MongoDB ServerStatus Health Check Tips

by | May 30, 2017 | Blog, MongoDB

MongoDB ServerStatus is the main command used to produce a huge document containing important metrics and information about your database. When performing a health check, there are several important keys that you’ll want to be aware of inside serverStatus. The output can be minimized for information that you want to see. It can give you instance information or it can be very specific.

Some of the main groups of information are listed below:

  • Instance Information
  • Asserts
  • Connections and Network
  • Locking
  • Operations Statistics
  • Security
  • Replication Statistics
  • Storage Engine Statistics
  • Metrics

Running Commands

You can get very specific data by simply running a command in the mongo shell.

db.serverStatus().host
db.serverStatus().version
db.serverStatus().pid

You can also reduce the output of serverStatus by flagging documents you don’t want.

db.runCommand( {serverStatus: 1, repl: 0, metrics: 0, locks: 1, wiredTiger: 0} )

Setting repl, metrics and wiredTiger to 0 in this command will remove them from the serverStatus output.

Useful Information

There is a vast amount of information available to you through the serverStatus command; some of it will be useful to you and others will not. I am going to jump through some of the top documents and list out metrics I believe are important if you’re performance tuning or running a health check on your system. These commands can also be put into a script so you’re able to run a full check-up on your system.

Instance Information

It’s always good to start with a bit of useful information about the instance you’re running so you can keep this information for historical record to know your baseline.

  • host: current host on which you’re running serverStatus
  • version: current version of the host
  • uptime: the number of seconds MongoDB process has been running
  • localTime: current local time

These will give you a good starting point to begin gathering metrics on your instance.

asserts

This document gives you the number of assertions raised since the MongoDB process was started. They’re rare so you’ll want to keep an eye on them; they can give you an indication that you need to look in your server log for an issue.

  • warning: This will tell you if your instance is generating any warnings.
  • user: These assertions can give you valuable information particular to application and development issues that are happening in your instance.

mem

Always important to know where to check your memory utilization.

  • bits: the architecture on which your server is running
  • resident: This is “roughly” the amount of RAM in use by the database process
  • virtual: Size in MB of virtual memory used by Mongo process

connections

Here you can find the number of connections that are currently being made to the server. If you’re experiencing sudden latency issues, you may want to check this stat to determine if an excessive amount of connections are being made to the server. This setting can be limited by the unix ulimits or it can be set in the configuration file (–maxConns) for your MongoDB process.

  • current:
  • available:

wiredTiger

This is a very large document. Many of the fields inside this document are for internal usage for the MongoDB process but there are some useful fields to monitor for performance and baseline statistics.

cache

  • maximum bytes configured : how many bytes allowed for your cache
  • bytes currently in the cache: how many bytes are currently in the cache

extra_info

This is underlying system-specific information. Most noteworthy is the page_faults field which could indicate a performance issue. Windows counts hard and soft page faults in this statistic.

  • page_faults: If you have limited memory or are experiencing problems, this is the first place to look.
  • heap_usage_byes: total heap space used by the database process. (unix/linux)

globalLock

This will give a good bit of general information about database lock state. If you want more specific information about locks, you can look in the ‘locks’ document.

  • currentQueue.total: Total number of operations in the queue. (readers + writers) If this particular attribute starts growing it should cause some concern. What you’ll want to do is maintain a good ratio by comparing the total current queue and the number of active client connections.
  • activeClients.total: Total active client connections. (readers + writers)

opLatencies

Important statistics to monitor for I/O performance. If you start seeing a steady increase over time, you may be experiencing some index, network or disk issues.

  • reads
  • writes

opcounters & opcountersRepl

This document contains the total number of operations for the database; you can analyze them all over time to understand utilization. I like to monitor one in particular. It’s important to remember that these are statistics gathered since last restart, so you’ll want to keep a historical record and monitor it over time. The replication statistic is in the opcountersRepl document.

  • query: This is the total number of received queries to the instance. If you see a sudden unexpected jump in this number it could indicate an application or security issue.

metrics

This document is a group of several statistics generated automatically which gives an overview of the current use and state of the mongod instance.

  • operation.scanAndOrder: If this number is high, you may want to profile your queries and try to determine where you’re doing a sort operation and an index is not being used.
  • operation.writeConflicts: total operations with a write conflict, could indicate contention
  • repl.buffer.count: important metric to keep an eye on to monitor replication lag; if this keeps increasing over time, you may have some network issues.
  • cursor.timedOut: If this number is growing at a regular rate, you may be experiencing an application error.

Conclusion

There are certainly a number of documents and fields I didn’t touch on but it’s almost impossible to determine what will be specific to your instance. It’s important that you baseline your system so you know what statistics are like in a healthy environment in order to identify when your instance is not acting appropriately. Gather metrics daily or weekly and graph it out to see what your trending numbers are. This can start to give you an idea what to plan for in the future.

For more information regarding serverStatus and its usage, please refer to the MongoDB documentation.