MongoDB Server Metrics
| Metrics | Description |
|---|---|
| asserts_msg | The number of message asserts. These are internal server errors that have a well-defined text string. Stack traces are logged for these. |
| asserts_regular | The number of regular asserts raised since this process started. |
| asserts_user | The number of user asserts. These are errors that can be generated by a user such as out of disk space or duplicate key. |
| asserts_warning | The number of warnings raised since this process started. |
| BackgroundFlushing_flushes | The number of times the database has flushed all writes to disk. |
| BackgroundFlushing_total_ms | The number of milliseconds (ms) that the mongod processes have spent writing (i.e., flushing) data to disk. |
| Connections_active | The number of active client connections to the server. Active client connections refers to client connections that currently have operations in progress. |
| Connections_available | The number of unused available connections that the database can provide. Consider this value in combination with the value of current to understand the connection load on the database, and the UNIX ulimit Settings document for more information about system thresholds on available connections. |
| Connections_current | The number of connections to the database server from clients. This number includes the current shell session. Consider the value of available to add more context to this datum. This figure will include the current shell connection as well as any inter-node connections to support a replica set or sharded cluster. |
| Cursor_timedOut | The number of cursors that have timed out since the server process started. If this number is large or growing at a regular rate, this may indicate an application error. |
| Cursor_totalOpen | The number of cursors that MongoDB is maintaining for clients. Because MongoDB exhausts unused cursors, typically this value is small or zero. However, if there is a queue, stale tailable cursors, or a large number of operations this value may rise. |
| globalLock_ActiveClients | The number of connected clients. |
| globalLock_CurrentQueue | The number of operations queued waiting for the lock. A consistently small queue, particularly of shorter operations, should cause no concern. Also, consider this value in light of the size of the queue waiting for the read lock (e.g., readers) and write lock (e.g., writers) individually. |
| Mem_mapped | The number of megabytes of memory mapped by the database. Because MongoDB uses memory-mapped files, this value will be roughly equivalent to the total size of your databases. |
| Mem_resident | The amount of RAM, in megabytes (MB), currently used by the database process. In normal use, this value tends to grow. In dedicated database servers, this number tends to approach the total amount of system memory. |
| Mem_virtual | The quantity, in megabytes (MB), of virtual memory used by the mongod process. With journaling enabled, the value of virtual is at least twice the value of mapped. If the virtual value is significantly larger than mapped (e.g., 3 or more times), this may indicate a memory leak. |
| metricsGetLastErrorWtimeTotalMillis |
The total amount of time in milliseconds that the mongod has spent performing write concern operations with a write concern ( w w |
| Network_bytesIn | The amount of network traffic, in bytes, received by this database. Use this value to ensure that network traffic sent to the mongod process is consistent with expectations and overall inter-application traffic. |
| Network_bytesOut | The amount of network traffic, in bytes, sent from this database. Use this value to ensure that network traffic sent by the mongod process is consistent with expectations and overall inter-application traffic. |
| Network_numRequests | The number of distinct requests that the server has received. Use this value to provide context for the bytesIn and bytesOut values to ensure that MongoDB network utilization is consistent with expectations and application use. |
| OpCounters_command | The number of commands sent to MongoDB. |
| OpCounters_delete | The number of Delete operations. |
| OpCounters_getmore | The number of GetMore operations. |
| OpCounters_insert | The number of Insert operations. |
| OpCounters_query | The number of Query operations. |
| OpCounters_update | The number of Update operations. |
| OpLatencies_commands |
The total number of commands performed on the collection since startup. |
| OpLatencies_commands_latency |
The combined latency of the commands in microseconds. |
| OpLatencies_reads | The total number of reads performed on the collection since startup. |
| OpLatencies_reads_latency | The combined latency of the read operations in microseconds. |
| OpLatencies_writes |
The total number of writes performed on the collection since startup. |
| OpLatencies_writes_latency | The combined latency of the write operations in microseconds. |
| Oplog_Max_Size (new in 4.5.4) | The maximum size of the operation log. |
| Oplog_Size (new in 4.5.4) | The size of the operation log. |
| OplogTimeDiff_in_sec (new in 4.5.4) | The difference (in seconds) between the first entry in the log and the last entry in the log. |
| Repl_command | The number of Replicated Commands issued to the database. |
| Repl_delete | The number of Replicated Delete operations. |
| Repl_getmore | The number of GetMore operations. This counter can be high even if the query count is low. Secondary nodes send getMore operations as part of the replication process. |
| Repl_insert | The number of replicated insert operations. |
| Repl_query | The number of Replicated Queries. |
| Repl_update | The number of Replicated Update Operations. |
| Replication_MyState (new in 4.5.4) | An integer between 0 and 10 that represents the replica state of the current member. |
| replSetGetStatus_optimes_lastDurableWallTimeLag | The lag between the most recent operation with respect to the primary node. |
| Index_missRatio | Ratio of index hits to misses. If there are a lot of index misses then you should look at your queries to see if they are optimally using your indexes. You may need to add new indexes to make the queries run faster. You can explain the query to see which index queries are hitting and the total execution time so you can compare query performance before and after adding the new indexes. |
| wiredtiger_concurrentTransactions_read_out | The maximum number of concurrent read transactions (read tickets) allowed into the storage engine. |
| wiredtiger_concurrentTransactions_write_out | The maximum number of concurrent write transactions allowed into the WiredTiger storage engine. |
| wiredtiger_log_logBytesWritten | The total number of bytes written to the log by the WiredTiger storage engine. |
| wiredtiger_log_logSyncOperations | The total number of log synchronization operations performed by the WiredTiger storage engine. |
| wiredtiger_log_logSyncTimeDuration | The total time spent on log synchronization (sync) operations by the WiredTiger storage engine. |
| wiredtiger_log_logWriteOperations | The total number of write operations performed on the log by the WiredTiger storage engine. |
| wiredtiger_connection_totalFsyncIos | The total number of fsync I/O operations
performed by the WiredTiger storage engine. |
| wiredtiger_log_logFlushOperations | The total number of flush operations performed on the log by the WiredTiger storage engine. |