Database Monitoring offre des informations complètes sur vos bases de données MongoDB en donnant accès à des métriques essentielles, aux opérations lentes, aux échantillons d’opérations, aux plans d’exécution et aux changements d’état de réplication. Pour tirer parti de Database Monitoring pour MongoDB, assurez-vous que l’Agent Datadog est installé et configuré pour se connecter à vos instances MongoDB Atlas. Ce guide décrit les étapes de configuration de Database Monitoring pour MongoDB Atlas.
Avant de commencer
Versions majeures de MongoDB prises en charge
4.4, 5.0, 6.0, 7.0, 8.0
Niveaux de cluster MongoDB Atlas pris en charge
M10 et supérieur
Remarque : les instances MongoDB Atlas Serverless ou les clusters partagés (M0 Sandbox, M2, M5) ne sont pas pris en charge.
Supported Agent versions
7.58.0+
Performance impact
The default Agent configuration for Database Monitoring is conservative, but you can adjust settings such as the collection interval and operation sampling rate to better suit your needs. For most workloads, the Agent represents less than one percent of query execution time on the database and less than one percent of CPU.
Connection strings or SRV strings
Although MongoDB connection strings or SRV strings provide many benefits such as automatic failover and load balancing, the Datadog Agent must connect directly to the MongoDB instance being monitored. If the Agent connects to a different MongoDB instance while it is running (as in the case of failover, load balancing, and so on), the Agent calculates the difference in statistics between two hosts, producing inaccurate metrics.
Data security considerations
Read about how Database Management handles sensitive information for information about what data the Agent collects from your databases and how to ensure it is secure.
Configuration
Pour activer Database Monitoring pour votre base de données :
Accorder à l’Agent l’accès à votre cluster MongoDB Atlas
L’Agent Datadog nécessite un accès en lecture seule au cluster MongoDB Atlas pour collecter des statistiques et des requêtes.
Créer un rôle de surveillance personnalisé
Dans l’interface MongoDB Atlas, accédez à l’onglet Database Access.
Dans l’onglet Custom Roles, cliquez sur Add New Custom Role.
Saisissez un Custom Role Name, par exemple datadog.
Ajoutez les autorisations suivantes au rôle personnalisé :
read sur la base de données admin
read sur la base de données local
read sur la base de données config (cluster shardé uniquement)
clusterMonitor sur la base de données admin
read sur les bases de données créées par l’utilisateur que vous souhaitez surveiller, ou readAnyDatabase pour surveiller toutes les bases de données
Cliquez sur Add Custom Role.
Créer un utilisateur de surveillance avec le rôle de surveillance personnalisé
Dans l’interface MongoDB Atlas, accédez à l’onglet Database Access.
Dans l’onglet Database Users, cliquez sur Add New Database User.
Sous Authentication Method, sélectionnez Password.
Saisissez le nom d’utilisateur et le mot de passe.
Sous Database User Privileges, développez Custom Roles et sélectionnez le rôle de surveillance personnalisé créé à l’étape précédente.
Cliquez sur Add User.
Notez le nom d’utilisateur et le mot de passe de l’utilisateur de surveillance afin de pouvoir configurer l’Agent.
Stocker votre mot de passe de manière sécurisée
Store your password using secret management software such as Vault. You can then reference this password as ENC[<SECRET_NAME>] in your Agent configuration files: for example, ENC[datadog_user_database_password]. See Secrets Management for more information.
The examples on this page use datadog_user_database_password to refer to the name of the secret where your password is stored. It is possible to reference your password in plain text, but this is not recommended.
Installer et configurer l’Agent
Pour surveiller votre cluster MongoDB Atlas, installez et configurez l’Agent Datadog sur un host capable d’accéder à distance à votre cluster MongoDB Atlas. Ce host peut être un host Linux, un conteneur Docker ou un pod Kubernetes.
Obtenir le nom d’host et le port de l’instance MongoDB individuelle à partir de la chaîne de connexion SRV
Les applications se connectent généralement à MongoDB Atlas via une chaîne de connexion SRV, mais l’Agent Datadog doit se connecter directement à l’instance MongoDB individuelle surveillée. Si l’Agent se connecte à une instance MongoDB différente pendant son exécution (en cas de basculement, d’équilibrage de charge, etc.), l’Agent calcule la différence de statistiques entre deux hosts, ce qui produit des métriques inexactes.
Pour obtenir le nom d’host et le port de l’instance MongoDB individuelle, utilisez des outils en ligne de commande utilitaires réseau tels que dig sous Linux ou nslookup sous Windows pour résoudre la chaîne de connexion SRV.
Membres du replica set
Pour un cluster non shardé (replica set) avec la chaîne de connexion SRV mongodb+srv://XXXXX.XXX.mongodb.net/ :
Utilisez dig sous Linux pour résoudre la chaîne de connexion SRV :
Dans cet exemple, les instances MongoDB individuelles du shard-0 sont :
XXXXX-00-00.4zh9o.mongodb.net:27017
XXXXX-00-01.4zh9o.mongodb.net:27017
XXXXX-00-02.4zh9o.mongodb.net:27017
Pour le shard-1, ce sont :
XXXXX-01-00.4zh9o.mongodb.net:27017
XXXXX-01-01.4zh9o.mongodb.net:27017
XXXXX-01-02.4zh9o.mongodb.net:27017
Pour le serveur de configuration, ce sont :
XXXXX-00-00-config.4zh9o.mongodb.net:27017
XXXXX-00-01-config.4zh9o.mongodb.net:27017
XXXXX-00-02-config.4zh9o.mongodb.net:27017
Utilisez l’un de ces noms d’host pour configurer l’Agent.
Créer le fichier de configuration
To monitor a MongoDB replica set, the Agent needs to connect to all members (including the arbiter) of the replica set.
Use the following configuration block as an example to configure the Agent to connect to a replica set member:
init_config:instances:## @param hosts - required## Specify the hostname, IP address, or UNIX domain socket of## a mongod instance as listed in the replica set configuration.## If the port number is not specified, the default port 27017 is used.#- hosts:- <HOST>:<PORT>## @param username - string - optional## The username to use for authentication.#username:datadog## @param password - string - optional## The password to use for authentication.#password:"ENC[datadog_user_database_password]"## @param options - mapping - optional## Connection options. For a complete list, see:## https://docs.mongodb.com/manual/reference/connection-string/#connections-connection-options#options:authSource:admin## @param tls - boolean - optional## Set to true to connect to the MongoDB instance using TLS.#tls:true## @param dbm - boolean - optional## Set to true to enable Database Monitoring.#dbm:true## @param cluster_name - string - optional## The unique name of the cluster to which the monitored MongoDB instance belongs.## Used to group MongoDB instances in a MongoDB cluster.## cluster_name should follow Datadog tags naming conventions. See:## https://docs.datadoghq.com/extend/guide/what-best-practices-are-recommended-for-naming-metrics-and-tags/#rules-and-best-practices-for-naming-tags## Required when `dbm` is enabled.#cluster_name:<MONGO_CLUSTER_NAME>## @param reported_database_hostname - string - optional## Set the reported database hostname for the connected MongoDB instance.## This value overrides the MongoDB hostname detected by the Agent## from the MongoDB admin command serverStatus.host.#reported_database_hostname:<DATABASE_HOSTNAME_OVERRIDE>## @param additional_metrics - list of strings - optional## List of additional metrics to collect. Available options are:## - metrics.commands: Use of database commands## - tcmalloc: TCMalloc memory allocator## - top: Usage statistics for each collection## - collection: Metrics of the specified collections#additional_metrics:["metrics.commands","tcmalloc","top","collection"]## @param collections_indexes_stats - boolean - optional## Set to true to collect index statistics for the specified collections.## Requires `collections` to be set.#collections_indexes_stats:true## @param database_autodiscovery - mapping - optional## Enable database autodiscovery to automatically collect metrics from all your MongoDB databases.#database_autodiscovery:## @param enabled - boolean - required## Enable database autodiscovery.#enabled:true## @param include - list of strings - optional## List of databases to include in the autodiscovery. Use regular expressions to match multiple databases.## For example, to include all databases starting with "mydb", use "^mydb.*".## By default, include is set to ".*" and all databases are included.#include:- "^mydb.*"## @param exclude - list of strings - optional## List of databases to exclude from the autodiscovery. Use regular expressions to match multiple databases.## For example, to exclude all databases starting with "mydb", use "^mydb.*".## When the exclude list conflicts with include list, the exclude list takes precedence.#exclude:- "^mydb2.*"- "admin$"## @param max_databases - integer - optional## Maximum number of databases to collect metrics from. The default value is 100.#max_databases:100## @param refresh_interval - integer - optional## Interval in seconds to refresh the list of databases. The default value is 600 seconds.#refresh_interval:600
An example configuration for a replica set with 1 primary and 2 secondaries is as follows:
To monitor a MongoDB sharded cluster, the Agent needs to connect to the mongos router(s) and all members of the shards. If you have multiple mongos routers, you can configure the Agent to connect to them for load balancing.
Use the following configuration block as an example to configure the Agent to connect to a Mongos router:
init_config:instances:## @param hosts - required## For a sharded cluster, you need one check instance for each mongod instance in## each shard (including the configsvr shard) as well as one additional check instance## that connects to at least one mongos node.## Specify the hostname, IP address, or UNIX domain socket of the mongod or mongos instance.## If the port number is not specified, the default port 27017 is used.- hosts:- <HOST>:<PORT>## @param username - string - optional## The username to use for authentication.#username:datadog## @param password - string - optional## The password to use for authentication.#password:"ENC[datadog_user_database_password]"## @param options - mapping - optional## Connection options. For a complete list, see:## https://docs.mongodb.com/manual/reference/connection-string/#connections-connection-options#options:authSource:admin## @param tls - boolean - optional## Set to true to connect to the MongoDB instance using TLS.#tls:true## @param dbm - boolean - optional## Set to true to enable Database Monitoring.#dbm:true## @param cluster_name - string - optional## The unique name of the cluster to which the monitored MongoDB instance belongs.## Used to group MongoDB instances in a MongoDB cluster.## cluster_name should follow Datadog tags naming conventions. See:## https://docs.datadoghq.com/extend/guide/what-best-practices-are-recommended-for-naming-metrics-and-tags/#rules-and-best-practices-for-naming-tags## Required when `dbm` is enabled.#cluster_name:<MONGO_CLUSTER_NAME>## @param reported_database_hostname - string - optional## Set the reported database hostname for the connected MongoDB instance.## This value overrides the MongoDB hostname detected by## the Agent from the MongoDB admin command serverStatus.host.#reported_database_hostname:<DATABASE_HOSTNAME_OVERRIDE>## @param additional_metrics - list of strings - optional## List of additional metrics to collect. Available options are:## - metrics.commands: Use of database commands## - tcmalloc: TCMalloc memory allocator## - top: Usage statistics for each collection## - collection: Metrics of the specified collections## - jumbo_chunks: Count and percentage of jumbo chunks. Ignored on mongod instances.## - sharded_data_distribution: Distribution of data in sharded collections.#additional_metrics:["metrics.commands","tcmalloc","top","collection","jumbo_chunks","sharded_data_distribution"]## @param collections_indexes_stats - boolean - optional## Set to true to collect index statistics for the specified collections.## Requires `collections` to be set.#collections_indexes_stats:true## @param database_autodiscovery - mapping - optional## Enable database autodiscovery to automatically collect metrics from all your MongoDB databases.#database_autodiscovery:## @param enabled - boolean - required## Enable database autodiscovery.#enabled:true## @param include - list of strings - optional## List of databases to include in the autodiscovery. Use regular expressions to match multiple databases.## For example, to include all databases starting with "mydb", use "^mydb.*".## By default, include is set to ".*" and all databases are included.#include:- "^mydb.*"## @param exclude - list of strings - optional## List of databases to exclude from the autodiscovery. Use regular expressions to match multiple databases.## For example, to exclude all databases starting with "mydb", use "^mydb.*".## When the exclude list conflicts with include list, the exclude list takes precedence.#exclude:- "^mydb2.*"- "admin$"## @param max_databases - integer - optional## Maximum number of databases to collect metrics from. The default value is 100.#max_databases:100## @param refresh_interval - integer - optional## Interval in seconds to refresh the list of databases. The default value is 600 seconds.#refresh_interval:600
Refer to the Replica Set configuration for an example configuration for connecting to members in each shard and the config server.
An example configuration for a sharded cluster with 1 mongos router and 2 shards is as follows:
Place the MongoDB Agent configuration file created in the previous step in /etc/datadog-agent/conf.d/mongo.d/conf.yaml. See the sample conf file for all available configuration options.
To configure the Database Monitoring Agent running in a Docker container, set the Autodiscovery Integration Templates as Docker labels on your Agent container.
The MongoDB check is included in the Datadog Agent. No additional installation is necessary.
Note: The Agent must have read permission on the Docker socket for autodiscovery of labels to work.
Add the configuration details for the MongoDB check from the previous step in the com.datadoghq.ad.checks label. See the sample conf file for all available configuration options.
If you have a Kubernetes cluster, use the Datadog Cluster Agent for Database Monitoring.
If cluster checks are not already enabled in your Kubernetes cluster, follow the instructions to enable cluster checks. You can configure the Cluster Agent either with static files mounted in the Cluster Agent container, or by using Kubernetes service annotations.
Command line with Helm
Execute the following Helm command to install the Datadog Cluster Agent on your Kubernetes cluster. Replace the values to match your account and environment:
To configure a cluster check with a mounted configuration file, mount the configuration file in the Cluster Agent container on the path: /conf.d/mongo.yaml:
cluster_check:true# Make sure to include this flaginit_config:instances:- hosts:- <HOST>:<PORT>username:datadogpassword:"ENC[datadog_user_database_password]"options:authSource:admindbm:truecluster_name:<MONGO_CLUSTER_NAME>reported_database_hostname:<DATABASE_HOSTNAME_OVERRIDE>database_autodiscovery:enabled:trueadditional_metrics:["metrics.commands","tcmalloc","top","collection"]collections_indexes_stats:true
Configure with Kubernetes service annotations
Rather than mounting a file, you can declare the instance configuration as a Kubernetes Service. To configure this check for an Agent running on Kubernetes, create a Service in the same namespace as the Datadog Cluster Agent:
The Cluster Agent automatically registers this configuration and begins running the MongoDB integration.
To avoid exposing the datadog user’s password in plain text, use the Agent’s secret management package and declare the password using the ENC[] syntax.
Database Monitoring for MongoDB captures slow operations from either MongoDB slow query logs or the system.profile collection. Slow operations are defined as those taking longer than the slowms threshold set in your MongoDB configuration.
With Database Profiling Enabled: When profiling is enabled at levels 1 or 2, Database Monitoring collects slow operations from the system.profile collection.
With Database Profiling Disabled: If profiling is disabled, Database Monitoring relies on MongoDB getLog command to gather slow operations from slow query logs.
Note: The getLog command retrieves the most recent 1024 mongod events. In busy databases with a high volume of slow queries or when the slow query collection interval is set to a higher interval (resulting in less frequent collection), some slow queries may not be captured.
Operation samples and explain plans
Database Monitoring for MongoDB gathers operation samples using the currentOp command. This command provides information about operations that are currently being executed on the MongoDB instance. Additionally, Database Monitoring collects explain plans for the read operation samples using the explain command, offering detailed insights into the query execution plans.
Replication state changes
Database Monitoring for MongoDB generates an event each time there is a change in the replication state within the MongoDB instance. This ensures that any changes in replication are promptly detected and reported.
Collection of schemas and indexes
Database Monitoring for MongoDB collects inferred schemas and indexes of MongoDB collections. This information is used to provide insights into the structure and organization of your collections.
When analyzing MongoDB collections, Datadog collects inferred schema information by sampling documents using the $sample aggregation stage. From this analysis, only metadata about the schema is gathered and sent to Datadog, including field names, field prevalence (how often each field appears), and their respective data types. Datadog does not collect or transmit the actual content of documents or any customer business data. This ensures that sensitive data remains protected while still providing valuable insights into the structure and organization of your collections.
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles:
