MongoDB Monitoring: SolarWinds vs New Relic vs Datadog
Nous avons installé SolarWinds, Datadog et New Relic sur des systèmes propres exécutant MongoDB 7.0 pour tester. Nous avons parcouru le processus de configuration complet de chaque outil, en documentant chaque étape et chaque obstacle.
MongoDB Résultats du benchmark des outils de surveillance des performances
Plateforme | Temps de configuration | Analyse des requêtes | Précision des métriques | Utilisation RAM | Idéal pour |
|---|---|---|---|---|---|
5 min | ✅ | 100% précis | Moyenne (500 Mo) | Optimisation de la production | |
New Relic | 15 min | ❌ | Faible (taux d'erreur de 23 à 800 %) | Faible (90 Mo) | Vérifications de santé de base |
Datadog | 20+ min | ❌ | Flou | Moyenne (330 Mo) | Surveillance multi-technologies |
Résumé des performances de surveillance MongoDB
- SolarWinds a terminé la configuration en 5 minutes avec détection automatique et a fourni une analyse au niveau des requêtes que les autres n'avaient pas.
- New Relic a pris 15 minutes avec des étapes de vérification manuelles et a rapporté des métriques inexactes.
- Datadog a nécessité plus de 20 minutes d'édition YAML et n'offrait qu'une visibilité de base.
Vous pouvez également voir comment ces plateformes surveillent MySQL et notre environnement de test et notre méthodologie
1. Expérience d'installation et d'intégration
1. Solarwinds
SolarWinds a terminé l'intégration MongoDB en moins de 5 minutes. Solarwinds s'ouvre avec une simple fenêtre modale : « Que voulez-vous surveiller ? » Lorsque vous sélectionnez les performances de la base de données, la plateforme affiche les bases de données prises en charge dès le début.
Après avoir sélectionné MongoDB, Solarwinds vérifie les agents existants.
La plateforme a immédiatement détecté notre agent précédemment installé.
Une fonctionnalité a retenu notre attention : l'interface affiche les détails de l'agent (système d'exploitation, ID d'instance cloud, version) directement sur l'écran de sélection. Pas besoin de chercher dans les menus déroulants.
Maintenant SolarWinds demande les identifiants MongoDB. Nous avons saisi les détails de connexion : localhost, méthode d'authentification (basée sur le mot de passe), nom d'utilisateur et mot de passe. Le nom d'affichage auto-rempli avec nos informations de serveur, bien qu'il ait utilisé le nom d'hôte interne complet plutôt que le nom d'agent que nous avions spécifié plus tôt.
Une bizarrerie : le menu déroulant « Capture de requête » est apparu sans explication. Nous avons sélectionné « Journal » et avons poursuivi, incertains de ce que faisaient les autres options.
L'écran suivant présentait trois commandes de base de données à exécuter. Chaque commande avait un bouton de copie. Nous les avons exécutées dans MongoDB et avons cliqué sur « Observer la base de données ».
C'est là que Solarwinds nous a impressionnés. Au lieu de nous demander de comprendre les autorisations, il a fourni des commandes à copier-coller :
- Créer un utilisateur de surveillance avec des identifiants spécifiques
- Accorder les privilèges nécessaires (rôles clusterMonitor et readAnyDatabase)
- Définir le niveau de profilage
Un écran de résumé est apparu montrant notre configuration. Le statut du plugin indiquait « Le plugin est en cours de déploiement ».
Quelques secondes plus tard, le statut est passé à « Le déploiement du plugin est réussi » avec un lien pour voir le tableau de bord. Configuration terminée.
Découvrez SolarWinds Observability avec une surveillance MongoDB approfondie et un profilage de requêtes. Explorez SolarWinds.
Visitez le site web2. New Relic
New Relic a pris environ 15 minutes à configurer, mais le temps n'était pas le vrai problème. La friction venait de répondre à des questions que la plateforme aurait déjà dû connaître.
New Relic commence à la page Intégrations et Agents.
Nous avons recherché « mongo » et trouvé plusieurs intégrations liées à MongoDB.
Après avoir sélectionné MongoDB, New Relic nous a demandé de choisir une méthode d'instrumentation.
Nous avons choisi « Sur un hôte » puisque notre agent était déjà installé. L'écran suivant demandait le système d'exploitation. Nous avons sélectionné Linux. Cela semblait inutile puisque l'agent était déjà en cours d'exécution sur le serveur, mais nous avons continué.
L'écran suivant demandait les détails de l'hôte MongoDB. Le terme « SCRAM » est apparu sans explication. La plupart des gens connaissent cela comme une authentification par nom d'utilisateur/mot de passe, mais le terme technique ajoute de la confusion.
Après avoir cliqué sur continuer, New Relic nous a demandé sur quel serveur installer. Cette question aurait dû venir en premier, pas après que nous ayons déjà saisi les détails de configuration. L'agent était déjà installé sur « aimultiple-benchmark », nous l'avons donc sélectionné et continué.
L'écran suivant nous a demandé de vérifier la compatibilité de la version MongoDB. New Relic voulait que nous exécutions mongod --version et confirmions que la sortie correspondait à ses exigences. Nous avons dû copier la commande, passer à notre terminal, l'exécuter, vérifier le numéro de version et revenir cliquer sur continuer.
L'agent est déjà installé sur le serveur. Il aurait pu vérifier cela automatiquement.
Après avoir cliqué sur continuer, nous sommes arrivés à l'étape de création d'utilisateur. New Relic a fourni un script MongoDB pour créer l'utilisateur de surveillance. Les commandes étaient claires, avec des attributions de rôle appropriées (clusterMonitor et readAnyDatabase). Nous avons également dû exécuter une commande de test de connexion pour vérifier que l'utilisateur fonctionnait correctement.
Cette approche était meilleure que de demander l'accès root, mais elle supposait que nous trouverions où exécuter ces commandes.
L'écran suivant nous a demandé d'installer le package d'intégration. Maintenant, New Relic veut que nous installions manuellement en utilisant yum. Même si l'agent est déjà installé sur Ubuntu, l'interface utilise par défaut Amazon Linux et fournit des commandes d'installation yum au lieu de apt. Nous nous attendions à ce que la plateforme détecte le bon système d'exploitation à partir de l'agent installé automatiquement.
Nous avons exécuté la commande apt correcte pour Ubuntu, puis sommes passés à l'écran suivant. New Relic a fourni un fichier de configuration YAML et nous a dit exactement où le mettre : /etc/newrelic-infra/integrations.d/. Au moins le chemin du fichier était clair.
Nous avons créé le fichier, collé la configuration et cliqué sur Continuer. L'écran final affichait un bouton « Tester la connexion ». Nous l'avons cliqué et avons attendu.
Le test a réussi. Configuration terminée.
3. Datadog
Datadog a pris plus de 20 minutes à terminer. L'intégration a fonctionné éventuellement, mais y arriver nécessitait un effort manuel significatif.
Après la connexion, nous sommes allés dans Intégrations et avons recherché « mongo ». Nous avons cliqué sur MongoDB, et une fenêtre modale est apparue.
L'aperçu montrait ce que la surveillance MongoDB incluait, mais cliquer sur « Installer l'intégration » ouvrait simplement un autre écran avec des instructions denses.
C'est là que Datadog nous a accablés. L'écran montrait un guide de référence complet couvrant chaque scénario MongoDB possible : instances autonomes, ensembles de réplicas, clusters fragmentés, méthodes d'authentification, configuration SSL, et plus encore.
Pour quelqu'un qui essaie simplement de surveiller une seule instance MongoDB, le mur de texte semblait excessif.
Nous avons fait défiler à la recherche des étapes de base :
- Créer un utilisateur de surveillance dans MongoDB
- Modifier le fichier de configuration YAML
- Redémarrer l'agent Datadog
Datadog a fourni les commandes MongoDB pour créer l'utilisateur, ce qui était utile. Mais quand il s'agissait du fichier YAML, la documentation disait de modifier conf.yaml sans indiquer clairement où ce fichier devrait aller.
Nous savions par expérience qu'il appartient dans /etc/datadog-agent/conf.d/mongo.d/, mais les instructions ont enfoui ce détail profondément dans la documentation.
Nous avons créé l'utilisateur MongoDB, écrit la configuration YAML, l'avons placée dans le bon répertoire et redémarré l'agent.
Puis nous sommes retournés à l'interface Datadog et avons cliqué sur « Installer l'intégration ».
Le bouton a disparu. Aucun message de confirmation, aucune notification de succès, aucune redirection vers un tableau de bord. Rien.
Nous avons attendu un moment, puis nous sommes rendus manuellement à la section Tableaux de bord et avons trouvé les métriques MongoDB commençant à se remplir.
2. Consommation des ressources de l'agent
Nous avons surveillé la quantité de ressources consommées par chaque agent pendant l'exécution. Le test a duré environ 10 minutes avec les trois agents collectant des données simultanément à partir de la même instance MongoDB sous charge.
Nous avons stressé le système en insérant 2 millions d'enregistrements dans MongoDB en utilisant un script qui générait des données aléatoires. Cela simulait une activité de base de données réelle pendant que nous mesurions l'utilisation des ressources de l'agent.
Consommation CPU
Les trois agents ont utilisé des ressources CPU minimales pendant le test.
- New Relic a affiché la consommation CPU moyenne la plus faible mais a eu des pics occasionnels atteignant 4 %. Ces pics étaient brefs et n'ont pas affecté les performances du système.
- Solarwinds a maintenu l'utilisation CPU la plus cohérente, restant autour de 3 % sans variation significative.
- Datadog se situait au milieu, avec une moyenne légèrement supérieure à 2 % et des performances stables tout au long du test.
Utilisation de la mémoire
L'utilisation de la mémoire a montré des différences plus significatives entre les agents.
New Relic a consommé environ 5 à 6 fois moins de mémoire que Solarwinds. Sur notre serveur de test de 16 Go, cela se traduisait par :
- New Relic : ~90 Mo
- Datadog : ~330 Mo
- Solarwinds : ~500 Mo
Pour la plupart des serveurs de production, ces montants n'importeront pas. Mais si vous exécutez des agents sur des systèmes à ressources limitées ou surveillez des centaines de bases de données, la différence s'accumule.
L'utilisation de la mémoire est restée stable sur les trois agents tout au long du test. Aucune fuite de mémoire ni croissance inattendue ne s'est produite.
E/S disque
L'activité disque variait considérablement entre les agents.
SolarWinds a effectué beaucoup plus de lectures disque que les deux autres agents, environ 40 fois plus que New Relic et 1,5 fois plus que Datadog. Cela suggère que SolarWinds accède aux données stockées localement plus fréquemment, probablement pour ses fonctionnalités de profilage de requêtes.
Datadog a écrit le moins sur le disque, indiquant qu'il met en mémoire tampon moins de données localement avant de les envoyer au cloud.
New Relic a affiché le motif E/S le plus équilibré avec des lectures et des écritures modérées.
Utilisation du réseau
Le trafic réseau a montré la quantité de données que chaque agent envoyait à son backend.
Les trois agents ont envoyé des quantités similaires de données sur le réseau. Datadog a transmis légèrement moins, probablement en raison d'une compression plus agressive ou de taux d'échantillonnage différents.
Le trafic bidirectionnel a du sens, car les agents envoient des métriques et reçoivent des mises à jour de configuration ou des commandes de la plateforme.
Résumé de l'impact des ressources
Aucun de ces agents ne sollicitera votre système. Même sous charge de base de données avec les trois fonctionnant simultanément, la consommation totale de ressources est restée bien en dessous de 10 % pour CPU et mémoire combinés.
New Relic gagne en efficacité mémoire. Solarwinds utilise plus de ressources mais fournit une analyse plus détaillée au niveau des requêtes. Datadog se situe au milieu.
Pour la plupart des cas d'utilisation, ces différences de ressources n'influenceront pas votre décision. Choisissez en fonction des fonctionnalités et de l'utilisabilité, pas de la consommation de ressources.
Ajouter comme source préférée3. Tableaux de bord et capacités de surveillance
Après avoir terminé la configuration, nous devions voir ce que chaque plateforme affichait réellement. Nous avons exécuté la même charge de travail sur les trois : insertion de 2 millions d'enregistrements par lots de 5 000, suivie d'un autre 5 millions d'enregistrements.
Le script utilisait Node.js avec Faker pour générer des noms de données utilisateur aléatoires, des e-mails, des adresses et des numéros de téléphone. Cela nous a donné un ensemble de données réaliste à surveiller.
Pendant que les insertions s'exécutaient, nous avons surveillé la consommation des ressources de l'agent en arrière-plan.
La charge de travail a mis une pression réelle sur MongoDB, ce qui nous a permis de voir comment chaque plateforme capturait et affichait l'activité.
Tableau de bord Solarwinds
Nous avons cliqué sur « Bases de données » dans le menu de gauche et avons immédiatement vu notre instance MongoDB. Un clic, et un tableau de bord complet est apparu.
Le haut de l'écran affichait la santé MongoDB, le temps de réponse moyen, le débit (requêtes par seconde) et le nombre d'erreurs. Le graphique à bulles « Top 10 Service Breakdown » affichait les modèles de requêtes les plus fréquemment utilisés avec leurs comptes et pourcentages.
Les chiffres racontaient une histoire. Le débit montrait 3 requêtes par seconde en moyenne. La ventilation montrait 1 400 opérations d'insertion. Pourquoi 1 400 au lieu de 7 millions ?
Nous avons inséré 7 millions d'enregistrements par lots de 5 000. Cela fait 1 400 opérations par lots. Solarwinds a suivi chaque lot sans en manquer un seul.
L'onglet Profiler affichait les modèles de requêtes avec les temps d'exécution moyens.
Nos requêtes d'insertion prenaient 4 à 5 secondes chacune, ce qui semble élevé jusqu'à ce que vous vous souveniez que chaque requête écrivait 5 000 lignes.
L'onglet Santé montrait tout fonctionnant sans problème.
Nous avons arrêté le service MongoDB pour voir à quelle vitesse Solarwinds le remarquerait. Dans les 30 à 40 secondes, le statut de santé est passé à « Mauvais ».
L'onglet Requêtes fournissait un filtrage avancé. Vous pouviez lister les requêtes qui :
- Renvoyaient des erreurs
- S'exécutaient sans index appropriés
- Répondaient lentement
- Généraient des avertissements
Chaque modèle de requête affichait quand il est apparu pour la première fois, quand il a été exécuté pour la dernière fois, combien d'échantillons ont été capturés et les statistiques d'exécution. Pour le dépannage, ce niveau de détail compte.
L'onglet Alertes nous a permis de créer des alertes spécifiques à MongoDB. Nous avions créé une alerte de mémoire pour l'hôte plus tôt, mais maintenant nous pouvions configurer des notifications spécifiques à la base de données.
L'onglet Ressources affichait les métriques au niveau de l'hôte ainsi que les statistiques MongoDB, CPU, mémoire, disque et réseau. Ce contexte aide à distinguer les problèmes de base de données des problèmes d'infrastructure sous-jacents.
L'onglet Conseillers n'avait pas encore de recommandations, mais il en fournissait pour MySQL dans notre test précédent. Nous nous attendons à ce qu'il propose des suggestions d'optimisation à mesure qu'il collecte plus de données MongoDB.
Mises à jour IA : En octobre 2025, SolarWinds a lancé l'agent IA avec la fonctionnalité AI Query Assist (actuellement en version technique). AI Query Assist analyse les modèles de requêtes de base de données et propose des réécritures optimisées pour améliorer automatiquement les performances. Root Cause Assist (maintenant généralement disponible) génère des analyses de cause racine claires basées sur les alertes et les anomalies pour réduire le temps de dépannage. Une disponibilité plus large de l'agent IA dans le portefeuille SolarWinds est prévue pour 20261 2 .
Tableau de bord New Relic
Nous sommes allés à la section Tableaux de bord, mais aucun tableau de bord MongoDB n'est apparu automatiquement.
Nous avons recherché « mongo » dans le catalogue de tableaux de bord et avons trouvé deux options MongoDB.
Nous avons sélectionné le tableau de bord MongoDB régulier et avons cliqué sur « Configurer MongoDB ».
Cela nous a redirigés vers la configuration de l'intégration MongoDB à nouveau. La plateforme savait déjà que nous avions installé MongoDB, alors pourquoi nous renvoyer à l'installation ? Nous avons cliqué sur « Terminé » et sommes passés au tableau de bord.
Le tableau de bord s'est ouvert complètement vide. « Aucune valeur rapportée pour la vérification de service mongodb.can_connect ».
Nous avons vérifié notre configuration en utilisant newrelic-infra agent configtest.
Lorsque nous avons exécuté la commande newrelic-infra agent configtest pour vérifier les problèmes avec notre configuration, nous avons remarqué que l'intégration_name était défini sur nri-prometheus. Pendant la configuration du tableau de bord, New Relic a affiché deux options MongoDB, dont l'une était la version Prometheus. Rien dans l'interface n'indiquait qu'il s'agissait d'une intégration différente, donc il ne m'aurait jamais venu à l'esprit que j'avais sélectionné celle de Prometheus. Ce n'était pas une erreur de l'utilisateur ; il n'y avait tout simplement pas de guide ou de distinction sur l'interface.
Nous sommes retournés et avons installé le tableau de bord « MongoDB (Prometheus) ».
Cette fois, des données sont apparues.
Mais voici le problème : comment un utilisateur normal pourrait-il comprendre cela ? Le processus d'installation était confus, et maintenant la sélection du tableau de bord ajoutait une autre couche de complexité.
La disposition du tableau de bord semblait étrange. Le haut affichait les informations sur le nombre total de serveurs et de bases de données qui changent une fois par an, mais occupait un espace écran privilégié.
En dessous, « Saturation de connexion » apparaissait en évidence. Cette métrique n'a d'importance que lorsque quelque chose ne va pas. Pourquoi la mettre en haut ?
La section « Opérations de requête » rapportait 11 670 insertions. Le nombre était faux. Nous avons inséré 7 millions d'enregistrements en 1 400 opérations par lots. Le graphique ne correspondait pas à la réalité.
L'onglet Bases de données affichait la taille de la base de données, les nombres d'objets et les tailles d'index. Ces chiffres étaient corrects 7 millions d'objets. New Relic obtient ces données en interrogeant directement MongoDB (« Combien de documents avez-vous ? »). Mais le comptage des requêtes en temps réel a échoué.
L'onglet Collections comprenait des graphiques utiles pour les métriques au niveau de la collection : taille (avec vues tableau et graphique), taille totale avec pourcentage de changement, nombre d'opérations de lecture, latence de lecture, nombre d'opérations d'écriture, latence d'écriture, nombres de transactions, latence des transactions, opérations d'accès aux index, nombres d'exécution de commandes, latence des commandes, fréquence des commandes et durée des commandes.
Notamment absent : les métriques d'hôte. Nous ne pouvions pas voir CPU, mémoire, disque ou utilisation du réseau pour le serveur exécutant MongoDB. SolarWinds incluait ce contexte, mais Datadog, comme New Relic, ne l'incluait pas.
Plus important encore, aucune analyse au niveau des requêtes n'existait nulle part. Aucun modèle de requête, aucun profilage, aucune identification de requête lente, aucune détection d'index manquant. Pour le dépannage de base de données, ces fonctionnalités comptent.
Tableau de bord Datadog
Nous avons cliqué sur « Tableaux de bord » dans le menu de gauche. Un tableau de bord « MongoDB – Aperçu » est apparu automatiquement.
Nous l'avons ouvert, mais il était vide.
Le problème a pris du temps à diagnostiquer. Lors de l'installation, la configuration de découverte automatique de Datadog nécessitait de spécifier quelles bases de données surveiller en utilisant une correspondance de motif. Le motif par défaut ne correspondait pas au nom de notre base de données. Datadog n'a jamais mentionné cela pendant la configuration.
Nous avons changé tous les motifs en .* (correspondre à tout) et avons redémarré l'agent.
Mais pourquoi le tableau de bord était-il complètement vide ? Même sans métriques spécifiques à la base de données, la disponibilité, les nombres de connexions et les statistiques du serveur auraient dû apparaître. Ils ne l'ont pas fait.
Nous avons exécuté datadog-agent check mongo pour déboguer. Le fichier de configuration avait une erreur d'indentation. L'exigence de formatage stricte de YAML nous a pris au piège. Après l'avoir corrigée et relancé notre test de charge avec 5 millions d'insertions, les données sont enfin apparues.
Nous avons immédiatement rencontré des problèmes avec le tableau de bord. La section Journaux affichait « Non accessible » même si nous avions configuré la collecte de journaux dans notre fichier YAML. Le processus de configuration de Datadog rapportait que tout allait bien, mais les journaux ne fonctionnaient toujours pas.
La disposition du tableau de bord n'avait guère de sens pour notre cas d'utilisation. La section supérieure se concentrait sur les statistiques de fragmentation. Nous n'exécutions pas de cluster fragmenté. Le milieu affichait les métriques d'ensemble de réplicas. Nous n'avions pas d'ensembles de réplicas. Le bas revenait à la fragmentation. Environ 60 % du tableau de bord affichait des sections vides pour les fonctionnalités que nous n'utilisions pas.
Les informations utiles occupaient peut-être 40 % de l'écran : disponibilité, utilisation de la mémoire, E/S réseau, requêtes par seconde et latence de lecture/écriture. Aucune analyse de requête, aucun profilage, aucune détection de requête lente, aucune recommandation d'index.
Nous ne pouvions même pas déterminer combien d'opérations s'exécutaient à partir de ce tableau de bord.
Environnement de test et méthodologie
Nous avons exécuté les trois outils sur des configurations identiques pour assurer une comparaison équitable. Chaque test a utilisé :
- Base de données : MongoDB 7.0 Édition communautaire
- Serveur : Instance AWS m6i.xlarge
- Point de départ : Installation fraîche avec l'agent de surveillance principal déjà installé
Les trois fournisseurs vous obligent à installer leur agent de base avant d'ajouter des intégrations spécifiques, telles que MongoDB. Nous avons terminé cette étape auparavant, donc notre test s'est concentré uniquement sur l'expérience d'intégration MongoDB.
Ce que nous avons mesuré :
- Complexité de configuration : Nombre d'étapes manuelles, configuration automatique versus manuelle, clarté des instructions et si l'interface nous guidait ou nous laissait chercher les prochaines étapes.
- Consommation des ressources de l'agent : CPU, mémoire, E/S disque et utilisation du réseau pendant l'inactivité et sous charge (insertion de 7 millions d'enregistrements).
- Capacités de surveillance : Qualité du tableau de bord, précision des métriques, analyse au niveau des requêtes et fonctionnalités de dépannage.
Considérations de sécurité
Une vulnérabilité grave nommée « MongoBleed » a été divulguée, affectant les versions du serveur MongoDB antérieures à 8.0.17, 7.0.28, 6.0.27 et antérieures. Cette vulnérabilité de lecture hors limites non authentifiée pourrait permettre aux attaquants d'accéder à des données mémoire sensibles. Les organisations exécutant MongoDB doivent immédiatement mettre à jour vers des versions corrigées : 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 ou 4.4.303 4 . Lors de la sélection d'outils de surveillance, assurez-vous qu'ils prennent en charge des méthodes d'authentification sécurisées et n'introduisent pas de risques de sécurité supplémentaires.
Nous avons abordé chaque outil comme le ferait un utilisateur ordinaire, sans lire la documentation au préalable et sans formation préalable. Si quelque chose n'était pas évident dans l'interface, nous l'avons noté.
Verdict final
Nous nous sommes lancés pour répondre à une question simple : quelle plateforme de surveillance rend l'intégration MongoDB la plus facile pour les équipes non techniques ?
Après avoir installé les trois, exécuté des charges de travail identiques et évalué les tableaux de bord, la réponse est devenue claire. Notre évaluation est basée sur l'intégration de base MongoDB de Datadog en janvier 2025. Datadog a depuis lancé Database Monitoring (DBM) pour MongoDB (décembre 2024), qui fournit des capacités significativement plus approfondies, y compris le profilage des requêtes, l'analyse des opérations lentes, les plans d'explication et la surveillance de la réplication. Le produit DBM répond à de nombreuses limitations identifiées dans ce benchmark5 .
Solarwinds : Conçu pour la surveillance de base de données
SolarWinds a remporté cette comparaison de manière décisive. La plateforme a immédiatement détecté notre agent, nous a guidés à travers la configuration des identifiants via des commandes copier-coller et a automatiquement déployé l'intégration. La configuration a pris 5 minutes.
Le tableau de bord est apparu instantanément avec des informations pertinentes. Le profilage des requêtes montrait exactement quelles opérations consommaient le plus de ressources. La plateforme a capturé toutes les 1 400 opérations par lots sans en manquer une seule. Lorsque nous avons arrêté MongoDB, SolarWinds a détecté l'échec dans les 40 secondes.
L'onglet Requêtes nous permet de filtrer par erreurs, index manquants, réponses lentes et fonctionnalités d'avertissement qui soutiennent directement l'optimisation de la base de données. La fonctionnalité Conseillers était censée fournir des recommandations (bien que nous n'ayons pas généré suffisamment de données pour en déclencher pendant notre test).
Solarwinds s'est concentré sur ce dont les administrateurs de bases de données ont réellement besoin : analyse des requêtes, profilage des performances et informations exploitables.
New Relic : Perdu dans la configuration
New Relic a pris 15 minutes à configurer, mais le temps n'était pas le principal problème. La plateforme posait des questions dans le mauvais ordre, nécessitait une vérification manuelle de choses que l'agent aurait pu vérifier automatiquement et nous forçait à installer manuellement des packages.
La confusion du tableau de bord a empiré les choses. Nous avons installé la surveillance MongoDB, mais la sélection du tableau de bord par défaut a abouti à un écran vide. Ce n'est qu'en fouillant dans les fichiers de configuration que nous avons réalisé que nous avions sélectionné le mauvais type d'intégration. Un utilisateur ordinaire ne comprendrait pas cela.
Lorsque les données sont enfin apparues, les métriques étaient fausses. New Relic a rapporté 11 670 insertions après que nous ayons effectué 1 400 opérations par lots, totalisant 7 millions d'enregistrements. La plateforme a sous-compté d'un ordre de grandeur.
Plus important encore, New Relic ne fournissait aucune analyse au niveau des requêtes. Aucun profilage, aucune détection de requête lente, aucune identification d'index manquant. Pour le dépannage de base de données, ces omissions comptent.
Datadog : Travail manuel requis
Datadog a nécessité plus de 20 minutes de configuration et la configuration manuelle la plus importante. Nous avons édité les fichiers YAML, déterminé où les placer et redémarré les services depuis la ligne de commande.
Le tableau de bord est apparu automatiquement mais n'affichait rien. La configuration de découverte automatique utilisait un motif qui ne correspondait pas à notre base de données. Après avoir corrigé le motif et corrigé les erreurs d'indentation YAML, les données ont enfin été remplies.
Le tableau de bord lui-même s'est avéré mal conçu pour une instance unique MongoDB. Soixante pour cent de l'écran était vide, avec des sections pour la fragmentation et les ensembles de réplicas – fonctionnalités que nous n'utilisions pas. Les 40 % restants offraient des métriques de base : disponibilité, mémoire, E/S réseau, requêtes par seconde et latence.
Aucune analyse de requête. Aucun profilage. Aucune recommandation d'optimisation. Nous ne pouvions pas déterminer avec précision les nombres d'opérations sur le tableau de bord.
Aucune analyse de requête. Aucun profilage. Aucune recommandation d'optimisation. Nous ne pouvions pas déterminer avec précision les nombres d'opérations sur le tableau de bord.
Mise à jour critique (décembre 2024) : Après l'achèvement de ce benchmark, Datadog a lancé Database Monitoring (DBM) pour MongoDB, ce qui change considérablement cette évaluation. DBM pour MongoDB fournit désormais :
- Analyse des opérations lentes avec des échantillons de requêtes détaillés
- Plans d'explication pour l'optimisation des requêtes
- Surveillance de l'état de réplication et visualisation de la santé du cluster
- Informations au niveau de l'opération et identification des goulots d'étranglement de performance
- Intégration avec la surveillance des performances des applications pour un dépannage unifié
DBM représente une amélioration substantielle par rapport à l'intégration MongoDB de base testée dans ce benchmark et comprend de nombreuses fonctionnalités d'analyse au niveau des requêtes qui étaient absentes pendant nos tests6 7 . Les organisations évaluant Datadog pour la surveillance MongoDB devraient spécifiquement évaluer le produit Database Monitoring plutôt que l'intégration de base testée ici.
Quel outil de surveillance de base de données fonctionne réellement lorsque vous n'êtes pas un expert DevOps ?
L'expérience de configuration
SolarWinds s'est ouvert avec une fenêtre modale demandant ce que vous voulez surveiller. Vous choisissez « performances de base de données », sélectionnez MongoDB, et la plateforme trouve immédiatement l'agent que vous avez déjà installé, vous montrant le système d'exploitation, l'ID d'instance cloud et le numéro de version directement sur l'écran de sélection. Ensuite, il vous donne trois commandes à copier-coller à exécuter dans MongoDB, gère les identifiants et confirme le déploiement. Cinq minutes, du début à la fin.
New Relic a pris quinze minutes, et le temps n'était même pas le vrai problème. L'interface continuait de poser des questions que l'agent aurait pu répondre lui-même, comme quel système d'exploitation et quelle version MongoDB, bien que l'agent soit déjà sur le serveur. À un moment donné, il utilisait par défaut des commandes d'installation Amazon Linux, même si nous exécutions clairement Ubuntu. L'étape qui a finalement brisé l'expérience : il y a deux options d'intégration MongoDB dans le catalogue de tableaux de bord, une standard et une basée sur Prometheus, et rien dans l'interface ne les distingue. Nous avons choisi la mauvaise, obtenu un tableau de bord vide et ne l'avons compris qu'en fouillant dans les fichiers de configuration.
Datadog a nécessité plus de vingt minutes d'édition YAML, de devinages de chemins de fichiers et de redémarrage de services depuis la ligne de commande. La documentation offerte pendant la configuration n'est pas un guide ; c'est un manuel de référence complet couvrant les instances autonomes, les ensembles de réplicas, les clusters fragmentés et la configuration SSL, tous à la fois, pour quelqu'un qui veut simplement surveiller une base de données. Lorsque les données sont enfin apparues, le tableau de bord commençait par les statistiques de fragmentation et les métriques d'ensemble de réplicas. Nous n'avions ni l'un ni l'autre. Environ soixante pour cent de l'écran était vide.
Précision des métriques sous charge
SolarWinds a compté 1 400. Exactement correct. New Relic a rapporté 11 670, faux d'un ordre de grandeur sans explication évidente, et a manqué un pic de mémoire pendant le test. Lorsque nous avons arrêté le service MongoDB, SolarWinds a détecté l'échec dans les trente à quarante secondes.
Sur la consommation de ressources : New Relic utilisait environ 90 Mo de RAM, Datadog environ 330 Mo et SolarWinds environ 500 Mo sur notre serveur de 16 Go. SolarWinds a effectué environ quarante fois plus de lectures disque que New Relic, probablement en raison du travail de profilage de requêtes local. Pour la plupart des environnements, rien de cela ne déterminera votre décision.
La fonctionnalité qui les sépare réellement
Chaque outil de surveillance vous dira que quelque chose est lent. La question est de savoir s'il vous dit pourquoi.
SolarWinds offre un profilage au niveau des requêtes. L'onglet Profiler montrait exactement quels modèles de requêtes s'exécutaient, combien de temps chacun prenait et combien d'échantillons ont été capturés. Vous pouvez filtrer par les requêtes qui se sont exécutées sans index, ont renvoyé des erreurs ou généré des avertissements.
New Relic et Datadog n'affichaient que des métriques agrégées pour la latence, les nombres de connexions et les totaux d'opérations. Aucun profilage, aucune identification de requête lente, aucune détection d'index manquant. Pour confirmer qu'une base de données est en vie, faisable. Pour diagnostiquer pourquoi elle lutte, une impasse.
Note : Datadog a lancé un produit Database Monitoring pour MongoDB en décembre 2024, après nos tests, qui ajoute l'analyse des opérations lentes, les plans d'explication et la visibilité au niveau des requêtes. Nous avons testé l'intégration standard, qui reste ce que la plupart des utilisateurs rencontrent en premier.
SolarWinds : Si l'optimisation de base de données est votre véritable préoccupation. Métriques précises, configuration rapide et la seule plateforme ici qui vous dit non seulement qu'une requête est lente mais quoi faire à ce sujet.
New Relic : Si vous l'utilisez déjà pour APM et avez besoin de la santé de base de données de base au même endroit. Retracer une requête lente du navigateur à travers le code jusqu'à l'appel de base de données est vraiment utile. Ne comptez pas sur elle pour des comptes d'opérations précis.
Datadog : Si vous êtes à l'aise avec la configuration manuelle et voulez une plateforme unique sur une pile complexe. Les plus de 600 intégrations justifient la friction de configuration pour la bonne équipe.
Citer cette recherche
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{dogan2026,
author = {Dogan, Sedat and Sezer, Sena},
title = {{MongoDB Monitoring: SolarWinds vs New Relic vs Datadog}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/mongodb-monitoring}},
note = {AIMultiple. Consulté le 12 Juin 2026}
}Liens de référence
![Écran de test de connexion affichant le statut « Non testé »]](https://aimultiple.com/wp-content/uploads/2025/12/11.png.webp "Écran de test de connexion affichant le statut « Non testé »]")
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.