MongoDB Supervision: 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 les tester. Nous avons suivi le processus de configuration complet de chaque outil, en documentant chaque étape et chaque obstacle.
MongoDB : résultats du benchmark des outils de supervision des performances
Plateforme | Temps d'installation | Profilage des requêtes | Précision des métriques | RAM Utilisation | Idéal pour |
|---|---|---|---|---|---|
5 min | ✓ | 100 % précis | Moyenne (500MB) | Optimisation de la production | |
New Relic | 15 min | ✕ | Faible (taux d'erreur de 23 à 800 %) | Faible (90MB) | Contrôles de santé de base |
Datadog | 20+ min | ✕ | Incertaine | Moyenne (330MB) | Supervision multi-technologies |
MongoDB : synthèse des performances de supervision
- SolarWinds a terminé l'installation en 5 minutes avec une détection automatique et a fourni un profilage au niveau des requêtes que les autres n'ont pas offert.
- New Relic a pris 15 minutes avec des étapes de vérification manuelle et a rapporté des métriques inexactes.
- Datadog a nécessité 20+ minutes d'édition YAML et n'a offert qu'une visibilité de base.
Vous pouvez également voir comment ces plateformes supervisent 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 de MongoDB en moins de 5 minutes. SolarWinds s'ouvre avec une simple fenêtre modale : « Que souhaitez-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'emblée.
Après avoir sélectionné MongoDB, SolarWinds recherche les agents existants.
La plateforme a immédiatement détecté notre agent précédemment installé.
Une fonctionnalité s'est démarquée : 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 de recherche dans des menus déroulants.
Maintenant, SolarWinds demande les identifiants de MongoDB. Nous avons saisi les détails de connexion : localhost, méthode d'authentification (par mot de passe), nom d'utilisateur et mot de passe. Le nom d'affichage a été auto-rempli avec les informations de notre 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é précédemment.
Une bizarrerie : le menu déroulant « Capture des requêtes » est apparu sans explication. Nous avons sélectionné « Journal » et avons continué, sans savoir 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 copier. 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 déterminer 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 a réussi » avec un lien pour afficher le tableau de bord. Installation terminée.
Découvrez l'observabilité de SolarWinds avec une supervision approfondie de MongoDB et le profilage des requêtes. Explorez SolarWinds.
Visitez le site web2. New Relic
New Relic a pris environ 15 minutes à installer, mais ce n'était pas le vrai problème. Les frictions venaient de réponses à des questions que la plateforme aurait déjà dû connaître.
New Relic commence sur la page Intégrations et agents.
Nous avons recherché « mongo » et avons 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 » car 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 sous le nom d'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 l'installer. Cette question aurait dû venir en premier, et non après avoir déjà saisi les détails de configuration. L'agent était déjà installé sur « aimultiple-benchmark », nous l'avons donc sélectionné et avons continué.
L'écran suivant nous a demandé de vérifier la compatibilité de la version de MongoDB. New Relic voulait que nous exécutions mongod --version et que nous 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, puis revenir cliquer sur continuer.
L'agent est déjà installé sur le serveur. Il pourrait vérifier cela automatiquement.
Après avoir cliqué sur continuer, nous sommes arrivés à l'étape de création de l'utilisateur. New Relic a fourni un script MongoDB pour créer l'utilisateur de surveillance. Les commandes étaient claires, avec des attributions de rôles 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 un accès root, mais elle supposait que nous trouverions où exécuter ces commandes.
L'écran suivant nous demandait d'installer le paquet d'intégration. New Relic voulait maintenant que nous l'installions manuellement à l'aide de yum. Même si l'agent est déjà installé sur Ubuntu, l'interface est définie par défaut sur Amazon Linux et fournit des commandes d'installation yum au lieu d'apt. Nous attendions à ce que la plateforme détecte automatiquement le bon système d'exploitation à partir de l'agent installé.
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 indiqué exactement où le placer : /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 avons cliqué dessus et avons attendu.
Le test a réussi. Installation terminée.
3. Datadog
Datadog a pris plus de 20 minutes pour terminer. L'intégration a fini par fonctionner, mais y parvenir a nécessité un effort manuel important.
Après nous être connectés, 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 comprend la supervision de MongoDB, mais cliquer sur « Installer l'intégration » ouvrait simplement un autre écran avec des instructions denses.
C'est là que Datadog nous a submergés. L'écran affichait un guide de référence complet couvrant tous les scénarios MongoDB possibles : instances autonomes, jeux de réplicas, clusters fragmentés, méthodes d'authentification, configuration SSL, et plus encore.
Pour quelqu'un qui essaie simplement de superviser une seule instance MongoDB, le mur de texte semblait excessif.
Nous avons fait défiler la page à 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 en ce qui concerne le fichier YAML, la documentation disait de modifier conf.yaml sans indiquer clairement où ce fichier devait aller.
Nous savions par expérience qu'il appartient à /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 avons redémarré l'agent.
Ensuite, 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 réussite, aucune redirection vers un tableau de bord. Rien.
Nous avons attendu un instant, puis avons navigué manuellement vers la section Tableaux de bord et avons constaté que les métriques MongoDB commençaient à apparaître.
2. Consommation des ressources des agents
Nous avons surveillé la quantité de ressources consommée par chaque agent pendant son exécution. Le test a duré environ 10 minutes, les trois agents collectant simultanément des données de la même instance MongoDB en charge.
Nous avons sollicité le système en insérant 2 millions d'enregistrements dans MongoDB à l'aide d'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 des agents.
CPU : consommation
Les trois agents ont utilisé des ressources CPU minimales pendant le test.
- New Relic a montré 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 régulière, se maintenant autour de 3 % sans variation significative.
- Datadog s'est situé au milieu, avec une moyenne d'un peu plus de 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 à 6x moins de mémoire que SolarWinds. Sur notre serveur de test de 16GB, cela se traduisait par :
- New Relic : ~90MB
- Datadog : ~330MB
- SolarWinds : ~500MB
Pour la plupart des serveurs de production, ces quantités n'auront pas d'importance. Mais si vous exécutez des agents sur des systèmes aux ressources limitées ou si vous supervisez des centaines de bases de données, la différence s'accumule.
L'utilisation de la mémoire est restée stable pour les trois agents tout au long du test. Aucune fuite de mémoire ni croissance inattendue n'est survenue.
E/S disque
L'activité du disque a considérablement varié entre les agents.
SolarWinds a effectué nettement plus de lectures disque que les deux autres agents, environ 40x plus que New Relic et 1.5x plus que Datadog. Cela suggère que SolarWinds accède plus fréquemment aux données stockées localement, probablement pour ses fonctionnalités de profilage des requêtes.
Datadog a le moins écrit sur le disque, ce qui indique qu'il met en mémoire tampon moins de données localement avant de les envoyer dans le cloud.
New Relic a montré le modèle d'E/S le plus équilibré avec des lectures et des écritures modérées.
Utilisation du réseau
Le trafic réseau a montré combien de données chaque agent envoyait à son backend.
Les trois agents ont envoyé des quantités similaires de données sur le réseau. Datadog en a transmis légèrement moins, peut-être en raison d'une compression plus agressive ou de taux d'échantillonnage différents.
Le trafic bidirectionnel est logique, car les agents envoient des métriques et reçoivent des mises à jour de configuration ou des commandes de la plateforme.
Synthèse de l'impact sur les ressources
Aucun de ces agents ne sollicitera excessivement votre système. Même en charge de base de données avec les trois agents exécutés simultanément, la consommation totale des ressources est restée bien en dessous de 10 % pour l'ensemble CPU et mémoire.
New Relic l'emporte sur l'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 la convivialité, et non de la consommation des ressources.
3. Tableau de bord et capacités de supervision
Après avoir terminé l'installation, nous devions voir ce que chaque plateforme affiche 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, suivis de 5 millions d'enregistrements supplémentaires.
Le script utilisait Node.js avec Faker pour générer des données utilisateur aléatoires : noms, e-mails, adresses et numéros de téléphone. Cela nous a donné un jeu de données réaliste à superviser.
Pendant l'exécution des insertions, nous avons surveillé la consommation des ressources des agents en arrière-plan.
La charge de travail a exercé 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é de MongoDB, le temps de réponse moyen, le débit (requêtes par seconde) et le nombre d'erreurs. Le graphique à bulles « Top 10 des services » 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 affichait 3 requêtes par seconde en moyenne. La répartition 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 représente 1 400 opérations par lot. 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 l'on se souvienne que chaque requête écrivait 5 000 lignes.
L'onglet Santé montrait que tout fonctionnait correctement.
Nous avons arrêté le service MongoDB pour voir à quelle vitesse SolarWinds le remarquerait. En 30 à 40 secondes, l'état de santé est passé à « Mauvais ».
L'onglet Requêtes offrait un filtrage avancé. Vous pouviez lister les requêtes qui :
- Ont renvoyé des erreurs
- Ont été exécutées sans index appropriés
- Ont répondu lentement
- Ont généré des avertissements
Chaque modèle de requête affichait sa première apparition, sa dernière exécution, le nombre d'échantillons capturés et les statistiques d'exécution. Pour le dépannage, ce niveau de détail compte.
L'onglet Alertes nous permettait de créer des alertes spécifiques à MongoDB. Nous avions créé une alerte mémoire pour l'hôte auparavant, mais nous pouvions désormais configurer des notifications spécifiques à la base de données.
L'onglet Ressources affichait les métriques au niveau de l'hôte à côté des statistiques MongoDB, du CPU, de la mémoire, du disque et du réseau. Ce contexte aide à distinguer les problèmes de base de données des problèmes d'infrastructure sous-jacente.
L'onglet Conseillers n'avait pas encore de recommandations, mais il en avait fourni pour MySQL lors de notre précédent test. Nous attendons à ce qu'il propose des suggestions d'optimisation à mesure qu'il collectera davantage de données MongoDB.
Mises à jour IA : En octobre 2025, SolarWinds a lancé la fonctionnalité IA Agent avec IA Query Assist (actuellement en aperçu technique). IA 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 (désormais généralement disponible) génère des analyses claires des causes profondes basées sur les alertes et les anomalies afin de réduire le temps de dépannage. Une disponibilité plus large de l'IA Agent dans le portefeuille SolarWinds est prévue pour 202612.
Tableau de bord New Relic
Nous sommes allés dans 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 standard et avons cliqué sur « Configurer MongoDB ».
Cela nous a redirigés à nouveau vers la configuration de l'intégration MongoDB. 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 le contrôle de service mongodb.can_connect ».
Nous avons vérifié notre configuration à l'aide de 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 integration_name était défini sur nri-prometheus. Lors de la configuration du tableau de bord, New Relic affichait 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, il ne me serait donc 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 simplement aucun guidage ni distinction dans l'interface.
Nous sommes revenus en arrière et avons installé le tableau de bord « MongoDB (Prometheus) ».
Cette fois, les données sont apparues.
Mais voici le problème : comment un utilisateur normal pourrait-il comprendre cela ? Le processus d'installation était déroutant, et la sélection du tableau de bord ajoutait une autre couche de complexité.
La disposition du tableau de bord semblait étrange. Le haut affichait des informations sur le nombre total de serveurs et de bases de données qui changent une fois par an, mais occupait un espace précieux à l'écran.
En dessous, « Saturation des connexions » apparaissait en évidence. Cette métrique n'a d'importance que lorsque quelque chose ne va pas. Pourquoi la placer en haut ?
La section « Opérations de requête » a rapporté 11 670 insertions. Le nombre était faux. Nous avons inséré 7 millions d'enregistrements en 1 400 opérations par lot. Le graphique ne correspondait pas à la réalité.
L'onglet Bases de données affichait la taille de la base, le nombre d'objets et la taille des 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 des collections : taille (avec vues tableau et graphique), taille totale avec variation en pourcentage, nombre d'opérations de lecture, latence de lecture, nombre d'opérations d'écriture, latence d'écriture, nombre de transactions, latence des transactions, opérations d'accès aux index, nombre d'exécutions de commandes, latence des commandes, fréquence des commandes et durée des commandes.
Absence notable : les métriques de l'hôte. Nous ne pouvions pas voir l'utilisation du CPU, de la mémoire, du disque ou du réseau pour le serveur exécutant MongoDB. SolarWinds incluait ce contexte, mais Datadog, comme New Relic, ne le faisait 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 des requêtes lentes, aucune détection d'index manquant. Pour le dépannage de base de données, ces fonctionnalités comptent.
Datadog : tableau de bord
Nous avons cliqué sur « Tableaux de bord » dans le menu de gauche. Un tableau de bord « MongoDB – Vue d'ensemble » est apparu automatiquement.
Nous l'avons ouvert, mais il était vide.
Le problème a mis du temps à être diagnostiqué. Lors de l'installation, la configuration d'autodécouverte de Datadog exigeait de spécifier les bases de données à superviser à l'aide d'une correspondance de modèle. Le modèle par défaut ne correspondait pas au nom de notre base de données. Datadog ne l'a jamais mentionné lors de l'installation.
Nous avons changé tous les modèles en .* (tout correspondre) 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é, le nombre de connexions et les statistiques du serveur auraient dû apparaître. Ils n'apparaissaient pas.
Nous avons exécuté datadog-agent check mongo pour déboguer. Le fichier de configuration présentait une erreur d'indentation. L'exigence de formatage stricte de YAML nous a piégés. Après l'avoir corrigée et relancé notre test de charge avec 5 millions d'insertions, les données sont finalement 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 des journaux dans notre fichier YAML. Le processus d'installation de Datadog indiquait 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 des métriques de jeux de réplicas. Nous n'avions pas de jeux de réplicas. Le bas revenait à nouveau à la fragmentation. Environ 60 % du tableau de bord affichait des sections vides pour des 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 en lecture/écriture. Aucune analyse de requête, aucun profilage, aucune détection de requêtes lentes, aucune recommandation d'index.
Nous ne pouvions même pas déterminer combien d'opérations s'étaient exécutées à partir de ce tableau de bord.
MongoDB : environnement et méthodologie du test de benchmark de supervision
Nous avons exécuté les trois outils sur des configurations identiques pour garantir une comparaison équitable. Chaque test utilisait :
- Base de données : MongoDB 7.0 Community Edition
- Serveur : instance AWS m6i.xlarge
- Point de départ : installation fraîche avec l'agent de supervision principal déjà installé
Les trois fournisseurs exigent d'installer leur agent de base avant d'ajouter des intégrations spécifiques, telles que MongoDB. Nous avons effectué cette étape au préalable, notre test s'est donc concentré uniquement sur l'expérience d'intégration de MongoDB.
Ce que nous avons mesuré :
- Complexité de l'installation : nombre d'étapes manuelles, configuration automatique ou manuelle, clarté des instructions, et si l'interface nous guidait ou nous laissait chercher les étapes suivantes.
- Consommation des ressources des agents : CPU, mémoire, E/S disque et utilisation du réseau au repos et en charge (insertion de 7 millions d'enregistrements).
- Capacités de supervision : 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 de MongoDB Server 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 à des attaquants d'accéder à des données sensibles en mémoire. Les organisations exécutant MongoDB doivent immédiatement mettre à jour vers les versions corrigées : 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 ou 4.4.3034. Lors de la sélection des outils de supervision, 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 apparent dans l'interface, nous le notions.
Ajouter comme source préféréeMongoDB : verdict final du benchmark de supervision
Nous avons cherché à répondre à une question simple : quelle plateforme de supervision facilite le plus l'intégration de MongoDB 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 de Datadog pour MongoDB en janvier 2025. Datadog a depuis lancé Database Monitoring (DBM) pour MongoDB (décembre 2024), qui offre des capacités nettement plus approfondies, notamment le profilage des requêtes, l'analyse des opérations lentes, les plans d'exécution et la surveillance de la réplication. Le produit DBM corrige bon nombre des limites identifiées dans ce benchmark5.
SolarWinds : conçu pour la supervision des bases 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 dans la configuration des identifiants via des commandes à copier-coller, et a déployé automatiquement l'intégration. L'installation 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 lot sans en manquer aucune. Lorsque nous avons arrêté MongoDB, SolarWinds a détecté la défaillance en 40 secondes.
L'onglet Requêtes nous permet de filtrer par erreurs, index manquants, réponses lentes et avertissements, des fonctionnalités qui soutiennent directement l'optimisation de la base de données. La fonctionnalité Conseillers devait 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 : l'analyse des requêtes, le profilage des performances et des informations exploitables.
New Relic : perdu dans la configuration
New Relic a pris 15 minutes à installer, mais le temps n'était pas le principal problème. La plateforme posait des questions dans le mauvais ordre, exigeait une vérification manuelle de choses que l'agent pouvait vérifier automatiquement, et nous a obligés à installer manuellement des paquets.
La confusion du tableau de bord a aggravé les choses. Nous avons installé la supervision de MongoDB, mais la sélection du tableau de bord par défaut a abouti à un écran vide. Ce n'est qu'après avoir fouillé 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 finalement apparues, les métriques étaient fausses. New Relic a rapporté 11 670 insertions après que nous avons effectué 1 400 opérations par lot, totalisant 7 millions d'enregistrements. La plateforme a sous-estimé d'un ordre de grandeur.
Plus critique encore, New Relic n'a fourni aucune analyse au niveau des requêtes. Aucun profilage, aucune détection des requêtes lentes, aucune identification des index manquants. Pour le dépannage de base de données, ces omissions comptent.
Datadog : travail manuel requis
Datadog a nécessité 20+ minutes d'installation et le plus de configuration manuelle. Nous avons modifié les fichiers YAML, déterminé où les placer et redémarré les services à partir de la ligne de commande.
Le tableau de bord est apparu automatiquement mais n'affichait rien. La configuration d'autodécouverte utilisait un modèle qui ne correspondait pas à notre base de données. Après avoir corrigé le modèle et les erreurs d'indentation YAML, les données ont finalement été renseignées.
Le tableau de bord lui-même s'est avéré mal conçu pour un MongoDB à instance unique. Soixante pour cent de l'écran était vide, avec des sections pour la fragmentation et les jeux de réplicas 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 le nombre 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 le nombre d'opérations sur le tableau de bord.
Mise à jour critique (décembre 2024) : après la réalisation de ce benchmark, Datadog a lancé Database Monitoring (DBM) pour MongoDB, ce qui modifie considérablement cette évaluation. DBM pour MongoDB offre désormais :
- Analyse des opérations lentes avec des échantillons de requêtes détaillés
- Plans d'exécution pour l'optimisation des requêtes
- Surveillance de l'état de la réplication et visualisation de la santé du cluster
- Informations au niveau des opérations et identification des goulets d'étranglement des performances
- Intégration avec la surveillance des performances des applications pour un dépannage unifié
DBM représente une mise à niveau substantielle par rapport à l'intégration de base de MongoDB testée dans ce benchmark et inclut bon nombre des fonctionnalités d'analyse au niveau des requêtes qui étaient absentes lors de nos tests56. Les organisations évaluant Datadog pour la supervision de MongoDB doivent spécifiquement évaluer le produit Database Monitoring plutôt que l'intégration de base testée ici.
Quel outil de supervision de base de données fonctionne réellement lorsque vous n'êtes pas un expert DevOps ?
L'expérience d'installation
SolarWinds s'ouvre avec une fenêtre modale demandant ce que vous souhaitez surveiller. Vous choisissez « performances de la base de données », sélectionnez MongoDB, et la plateforme trouve immédiatement l'agent que vous avez déjà installé, affichant le système d'exploitation, l'ID d'instance cloud et le numéro de version directement sur l'écran de sélection. Ensuite, elle 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 n'arrêtait pas de poser des questions auxquelles l'agent aurait pu répondre lui-même, comme le système d'exploitation et la version de MongoDB, alors que l'agent était déjà sur le serveur. À un moment donné, elle proposait par défaut des commandes d'installation d'Amazon Linux, alors que nous utilisions 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, l'une standard et l'autre 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 suppositions sur les chemins de fichiers et de redémarrages de services depuis la ligne de commande. La documentation proposée lors de l'installation n'est pas un guide ; c'est un manuel de référence complet couvrant les instances autonomes, les jeux de réplicas, les clusters fragmentés et la configuration SSL, tout à la fois, pour quelqu'un qui veut simplement superviser une base de données. Lorsque les données sont finalement apparues, le tableau de bord commençait par les statistiques de fragmentation et les métriques de jeux de réplicas. Nous n'avions ni l'une ni l'autre. Environ soixante pour cent de l'écran était vide.
Précision des métriques en charge
SolarWinds a compté 1 400. Exactement juste. New Relic a rapporté 11 670, faux d'un ordre de grandeur sans explication évidente, et a complètement manqué un pic de mémoire pendant le test. Lorsque nous avons arrêté le service MongoDB, SolarWinds a détecté la défaillance en trente à quarante secondes.
Concernant la consommation des ressources : New Relic utilisait environ 90MB de RAM, Datadog environ 330MB, et SolarWinds environ 500MB sur notre serveur de 16GB. SolarWinds a effectué environ quarante fois plus de lectures disque que New Relic, probablement en raison du travail local de profilage des requêtes. Pour la plupart des environnements, rien de tout cela n'influencera votre décision.
La fonctionnalité qui les distingue réellement
Tout outil de supervision 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 étaient capturés. Vous pouvez filtrer par les requêtes qui se sont exécutées sans index, ont renvoyé des erreurs ou ont généré des avertissements.
New Relic et Datadog n'affichaient que des métriques agrégées pour la latence, le nombre de connexions et les totaux d'opérations. Aucun profilage, aucune identification des requêtes lentes, aucune détection d'index manquant. Pour confirmer qu'une base de données est en vie, c'est acceptable. Pour diagnostiquer pourquoi elle peine, c'est 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'exécution 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 la base de données est votre véritable préoccupation. Des métriques précises, une installation rapide, et la seule plateforme ici qui vous dit non seulement qu'une requête est lente, mais aussi quoi faire à ce sujet.
New Relic : si vous l'utilisez déjà pour l'APM et avez besoin d'une santé de base de la base de données au même endroit. Tracer une requête lente depuis le navigateur à travers le code jusqu'à l'appel de base de données est réellement utile. Ne comptez pas sur lui pour des comptages d'opérations précis.
Datadog : si vous êtes à l'aise avec la configuration manuelle et souhaitez une plateforme unique sur une pile complexe. Les plus de 600 intégrations justifient les frictions d'installation pour la bonne équipe.
Citez ce benchmark
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 Ermut, Sıla},
title = {{MongoDB Supervision: SolarWinds vs New Relic vs Datadog}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/mongodb-monitoring}},
note = {AIMultiple. Consulté le 16 septembre 2026}
}Résultats et horodatages de 38 points de données. Téléchargez les données de synthèse présentées dans les graphiques et les tableaux de cet article sous forme de fichier ZIP contenant 7 fichiers CSV.
Vous voulez les données détaillées derrière ? Rejoindre Premium
Journal des modifications
5 mises à jourLa section « La différence fondamentale » a été remplacée par « Quel outil de surveillance de base de données fonctionne réellement si vous n'êtes pas un expert DevOps ? ».
Ajout des mises à jour de l'IA à la section SolarWinds.
Ajout des considérations de sécurité à la méthodologie.
Liens de référence
- A 20 ans d’expérience en tant que hacker white-hat et gourou du développement, avec une expertise approfondie des langages de programmation et des architectures de serveurs.
- Est conseiller d’administration auprès d’un VC qui investit dans des entreprises technologiques en phase de démarrage et chez Ödeal, une plateforme de paiement numérique régionale servant 125 000 commerçants.
- A dirigé l’infrastructure technologique et la cybersécurité de sept élections nationales, et a été reconnu au Hall of Fame de la cybersécurité par des leaders technologiques mondiaux dont Twitter.
Elle a précédemment travaillé comme recruteuse dans des cabinets de gestion de projet et de conseil. Sıla est titulaire d’un master en psychologie sociale et d’une licence en relations internationales.
À lire ensuite
Meilleurs fournisseurs de proxy en France: benchmark et tarification
Densité d'intelligence des 71 LLMs pour des modèles plus intelligents et plus denses
Benchmark VPN des 5 meilleurs fournisseurs VPN
Benchmark des modèles tabulaires: performances sur 19 jeux de données
Recherche agentique: benchmark de 8 API de recherche pour les agents
Exécution de code avec MCP: une nouvelle approche de l'efficacité des agents IA
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.