Monitor MongoDB Flex

Introduction

Monitoring and Observability in combination with your database is a crucial part of providing a good customer experience and to prove your own SLAs towards your customers. With Observability, STACKIT offers a managed service which covers Observability and monitoring. Read the documentation on Observability to learn how to configure the managed service to your needs.

This article is based on the paradigm that you use monitoring with thresholds on certain metrics to recognize situations which need your attention and Observability to analyze how to take action.

Access the metrics

You have three major possibilities to obtain your metrics. You can either easily view them in the STACKIT Portal or go with the more sophisticated methods. From the latter you can choose whether you want to store your metrics in STACKIT Observability or you want to store them in a self-managed Prometheus instance.

MongoDB Flex offers several metrics directly in the Portal. This is an additional preconfigured service and runs in parallel to an optional self-configured Observability instance.

Requirements

You have created a MongoDB Flex instance.
Check Create and manage instances of MongoDB Flex.

Follow the steps to access the metrics:

On the sidebar click on MongoDB Flex.
Click on the instance for which you want to access the metrics.
On the sidebar click on Metrics.

The panel shows the current utilization of the most important resources of all nodes. Consult Dashboard metrics of MongoDB Flex to get an idea of the meaning of the metrics.

Interpret the metrics

The metrics and thresholds are important tools to maintain your instance. Besides proving to your customer that your SLAs are met, you get important information for sizing your instance. It is good practice to set the alarm thresholds between 60% and 80% depending on your risk affinity and reaction time.

Before allocating more resources, try to optimize your database and queries first. There are several patterns in the metrics that give you hints about optimization potential. Read MongoDBs Guide to optimizing MongoDB performance and Query optimization on how to recognize these patterns and on how to mitigate the causes.

If you are sure that you need more resources, utilize the metrics as well. For every instance type (Single, Replica, Sharded) there are three parameters that control the allocated resources: database site, performance class and flavor.

Database size

If the metric DB Storage growths over 80%, it is best practice to increase the database size.

Performance class

When you analyze performance problems with storage, you need to distinguish between two parameters: IOPS and disk bandwidth. The first is more important for internal database tasks and handling many small queries, the latter is important when serving large bulk files with your queries.

If the metric Disk IOPS reaches 80% of the IOPS of your performance class plan, it is best practice to upgrade the performance class. Read Flavors and performance classes of MongoDB Flex to look up which plan has how much IOPS.

If the metric Disk Util % permanently reaches 60%, consider upgrading the performance class.

Flavor

MongoDB heavily relies on memory. As a rule of thumb, your RAM should be as big as 60% of your MongoDB’s DB Storage. With the flavor parameter, you can allocate more memory and CPU resources to your instance.

When interpretating memory metrics, you need to distinguish between Resident and Virtual memory. Resident memory is the amount of memory which is really used and therefore the parameter you need to pay attention to. If it permanently lies above 80%, consider upgrading the flavor.

For analyzing the need on CPUs, monitor the normalized system CPU parameter. If it lies permanently over 80%, consider upgrading the flavor.