MongoDB monitoring is a Gateway configuration file that enables monitoring of MongoDB through the Toolkit plug-in.
MongoDB can monitor the database environment in a measurable way to spot any potential discrepancies and issues.
Some key areas to track when using MongoDB monitoring:
|Metrics||Determine the crucial alerts to be set in the metrics to avoid any performance issues or errors.|
|Database performance||Monitor the database's current state.|
|Resource utilisation||Monitor the number of client connections to avoid abnormal traffic loads that can lead to performance issues.|
|Asserts||Show errors raised during the selected time period.|
MongoDB helps you to get an overview of database operations, such as:
- Track the current state of database.
- View reports of asserts on the database.
- Monitor the metrics for write performance.
- View contains storage statistics for a given database.
- Check reports information regarding the state and use of indexes in MongoDB.
This technical reference provides information on the metrics and dataviews for the samplers available through the MongoDB integration. If you are setting up the MongoDB integration for the first time, see MongoDB Monitoring User Guide.
This view reports the number of asserts on the database:
|msg||Number of message assertions raised since the server process started.|
|regular||Number of regular assertions raised since the server process started.|
|user||Number of user-asserts that have occurred since the last time the server process started.|
|warning||Number of warnings raised since the server process started.|
The information on this view appears only for instances that use the MMAPv1 storage engine. Mongod periodically flushes and writes to disk.
In the default configuration, this happens every 60 seconds. This view contains data regarding these operations.
These metrics are important for write performance and journaling.
The information on this view appears only for instances that use the wiredTiger storage engine.
This contains ticket details that the wiredTiger uses for its thread management.
This view contains data regarding cursor state and use:
|openNoTimeout||Number of open cursors with timeout disabled.|
|openTotal||Number of cursors that MongoDB is maintaining for clients. Since MongoDB exhausts unused cursors, this value is usually small or zero.|
|timedOut||Provides a counter of the total number of cursors that have timed out since the server process started. If this number is larger or growing at a regular rate, this may indicate an application error.|
This view contains storage statistics for a given database. You can pass their database to the provided script:
|dataSize||Total size in bytes of the data held in this database including the padding factor.|
|indexSize||Total size in bytes of all indexes created on this database.|
|objects||Contains a count of the number of objects like documents in the database across all collections.|
|storageSize||Total amount of space in bytes allocated to the collections in this database for document storage.|
This view contains a build summary for the Mongo server instance:
|host||Configured host in the system.|
|localTime||Current time based on the server.|
|ok||Status of the server instance.|
|pid||Process ID number.|
|process||Current MongoDB process: mongod or mongos.|
|storageEngine||Type of storage engine.|
|uptime||Number of seconds that the MongoDB process has been active.|
|uptimeEstimate||Number in seconds based from MongoDB’s internal time keeping system.|
|uptimeMs||Number of milliseconds that the MongoDB process has been active.|
|version||Version of the current MongoDB process.|
This view provides a granular report on MongoDB database-level lock use:
Number of times the lock has been acquired. Possible lock modes:
Number of times when lock acquisitions waits because locks have encountered conflicts. Possible lock modes:
Cumulative waiting time in microseconds for the lock acquisition. Possible lock modes:
This view contains the MongoDB memory metrics:
|mapped||Provides the amount of mapped memory (in MB) by the database. Because MongoDB uses memory-mapped files, this value is likely to be roughly equivalent to the total size of your database(s).|
|nonMapped||Virtual memory collected by connections.|
|page_faults||Number of times MongoDB has requested to connect from disk per second.|
|resident||Equivalent to the amount of RAM (in MB) currently used by the database process. In normal use this value tends to grow, approaching total amount of system memory in dedicated servers.|
|virtual||Displays the quantity (in MB) of virtual memory used by the mongod process. If virtual value is significantly larger than mapped (e.g. 3 or more times), this may indicate a memory leak.|
This view provides an overview of database operations by type. These numbers will grow over time and in response to database use:
|getmore||Provides a counter of the total number of "getmore" operations since the mongod instance last started. This counter can be high even if the query count is low.|
|insert||Total number of "insert" operations since the mongod instance last started.|
|query||Total number of queries since the mongod instance last started.|
|readers||Number of clients with read operations.|
|update||Total number of "update" operations since the mongod instance last started.|
|writers||Number of clients with write operations.|
This information appears only if the replica set is used and it contains metrics related to replication:
|id||Unique identifier for each replication.|
|state||Value of state between 0 and 10 that represents the replica state.|
|stateStr||Describes the state string.|
|replicationLag||Shows the delay between a write operation on the primary and to its secondary. If the replication lag is set to zero, that means that there is no load issues yet.|