Monitor

Prerequisites

• You have created a MongoDB Flex instance.
  Check Create and manage instances for MongoDB Flex.
• You have a STACKIT Observabilty managed service configured and running. Check Create and configure your first Observability service.
• Or you have a STACKIT Observabiliy Monitoring managed service configured and running.

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

Use the Portal

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.

Follow the steps to access the metrics:

1. On the sidebar click on MongoDB Flex.

2. Click on the instance for which you want to access the metrics.

3. On the sidebar click on Metrics.

If you need logs and traces to further analyze your MongoDB Flex problem, you need to scrape the telemetry to an Observability instance.

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

Use Observability to analyze and solve potential problems with your MongoDB Flex service

Regardless if you use STACKIT’s internal Observability solution or an external tool, you need to configure scraping manually. Add a scraper to your Prometheus instane to achieve this. Then add a dashboard to Grafana to visualize the metrics you are interested in. To get a list of available metrics, read Metrics of MongoDB Flex.

The Portal metrics querying competes with additional scraping from an Observability solution. You may need to reduce the scraping interval.

Intepret the metrics

The metrics and tresholds 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 tresholds 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 bandwith. 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.

Inefficient queries can also cause high Disk IOPS and Disk Util. Always consider query analyzation before allocating more resources.

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 permenently 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.

Inefficient queries can also cause high normalized system CPU. Always consider query analyzation before allocating more resources.