
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" }
]
})
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" }
]
})
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 un Agent pour chaque membre de chaque partition.
- Configurez un Agent pour chaque membre des serveurs de configuration.
- 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
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
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 :
- Activez la collecte de traces dans Datadog.
- Instrumentez l’application qui envoie des requêtes à Mongo.
Collecte de logs
Disponible à partir des versions > 6.0 de l’Agent
La collecte de logs est désactivée par défaut dans l’Agent Datadog. Vous devez l’activer dans datadog.yaml
:
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.
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ètre | Valeur |
---|
<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ètre | Valeur |
---|
<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ètre | Valeur |
---|
<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.collection | collection |
mongodb.commands | top |
mongodb.getmore | top |
mongodb.insert | top |
mongodb.queries | top |
mongodb.readLock | top |
mongodb.writeLock | top |
mongodb.remove | top |
mongodb.total | top |
mongodb.update | top |
mongodb.writeLock | top |
mongodb.tcmalloc | tcmalloc |
mongodb.metrics.commands | metrics.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 :