Key MongoDB metrics
Monitor memory usage, CPU usage, and average read and write latency to identify
scale problems. If MongoDB is not scaled properly, it can become a bottleneck
when the number of concurrent users grows. Liveness probes are used to determine when a container
needs to be restarted. For instance, they detect a deadlock situation, where an application is still
running but unable to continue functioning properly. If a container continuously fails its liveness
probe, the kubelet restarts it. If the liveness probes time out and results in a pod restart, your
MongoDB cluster is likely undersized
For more information, see Liveness, Readiness, and Startup Probes
Monitor the following MongoDB metrics to identify scaling problems.
- Memory usage
- Monitoring memory usage is crucial for MongoDB performance. By default, MongoDB tries to cache the active dataset in memory by using the Wired Tiger cache. If you notice a high number of cache evictions or if MongoDB servers are terminated by the oomkiller process for using too much memory, consider increasing the memory that is allocated to the MongoDB server.
- CPU usage
- Help ensure that the MongoDB servers are not reaching their allocated CPU limits. Consistently high CPU usage might lead to performance issues, so regularly check this metric to avoid bottlenecks.
- Average read and write latency
- Ideally, the average read and write latency needs to be under 50 milliseconds. If the latency exceeds this threshold, it might indicate an undersized MongoDB cluster. Check whether the MongoDB cluster has sufficient memory allocation and verify disk performance.
- Lock waiters
- A large number of lock waiters is a sign of contention on collections or documents in MongoDB and might lead to performance degradation. Monitor and address any excessive lock wait times.