Surveillance et alertes MongoDB : guide pratique avec exemples réels

Introduction

La surveillance et les alertes MongoDB, accompagnées d'exemples pratiques, doivent aider les opérateurs à passer d'un problème observé à un résultat vérifié. Commencez par identifier la version installée, la topologie du déploiement, les prérequis et le composant exact inspecté.

Cet article se concentre sur la surveillance MongoDB pour les développeurs, les consultants DevOps et les équipes techniques de startups. Il relie les alertes MongoDB, les métriques MongoDB, les tableaux de bord MongoDB et la réponse aux incidents MongoDB aux commandes, aux sorties attendues, aux signaux de défaillance et aux décisions de récupération qui correspondent à la technologie sélectionnée.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des variables fictives au lieu de secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint.

Inventaire de la version et de l'environnement

Avant de surveiller quoi que ce soit, sachez exactement ce que vous exécutez. Commencez par capturer la version du serveur MongoDB, les informations de build et la topologie du déploiement. Il s'agit d'une étape d'inventaire en lecture seule qui prépare le terrain pour toutes les décisions ultérieures de surveillance et d'alerte.

Prérequis : Vous avez besoin de mongosh installé localement ou d'un accès au serveur où mongosh est disponible. L'accès réseau à l'instance MongoDB sur le port 27017 (ou votre port personnalisé) est requis. Aucune authentification n'est supposée dans cet exemple ; si votre déploiement exige une authentification, ajustez la chaîne de connexion en conséquence.

Commande d'observation en lecture seule :

mongosh --quiet --eval "db.version()"

Sortie attendue :

6.0.5

Cela vous indique la version majeure.mineure.corrective, qui détermine la disponibilité des fonctionnalités et les noms des métriques. Par exemple, les métriques serverStatus peuvent différer entre les versions 4.4 et 6.0.

Ensuite, confirmez la topologie du déploiement. S'agit-il d'une instance autonome, d'un jeu de réplicas ou d'un cluster fragmenté ? Exécutez :

mongosh --quiet --eval "db.adminCommand({replSetGetStatus: 1}).myState"

Si la sortie est 1, le nœud est primaire ; 2 est secondaire ; une erreur indique une instance autonome. Pour un cluster fragmenté, vérifiez sh.status().

Signal de défaillance : Si db.version() échoue ou renvoie une version inattendue, arrêtez-vous et résolvez le problème de connectivité ou d'environnement avant de continuer. Ne tentez pas de configurer la surveillance sur un déploiement mal identifié.

Rayon d'impact : Ces commandes sont en lecture seule et sûres. Elles n'affectent ni les performances ni les données.

Récupération : Si la commande échoue, vérifiez que le service MongoDB est en cours d'exécution (sudo systemctl status mongod), consultez le fichier journal (/var/log/mongodb/mongod.log) et assurez-vous de la connectivité réseau.

Chemin de configuration sûr

Configurer la surveillance et les alertes en toute sécurité signifie apporter de petites modifications réversibles avec des étapes de retour en arrière claires. La première étape la plus courante consiste à activer le profileur de base de données pour capturer les requêtes lentes, mais faites-le avec prudence.

Observation avant modification : Vérifiez l'état actuel du profileur :

mongosh --quiet --eval "db.getProfilingStatus()"

Sortie attendue :

{ "was": 0, "slowms": 100, "sampleRate": 1 }

was: 0 signifie que le profilage est désactivé. slowms: 100 signifie que les requêtes plus lentes que 100 ms sont considérées comme lentes si le profilage est activé.

Plus petite modification justifiée : Activez le profilage au niveau 1 (uniquement les requêtes lentes) avec un seuil de 200 ms et définissez un taux d'échantillonnage de 0,5 pour réduire la surcharge. Cette modification est uniquement en mémoire ; elle ne persiste pas après un redémarrage.

mongosh --quiet --eval "db.setProfilingLevel(1, { slowms: 200, sampleRate: 0.5 })"

Vérification :

mongosh --quiet --eval "db.getProfilingStatus()"

Sortie attendue :

{ "was": 1, "slowms": 200, "sampleRate": 0.5 }

Rayon d'impact : Le profilage ajoute une petite quantité de surcharge d'E/S et de CPU par requête profilée. Avec un taux d'échantillonnage de 0,5, seule la moitié des requêtes lentes est journalisée. C'est généralement sûr, mais surveillez la taille de la collection du profileur.

Récupération : Pour désactiver le profilage, remettez le niveau à 0 :

mongosh --quiet --eval "db.setProfilingLevel(0)"

Avertissement de persistance : Cette modification n'est pas persistante. Si vous voulez qu'elle survive aux redémarrages, vous devez définir les paramètres profile et slowms dans le fichier de configuration (/etc/mongod.conf). Testez toujours les modifications de configuration dans un environnement de préproduction d'abord.

Vérification et diagnostics

Une fois la surveillance configurée, vous devez vérifier que les métriques sont collectées et pouvoir diagnostiquer les problèmes. La commande clé est serverStatus, qui fournit une multitude de métriques opérationnelles.

Observation en lecture seule :

mongosh --quiet --eval "JSON.stringify(db.serverStatus().opcounters)"

Sortie attendue :

{"insert":100,"query":250,"update":50,"delete":20,"getmore":10,"command":80}

Cela montre les opérations cumulées depuis le démarrage du serveur. Pour voir les taux, vous devez échantillonner deux fois et calculer la différence.

Diagnostic d'un CPU élevé : Vérifiez la métrique globalLock.currentQueue :

mongosh --quiet --eval "JSON.stringify(db.serverStatus().globalLock.currentQueue)"

Si total est constamment élevé (par exemple, > 10), il peut y avoir de la contention de verrous. Corrélez avec serverStatus().locks pour une analyse plus approfondie.

Vérification du retard de réplication (jeux de réplicas uniquement) :

mongosh --quiet --eval "db.printSecondaryReplicationInfo()"

Cela rapporte la fenêtre d'oplog et le retard de réplication pour chaque secondaire. Par exemple :

source: mongo1:27017
    syncedTo: Thu Jan 01 2026 12:00:00 GMT+0000 (UTC)
    0 secs (0 hrs) behind the primary

Signal de défaillance : Si les métriques sont manquantes (par exemple, opcounters est vide), vérifiez si le processus mongod est en cours d'exécution et si l'utilisateur a la permission d'exécuter serverStatus (nécessite le rôle clusterMonitor).

Récupération : Pour les problèmes de permission, accordez le rôle : db.grantRolesToUser("monitorUser", ["clusterMonitor"]).

Modes de défaillance et récupération

La surveillance et les alertes elles-mêmes peuvent échouer. Comprendre les modes de défaillance courants vous aide à concevoir une surveillance résiliente.

1. Fatigue des alertes : Trop d'alertes, dont beaucoup ne sont pas actionnables. Cela se produit lorsque les seuils d'alerte sont trop serrés ou lorsque des alertes sont envoyées pour chaque pic transitoire. Récupérez en examinant les règles d'alerte, en consolidant les alertes similaires et en définissant des seuils plus réalistes (par exemple, CPU > 90 % pendant 10 minutes au lieu de > 80 % pendant 1 minute).

2. Panne du système de surveillance : Si votre système de surveillance (par exemple, Prometheus, Datadog) tombe en panne, vous perdez la visibilité. Récupérez en ayant un moniteur secondaire léger (par exemple, une tâche cron qui vérifie la connectivité et écrit un fichier de pulsation) et en assurant l'alerte pour le système de surveillance lui-même.

3. Retard de collecte des métriques : Si les métriques sont retardées, la réponse aux incidents est compromise. Cela peut être dû à la latence du réseau ou à une charge élevée sur l'agent de surveillance. Vérifiez en consultant les journaux de l'agent et l'horodatage de la métrique la plus récente. Si le retard dépasse 60 secondes, enquêtez sur le processus de l'agent et le réseau.

4. Faux positifs dus à une mauvaise base de référence : Lorsqu'une alerte est basée sur une base de référence obsolète, elle peut se déclencher de manière incorrecte. Récupérez en recalculant les bases de référence périodiquement (par exemple, chaque semaine) à l'aide de données historiques.

5. Expiration des identifiants : Les agents de surveillance utilisent souvent des identifiants de base de données qui expirent. Lorsqu'ils expirent, les métriques cessent de circuler. Récupérez en renouvelant les identifiants avant l'expiration et en utilisant un gestionnaire de secrets.

Liste de contrôle opérationnelle

Cette liste de contrôle combine les étapes clés dans un manuel pour configurer et vérifier la surveillance et les alertes MongoDB. Chaque élément a un propriétaire et une fréquence de révision.

Pièges courants et comment les éviter

Les pièges de la surveillance MongoDB proviennent souvent d'une configuration incorrecte, de permissions insuffisantes ou d'une mauvaise interprétation des métriques. Voici les plus fréquents.

Piège 1 : Surveiller sans rôles utilisateur appropriés

Pourquoi cela arrive : Les nouveaux utilisateurs créent souvent un utilisateur de base de données avec uniquement le rôle read et essaient d'exécuter serverStatus, qui nécessite le rôle clusterMonitor.

Comment éviter : Créez un utilisateur de surveillance dédié avec les rôles clusterMonitor et readAnyDatabase. Exemple :

db.createUser({
  user: "monitorUser",
  pwd: "SecurePass123!",
  roles: [
    { role: "clusterMonitor", db: "admin" },
    { role: "readAnyDatabase", db: "admin" }
  ]
})

Comment récupérer : Si vous rencontrez des erreurs d'autorisation, accordez le rôle manquant : db.grantRolesToUser("monitorUser", ["clusterMonitor"]).

Piège 2 : Ne pas surveiller le retard de réplication

Pourquoi cela arrive : Dans un état d'esprit autonome, les développeurs oublient que les jeux de réplicas peuvent prendre du retard, provoquant des lectures obsolètes et des problèmes de basculement.

Comment éviter : Configurez des alertes pour un retard de réplication > 30 secondes. Utilisez db.printSecondaryReplicationInfo() manuellement ou intégrez un outil de surveillance qui suit replSetGetStatus.members[i].optimeDate.

Comment récupérer : Si le retard est élevé, vérifiez la connectivité réseau du secondaire, la taille de la fenêtre d'oplog et si le secondaire peut suivre la charge d'écriture du primaire. Envisagez d'augmenter la taille de l'oplog ou d'ajouter un secondaire caché pour l'analytique.

Piège 3 : Activer le profilage globalement avec un seuil bas

Pourquoi cela arrive : Dans la quête de requêtes lentes, les équipes activent le profilage sur toutes les bases de données avec slowms: 10, provoquant une surcharge massive et une utilisation excessive du disque.

Comment éviter : Utilisez le profileur de base de données de manière sélective. Préférez slowms: 200 ou plus et définissez sampleRate à une fraction (par exemple, 0,25). Mieux encore, utilisez les journaux MongoDB avec slowms défini au niveau du système, ce qui a une surcharge plus faible.

Comment récupérer : Désactivez le profilage (db.setProfilingLevel(0)) et videz la collection system.profile si elle est devenue trop grande : db.system.profile.drop() (avec prudence).

Piège 4 : Ignorer les métriques au niveau de l'hôte

Pourquoi cela arrive : Les équipes se concentrent uniquement sur les métriques MongoDB et manquent le CPU, la mémoire, les E/S disque et la saturation du réseau sur l'hôte sous-jacent.

Comment éviter : Combinez les métriques MongoDB avec les métriques de l'hôte en utilisant l'exportateur de nœud Prometheus ou la surveillance du fournisseur cloud. Alertez sur le CPU de l'hôte > 85 %, l'utilisation de la mémoire > 90 %, la latence du disque > 20 ms.

Comment récupérer : Si les métriques de l'hôte sont manquantes, installez et configurez l'exportateur approprié. Ensuite, corrélez avec les performances MongoDB pour identifier les goulots d'étranglement des ressources.

Piège 5 : Ne pas tester la livraison des alertes

Pourquoi cela arrive : La configuration semble correcte, mais les alertes échouent silencieusement à atteindre l'équipe d'astreinte.

Comment éviter : Planifiez des tests d'alerte réguliers. La plupart des outils de surveillance ont une fonction « tester l'alerte ». Ayez également un canal de notification secondaire.

Comment récupérer : Si une alerte ne parvient pas à être livrée, vérifiez les paramètres de notification du système de surveillance, les clés API et la sortie réseau. Vérifiez que la rotation d'astreinte est à jour.

Conclusion

La surveillance et les alertes MongoDB avec des exemples pratiques ne sont utiles que lorsque chaque recommandation est liée à une version, observable et réversible là où la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure opérationnelle.

Comme prochaine étape, choisissez une vérification à faible risque pour la surveillance MongoDB : capturez les valeurs actuelles de serverStatus().opcounters et globalLock.currentQueue, enregistrez-les, puis exécutez la même vérification après cinq minutes et calculez les taux. Comparez les taux à votre base de référence et définissez une alerte de seuil.

Un flux de travail technique fiable rend la défaillance visible, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de la récupération avant qu'un incident ne force la décision. En suivant l'approche structurée de cet article, vous pouvez construire un système de surveillance et d'alerte qui vous aide à dormir tranquille.