Very many MongoDB, Inc. "field" engagements (support, consulting, onboarding, and pre-sales interactions) require collecting information about a MongoDB deployment in order to understand, debug, tune, etc.
A quantity of the information that is desirable in these engagements are host-level properties (hardware details, OS version, library versions, OS settings, etc.) At the moment, collecting this information is easy for an individual host, but wrangling the information for a whole cluster becomes tedious in proportion to the number of hosts running MongoDB server processes. In consequence, customer interactions can become delayed and sidetracked on these data collection steps.
Proposal: (1) add code to mongod and mongos processes to collect the kinds of host-level information the MongoDB, Inc. field organization often wants to gather, and (2) present that information to (suitably authorized) clients via some command (maybe serverStatus, maybe some other existing command, maybe a new command; I don't think it matters).
Benefits: streamlining the collection of diagnostic information will improve efficiency of field activities (support, services, pre-sales, etc.)
Disadvantages: more code, all of it OS-dependent. (However, it ought be possible to implement in a very modular, incremental fashion.)
Documentation changes needed: if the feature is added, and if the feature is not considered "internal only", document the feature.
Driver changes needed: if it's considered desirable to have driver bindings to the proposed command, design, implement, and document them.
Example: a sample Bourne shell script the MongoDB support team has used for Linux follows. This is intended to enumerate the kinds of things we tend to gather, not as a concrete proposal for how to collect the info or present it back to users/client applications.
(Note: the info this script collects includes static information that only needs to be gathered once per process lifetime (OS kernel version, libraries, CPU info) and dynamic state that will change while the process runs (e.g., free disk space, I/O statistics). If this request needs to be broken up into subtasks, I'd propose that a first pass would be to collect the only static info at server startup time; a second or subsequent pass could gather the dynamic info, perhaps on a periodic basis.)