Monitoring for MongoDB¶
On this page
Monitoring is a critical component of all database administration. A firm grasp of MongoDB’s reporting will allow you to assess the state of your database and maintain your deployment without crisis. Additionally, a sense of MongoDB’s normal operational parameters will allow you to diagnose problems before they escalate to failures.
This document presents an overview of the available monitoring utilities and the reporting statistics available in MongoDB. It also introduces diagnostic strategies and suggestions for monitoring replica sets and sharded clusters.
MongoDB Cloud Manager, a hosted service, and Ops Manager, an on-premise solution, provide monitoring, backup, and automation of MongoDB instances. See the MongoDB Cloud Manager documentation and Ops Manager documentation for more information.
There are three methods for collecting data about the state of a running MongoDB instance:
- First, there is a set of utilities distributed with MongoDB that provides real-time reporting of database activities.
- Second, database commands return statistics regarding the current database state with greater fidelity.
- Third, MongoDB Cloud Manager, a hosted service, and Ops Manager, an on-premise solution available in MongoDB Enterprise Advanced, provide monitoring to collect data from running MongoDB deployments as well as providing visualization and alerts based on that data.
Each strategy can help answer different questions and is useful in different contexts. These methods are complementary.
MongoDB Reporting Tools¶
This section provides an overview of the reporting methods distributed with MongoDB. It also offers examples of the kinds of questions that each method is best suited to help you address.
The MongoDB distribution includes a number of utilities that quickly return statistics about instances’ performance and activity. Typically, these are most useful for diagnosing issues and assessing normal operation.
mongostat captures and returns the counts of database
operations by type (e.g. insert, query, update, delete, etc.). These
counts report on the load distribution on the server.
mongotop tracks and reports the current read and write
activity of a MongoDB instance, and reports these statistics on a per
MongoDB provides a web interface that exposes diagnostic
and monitoring information in a simple web page. The web interface is
localhost:<port>, where the
<port> number is 1000 more than the
mongod port .
For example, if a locally running
mongod is using the
27017, access the HTTP console at
MongoDB includes a number of commands that report on the state of the database.
These data may provide a finer level of granularity than the utilities
discussed above. Consider using their output in scripts and programs to
develop custom alerts, or to modify the behavior of your application in
response to the activity of your instance. The
method is another useful tool for identifying the database instance’s
serverStatus command, or
from the shell, returns a general overview of the status of the
database, detailing disk usage, memory use, connection, journaling,
and index access. The command returns quickly and does not impact
serverStatus outputs an account of the state of a MongoDB
instance. This command is rarely run directly. In most cases, the data
is more meaningful when aggregated, as one would see with monitoring
tools including MongoDB Cloud Manager and Ops Manager. Nevertheless, all
administrators should be familiar with the data provided by
dbStats command, or
db.stats() from the shell,
returns a document that addresses storage use and data volumes. The
dbStats reflect the amount of
storage used, the quantity of data contained in the database, and
object, collection, and index counters.
Use this data to monitor the state and storage capacity of a specific database. This output also allows you to compare use between databases and to determine the average document size in a database.
db.collection.stats() from the
shell that provides statistics that resemble
the collection level, including a count of the objects in the
collection, the size of the collection, the amount of disk space used
by the collection, and information about its indexes.
replSetGetStatus command (
the shell) returns an overview of your replica set’s status. The replSetGetStatus document details the
state and configuration of the replica set and statistics about its members.
Use this data to ensure that replication is properly configured, and to check the connections between the current host and the other members of the replica set.
Third Party Tools¶
A number of third party monitoring tools have support for MongoDB, either directly, or through their own plugins.
Self Hosted Monitoring Tools¶
These are monitoring tools that you must install, configure and maintain on your own servers. Most are open source.
|Ganglia||mongodb-ganglia||Python script to report operations per second, memory usage, btree statistics, master/slave status and current connections.|
|Ganglia||gmond_python_modules||Parses output from the
|Motop||None||Realtime monitoring tool for MongoDB servers. Shows current operations ordered by durations every second.|
|mtop||None||A top like tool.|
|Munin||mongo-munin||Retrieves server statistics.|
|Munin||mongomon||Retrieves collection statistics (sizes, index sizes, and each (configured) collection count for one DB).|
|Munin||munin-plugins Ubuntu PPA||Some additional munin plugins not in the main distribution.|
|Nagios||nagios-plugin-mongodb||A simple Nagios check script, written in Python.|
Also consider dex, an index and query analyzing tool for MongoDB that compares MongoDB log files and indexes to make indexing recommendations.
Hosted (SaaS) Monitoring Tools¶
These are monitoring tools provided as a hosted service, usually through a paid subscription.
|MongoDB Cloud Manager||MongoDB Cloud Manager is a cloud-based suite of services for managing MongoDB deployments. MongoDB Cloud Manager provides monitoring, backup, and automation functionality. For an on-premise solution, see also Ops Manager, available in MongoDB Enterprise Advanced.|
|Scout||Several plugins, including MongoDB Monitoring, MongoDB Slow Queries, and MongoDB Replica Set Monitoring.|
|Server Density||Dashboard for MongoDB, MongoDB specific alerts, replication failover timeline and iPhone, iPad and Android mobile apps.|
|Application Performance Management||IBM has an Application Performance Management SaaS offering that includes monitor for MongoDB and other applications and middleware.|
During normal operation,
instances report a live account of all server activity and operations
standard output or a log file. The following runtime settings
control these options.
quiet. Limits the amount of information written to the log or output.
verbosity. Increases the amount of information written to the log or output. You can also modify the logging verbosity during runtime with the
logLevelparameter or the
db.setLogLevel()method in the shell.
path. Enables logging to a file, rather than the standard output. You must specify the full path to the log file when adjusting this setting.
logAppend. Adds information to a log file instead of overwriting the file.
mongod -v --logpath /var/log/mongodb/server1.log --logappend
The following database commands also affect logging:
Diagnosing Performance Issues¶
As you develop and operate applications with MongoDB, you may want to analyze the performance of the database as the application. Analyzing MongoDB Performance discusses some of the operational factors that can influence performance.
Replication and Monitoring¶
Beyond the basic monitoring requirements for any MongoDB instance, for replica sets, administrators must monitor replication lag. “Replication lag” refers to the amount of time that it takes to copy (i.e. replicate) a write operation on the primary to a secondary. Some small delay period may be acceptable, but two significant problems emerge as replication lag grows:
First, operations that occurred during the period of lag are not replicated to one or more secondaries. If you’re using replication to ensure data persistence, exceptionally long delays may impact the integrity of your data set.
Second, if the replication lag exceeds the length of the operation log (oplog) then MongoDB will have to perform an initial sync on the secondary, copying all data from the primary and rebuilding all indexes. This is uncommon under normal circumstances, but if you configure the oplog to be smaller than the default, the issue can arise.
The size of the oplog is only configurable during the first run using the
--oplogSizeargument to the
mongodcommand, or preferably, the
oplogSizeMBsetting in the MongoDB configuration file. If you do not specify this on the command line before running with the
mongodwill create a default sized oplog.
By default, the oplog is 5 percent of total available disk space on 64-bit systems. For more information about changing the oplog size, see the Change the Size of the Oplog
For causes of replication lag, see Replication Lag.
Replication issues are most often the result of network connectivity
issues between members, or the result of a primary that does not
have the resources to support application and replication traffic. To
check the status of a replica, use the
the following helper in the shell:
replSetGetStatus reference provides a more in-depth
overview view of this output. In general, watch the value of
optimeDate, and pay particular attention
to the time difference between the primary and the