MongoDB

Supported OS Linux Mac OS Windows

Dashboard MongoDB

Présentation

Associez MongoDB à Datadog pour :

  • Visualiser les métriques clés de MongoDB
  • Corréler les performances de MongoDB avec le reste de vos applications

Vous pouvez également créer vos propres métriques à l’aide de requêtes personnalisées find, count et aggregate.

Remarque : MongoDB v3.0 ou ultérieur est requis pour cette intégration. L’intégration de MongoDB Atlas avec Datadog est uniquement disponibles sur les clusters M10+.

Configuration

Installation

Le check MongoDB est inclus avec le package de l’Agent Datadog. Vous n’avez donc rien d’autre à installer.

Architecture

La plupart des métriques mesurant des éléments précis (tels que la disponibilité, la taille, etc.) doivent être recueillies sur chaque nœud mongod. Les métriques plus globales (comme les statistiques sur les index ou la collecte) doivent être recueillies une seule fois. Ainsi, la configuration de votre Agent dépend du déploiement de votre cluster mongo.

Déploiement autonome

Pour configurer cette intégration pour un déploiement MongoDB composé d’un seul nœud :

Préparer MongoDB

Dans un shell Mongo, créez un utilisateur en lecture seule pour l’Agent Datadog dans la base de données admin :

# S'authentifier en tant qu'administrateur.
use admin
db.auth("admin", "<VOTRE_MOTDEPASSE_ADMIN_MONGODB>")

# Sur MongoDB 2.x, utiliser la commande addUser.
db.addUser("datadog", "<MOTDEPASSEUNIQUE>", true)

# Sur MongoDB 3.x ou une version ultérieure, utiliser la commande createUser.
db.createUser({
  "user": "datadog",
  "pwd": "<MOTDEPASSEUNIQUE>",
  "roles": [
    { role: "read", db: "admin" },
    { role: "clusterMonitor", db: "admin" },
    { role: "read", db: "local" }
  ]
})
Configurer les Agents

Pour recueillir toutes les métriques Mongo disponibles, vous avez besoin d’un seul Agent. Il est préférable de l’exécuter sur le même nœud. Consultez les options de configuration ci-dessous.

ReplicaSet

Pour configurer cette intégration pour un ReplicaSet MongoDB :

Préparer MongoDB

Dans un shell Mongo, authentifiez-vous auprès du serveur primaire et créez un utilisateur en lecture seule pour l’Agent Datadog dans la base de données admin :

# S'authentifier en tant qu'administrateur.
use admin
db.auth("admin", "<VOTRE_MOTDEPASSE_ADMIN_MONGODB>")

# Sur MongoDB 2.x, utiliser la commande addUser.
db.addUser("datadog", "<MOTDEPASSEUNIQUE>", true)

# Sur MongoDB 3.x ou une version ultérieure, utiliser la commande createUser.
db.createUser({
  "user": "datadog",
  "pwd": "<MOTDEPASSEUNIQUE>",
  "roles": [
    { role: "read", db: "admin" },
    { role: "clusterMonitor", db: "admin" },
    { role: "read", db: "local" }
  ]
})
Configurer les Agents

Vous avez besoin d’un Agent pour chaque membre. Consultez les options de configuration ci-dessous. Remarque : d’après la documentation MongoDB (en anglais), la surveillance des nœuds arbitres n’est pas possible à distance. Cependant, tout changement de statut d’un nœud arbitre est signalé à l’Agent connecté au serveur primaire.

Partitionnement

Pour configurer cette intégration pour un cluster MongoDB partitionné :

Préparer MongoDB

Pour chaque partition de votre cluster, connectez-vous au serveur primaire du ReplicaSet et créez un utilisateur local en lecture seule pour l’Agent Datadog dans la base de données admin :

# S'authentifier en tant qu'administrateur.
use admin
db.auth("admin", "<VOTRE_MOTDEPASSE_ADMIN_MONGODB>")

# Sur MongoDB 2.x, utiliser la commande addUser.
db.addUser("datadog", "<MOTDEPASSEUNIQUE>", true)

# Sur MongoDB 3.x ou une version ultérieure, utiliser la commande createUser.
db.createUser({
  "user": "datadog",
  "pwd": "<MOTDEPASSEUNIQUE>",
  "roles": [
    { role: "read", db: "admin" },
    { role: "clusterMonitor", db: "admin" },
    { role: "read", db: "local" }
  ]
})

Créez ensuite le même utilisateur depuis un proxy mongos. Cette étape entraîne également la création d’un utilisateur local dans les serveurs de configuration, ce qui permet une connexion directe.

Configurer les Agents
  1. Configurer un Agent pour chaque membre de chaque partition.
  2. Configurez un Agent pour chaque membre des serveurs de configuration.
  3. Configurez un Agent supplémentaire pour vous connecter au cluster via un proxy mongos. La surveillance peut être assuré par ce proxy Mongos ou par un proxy existant.

Remarque : d’après la [documentation MongoDB][1] (en anglais), la surveillance des nœuds arbitres n’est pas possible à distance. Cependant, tout changement de statut d’un nœud arbitre est signalé à l’Agent connecté au serveur primaire. [1]: https://docs.mongodb.com/manual/core/replica-set-arbiter/#authentication

Configuration

Suivez les instructions ci-dessous pour configurer ce check lorsque l’Agent est exécuté sur un host. Consultez la section Environnement conteneurisé pour en savoir plus sur les environnements conteneurisés.

Host

Pour configurer ce check lorsque l’Agent est exécuté sur un host :

Collecte de métriques
  1. Modifiez le fichier mongo.d/conf.yaml dans le dossier conf.d/ à la racine du répertoire de configuration de votre Agent. Consultez le fichier d’exemple mongo.d/conf.yaml pour découvrir toutes les options de configuration disponibles.

    init_config:
    
    instances:
        ## @param hosts - list of strings - required
        ## Hosts to collect metrics from, as is appropriate for your deployment topology.
        ## E.g. for a standalone deployment, specify the hostname and port of the mongod instance.
        ## For replica sets or sharded clusters, see instructions in the sample conf.yaml.
        ## Only specify multiple hosts when connecting through mongos
        #
      - 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: <UNIQUEPASSWORD>
    
        ## @param database - string - optional
        ## The database to collect metrics from.
        #
        database: <DATABASE>
    
        ## @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
    
  2. Redémarrez l’Agent.

Collecte de traces

L’APM Datadog s’intègre à Mongo pour vous permettre de visualiser les traces sur l’ensemble de votre système distribué. La collecte de traces est activée par défaut dans les versions 6 et ultérieures de l’Agent Datadog. Pour commencer à recueillir des traces :

  1. Activez la collecte de traces dans Datadog.
  2. Instrumentez l’application qui envoie des requêtes à Mongo.
Collecte de logs

Disponible à partir des versions > 6.0 de l’Agent

  1. La collecte de logs est désactivée par défaut dans l’Agent Datadog. Vous devez l’activer dans datadog.yaml :

    logs_enabled: true
    
  2. Ajoutez ce bloc de configuration à votre fichier mongo.d/conf.yaml pour commencer à recueillir vos logs MongoDB :

    logs:
      - type: file
        path: /var/log/mongodb/mongodb.log
        service: mongo
        source: mongodb
    

    Modifiez les valeurs des paramètres service et path en fonction de votre environnement. Consultez le fichier d’exemple mongo.yaml pour découvrir toutes les options de configuration disponibles.

  3. Redémarrez l’Agent.

Docker

Pour configurer ce check lorsque l’Agent est exécuté sur un conteneur :

Collecte de métriques

Définissez des modèles d’intégration Autodiscovery en tant qu’étiquettes Docker sur votre conteneur d’application :

LABEL "com.datadoghq.ad.check_names"='["mongo"]'
LABEL "com.datadoghq.ad.init_configs"='[{}]'
LABEL "com.datadoghq.ad.instances"='[{"hosts": ["%%host%%:%%port%%""], "username": "datadog", "password" : "<MOTDEPASSEUNIQUE>", "database": "<BASEDEDONNÉES>"}]'
Collecte de logs

La collecte des logs est désactivée par défaut dans l’Agent Datadog. Pour l’activer, consultez la section Collecte de logs avec Docker.

Définissez ensuite des intégrations de logs en tant qu’étiquettes Docker :

LABEL "com.datadoghq.ad.logs"='[{"source":"mongodb","service":"<NOM_SERVICE>"}]'
Collecte de traces

L’APM pour applications conteneurisées est pris en charge sur les versions 6 et ultérieures de l’Agent, mais nécessite une configuration supplémentaire pour commencer à recueillir des traces.

Variables d’environnement requises sur le conteneur de l’Agent :

ParamètreValeur
<DD_API_KEY>api_key
<DD_APM_ENABLED>true
<DD_APM_NON_LOCAL_TRAFFIC>true

Consultez la section Tracer des applications Docker pour voir la liste complète des variables d’environnement et configurations disponibles.

Ensuite, instrumentez le conteneur de votre application et définissez DD_AGENT_HOST sur le nom du conteneur de votre Agent.

Kubernetes

Pour configurer ce check lorsque l’Agent est exécuté sur Kubernetes :

Collecte de métriques

Définissez des modèles d’intégration Autodiscovery en tant qu’annotations de pod sur votre conteneur d’application. Cette configuration peut également être réalisée avec un fichier, une configmap ou une paire key/value.

apiVersion: v1
kind: Pod
metadata:
  name: mongo
  annotations:
    ad.datadoghq.com/mongo.check_names: '["mongo"]'
    ad.datadoghq.com/mongo.init_configs: '[{}]'
    ad.datadoghq.com/mongo.instances: |
      [
        {
          "hosts": ["%%host%%:%%port%%"], 
          "username": "datadog", 
          "password": "<MOTDEPASSEUNIQUE>", 
          "database": "<BASEDEDONNÉES>"
        }
      ]      
spec:
  containers:
    - name: mongo
Collecte de logs

La collecte des logs est désactivée par défaut dans l’Agent Datadog. Pour l’activer, consultez la section Collecte de logs avec Kubernetes.

Définissez ensuite des intégrations de logs en tant qu’annotations de pod. Cette configuration peut également être réalisée à l’aide d’un fichier, d’une configmap ou d’une paire key/value.

apiVersion: v1
kind: Pod
metadata:
  name: mongo
  annotations:
    ad.datadoghq.com/mongo.logs: '[{"source":"mongodb","service":"<NOM_SERVICE>"}]'
spec:
  containers:
    - name: mongo
Collecte de traces

L’APM dédié aux applications conteneurisées est pris en charge par les hosts exécutant les versions 6 et ultérieures de l’Agent, mais nécessite une configuration supplémentaire pour recueillir des traces.

Variables d’environnement requises sur le conteneur de l’Agent :

ParamètreValeur
<DD_API_KEY>api_key
<DD_APM_ENABLED>true
<DD_APM_NON_LOCAL_TRAFFIC>true

Consultez les sections relatives au tracing d’applications Kubernetes et à la configuration de DaemonSet Kubernetes pour voir la liste complète des variables d’environnement et configurations disponibles.

Ensuite, instrumentez votre conteneur d’application et définissez DD_AGENT_HOST sur le nom du conteneur de votre Agent.

ECS

Pour configurer ce check lorsque l’Agent est exécuté sur ECS :

Collecte de métriques

Définissez des modèles d’intégration Autodiscovery en tant qu’étiquettes Docker sur votre conteneur d’application :

{
  "containerDefinitions": [{
    "name": "mongo",
    "image": "mongo:latest",
    "dockerLabels": {
      "com.datadoghq.ad.check_names": "[\"mongo\"]",
      "com.datadoghq.ad.init_configs": "[{}]",
      "com.datadoghq.ad.instances": "[{\"hosts\": [\"%%host%%:%%port%%\"], \"username\": \"datadog\", \"password\": \"<MOTDEPASSEUNIQUE>\", \"database\": \"<BASEDEDONNÉES>\"}]"
    }
  }]
}
Collecte de logs

Disponible à partir des versions > 6.0 de l’Agent

La collecte des logs est désactivée par défaut dans l’Agent Datadog. Pour l’activer, consultez la section Collecte de logs avec ECS.

Définissez ensuite des intégrations de logs en tant qu’étiquettes Docker :

{
  "containerDefinitions": [{
    "name": "mongo",
    "image": "mongo:latest",
    "dockerLabels": {
      "com.datadoghq.ad.logs": "[{\"source\":\"mongodb\",\"service\":\"<NOM_SERVICE>\"}]"
    }
  }]
}
Collecte de traces

L’APM dédié aux applications conteneurisées est pris en charge sur les versions 6 et ultérieures de l’Agent, mais nécessite une configuration supplémentaire pour recueillir des traces.

Variables d’environnement requises sur le conteneur de l’Agent :

ParamètreValeur
<DD_API_KEY>api_key
<DD_APM_ENABLED>true
<DD_APM_NON_LOCAL_TRAFFIC>true

Consultez la section Tracer des applications Docker pour voir la liste complète des variables d’environnement et configurations disponibles.

Ensuite, instrumentez votre conteneur d’application et définissez DD_AGENT_HOST sur l’adresse IP privée EC2.

Validation

Lancez la sous-commande status de l’Agent et cherchez mongo dans la section Checks.

Données collectées

Métriques

Consultez la documentation sur MongoDB 3.0 (en anglais) pour en savoir plus sur certaines de ces métriques.

REMARQUE : les métriques suivantes ne sont PAS recueillies par défaut. Utilisez le paramètre additional_metrics dans votre fichier mongo.d/conf.yaml pour les recueillir :

Préfixe de la métriqueÉlément à ajouter à additional_metrics pour recueillir la métrique
mongodb.collectioncollection
mongodb.commandstop
mongodb.getmoretop
mongodb.inserttop
mongodb.queriestop
mongodb.readLocktop
mongodb.writeLocktop
mongodb.removetop
mongodb.totaltop
mongodb.updatetop
mongodb.writeLocktop
mongodb.tcmalloctcmalloc
mongodb.metrics.commandsmetrics.commands

Événements

Changements de statut de réplication :
Ce check émet un événement chaque fois que le statut de réplication d’un nœud Mongo change.

Checks de service

mongodb.can_connect :
Renvoie CRITICAL si l’Agent ne parvient pas à se connecter à MongoDB pour recueillir des métriques. Si ce n’est pas le cas, renvoie OK.

Dépannage

Besoin d’aide ? Contactez l’assistance Datadog.

Pour aller plus loin

Lisez notre série d’articles de blog à propos de la collecte de métriques MongoDB avec Datadog :

PREVIEWING: may/embedded-workflows