[SERVER-12698] mongod/mongos ought to collect host-level info & serve it via commands Created: 12/Feb/14 Updated: 14/Mar/17 Resolved: 27/Aug/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Richard Kreuter (Inactive) | Assignee: | Kevin Pulo |
| Resolution: | Won't Fix | Votes: | 5 |
| Labels: | community-team, polish | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
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.)
|
| Comments |
| Comment by Thomas Rueckstiess [ 27/Aug/14 ] |
|
It was decided that this functionality is not appropriate to include in the server. We're looking at alternatives to collect this information, e.g. via a standalone tool. |
| Comment by Richard Kreuter (Inactive) [ 18/Feb/14 ] |
|
Sure, all the stuff that hostInfo doesn't currently collect that the shell script in the original report requests. |
| Comment by Daniel Pasette (Inactive) [ 18/Feb/14 ] |
|
There is already OS specific host information exposed via the hostInfo command. This information is also exposed in MMS in the hostInfo field in the "last ping" view. Can you specify what additional fields are desired and for which platforms? example of platforma specific code is here: https://github.com/mongodb/mongo/blob/master/src/mongo/util/processinfo_linux2.cpp |