[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:
Documented
is documented by DOCS-9004 mongod/mongos ought to collect host-l... Closed
Related
Tested
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.)

echo "MongoDB Diag" > /tmp/system.data
mlog() {
    echo -e "\n\n\n $1 \n =======================" >> /tmp/system.data
    shift 1
    $@ 2>/dev/null >> /tmp/system.data
}
 
mlog uname uname -a                          
mlog date date                              
mlog blockdev /sbin/blockdev --report           
mlog libraries ls -l /lib/libc.so*               
mlog libraries /lib/libc.so*                    
mlog lsb lsb_release -a                  
mlog sysctl /sbin/sysctl -a                
mlog ifconfig /sbin/ifconfig -a             
mlog dmesg dmesg                        
mlog lspci lspci -vvv                  
mlog mount mount                      
mlog whoami whoami                    
mlog ulimit ulimit -a                
mlog df df -h                   
mlog cpuinfo cat /proc/cpuinfo      
mlog meminfo cat /proc/meminfo     
mlog swaps cat /proc/swaps      
mlog modules cat /proc/modules   
mlog vmstat cat /proc/vmstat   
mlog top -b -n 10                    
mlog iostat iostat -xtm 5 10               
mlog rpcinfo /usr/sbin/rpcinfo -p          
mlog scsidevices cat /sys/bus/scsi/devices/*/model 
mlog proc/limits
for i in `pgrep mongo`; do echo "PID: $i"; cat /proc/$i/cmdline; echo -e "\nLimits:\n"; cat /proc/$i/limits; echo; done >> /tmp/system.data
mlog smartctl
/usr/sbin/smartctl --scan | sed -e 's/#.*$//' | while read i; do /usr/sbin/smartctl --all $i; done >> /tmp/system.data
mlog nr_requests
for d in `find /sys -name nr_requests`; do (echo $d; cat $d); done  >> /tmp/system.data
mlog read_ahead_kb
for d in `find /sys -name read_ahead_kb`; do (echo $d; cat $d); done   >> /tmp/system.data
mlog scheduler
for d in `find /sys -name scheduler`; do (echo $d; cat $d); done   >> /tmp/system.data



 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

Generated at Thu Feb 08 03:29:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.