MongoDB Surveillance : SolarWinds vs New Relic vs Datadog
Nous avons installé SolarWinds, Datadog et New Relic sur des systèmes vierges exécutant MongoDB 7.0 à des fins de test. Nous avons suivi l'intégralité du processus d'installation de chaque outil, en documentant chaque étape et chaque difficulté rencontrée.
Résultats des tests de performance des outils de surveillance des performances (MongoDB)
Plate-forme | Temps de préparation | Profilage des requêtes | Précision métrique | Utilisation de la RAM | Idéal pour |
|---|---|---|---|---|---|
5 min | ✅ | 100 % précis | Moyen (500 Mo) | Optimisation de la production | |
New Relic | 15 min | ❌ | Faibles (taux d'erreur de 23 à 800 %) | Faible (90 Mo) | examens de santé de base |
Datadog | 20+ min | ❌ | Peu clair | Moyen (330 Mo) | Surveillance multitechnologique |
MongoDB résumé des performances de surveillance
- SolarWinds a terminé la configuration en 5 minutes avec détection automatique et a fourni un profilage au niveau des requêtes que les autres n'avaient pas.
- New Relic a mis 15 minutes pour effectuer les étapes de vérification manuelle et a signalé des mesures inexactes.
- Datadog nécessitait plus de 20 minutes d'édition YAML et n'offrait qu'une visibilité de base.
Vous pouvez également observer comment ces plateformes surveillent MySQL , notre environnement de test et notre méthodologie.
1. Expérience d'installation et d'intégration
1. Solarwinds
L'intégration de Solarwinds ( SolarWinds ) a été finalisée en moins de 5 minutes. Solarwinds s'ouvre sur une simple fenêtre modale : « Que souhaitez-vous surveiller ? » Lorsque vous sélectionnez « Performances de la base de données », la plateforme affiche directement les bases de données prises en charge.
Après avoir sélectionné MongoDB, Solarwinds vérifie s'il existe des agents.
La plateforme a immédiatement détecté notre agent précédemment installé.
Une fonctionnalité s'est particulièrement démarquée : l'interface affiche les détails de l'agent (système d'exploitation, ID de l'instance cloud, version) directement sur l'écran de sélection. Plus besoin de parcourir des listes déroulantes.
Maintenant, SolarWinds demande les identifiants de MongoDB. Nous avons saisi les informations de connexion : localhost, méthode d'authentification (par mot de passe), nom d'utilisateur et mot de passe. Le nom d'affichage s'est automatiquement rempli avec les informations de notre serveur, mais il a utilisé le nom d'hôte interne complet au lieu du nom d'agent que nous avions spécifié précédemment.
Étrange détail : le menu déroulant « Capture de requête » est apparu sans explication. Nous avons sélectionné « Journal » et continué, sans savoir à quoi servaient les autres options.
L'écran suivant affichait trois commandes de base de données à exécuter. Chaque commande comportait 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 nous débrouiller avec les permissions, il nous 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 récapitulatif affichant notre configuration est apparu. L'état du plugin indiquait « Le plugin est en cours de déploiement ».
Quelques secondes plus tard, le statut est passé à « Déploiement du plugin réussi » avec un lien permettant d'accéder au tableau de bord. Installation terminée.
Découvrez l'observabilité SolarWinds grâce à une surveillance approfondie MongoDB et au profilage des requêtes. Explorez SolarWinds.
Visitez le site web2. Nouvelle relique
L'installation de New Relic a pris environ 15 minutes, mais le temps n'était pas le véritable problème. La difficulté résidait dans le fait de devoir répondre à des questions dont la plateforme aurait dû déjà connaître les réponses.
New Relic commence par 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 sélectionné « Sur un hôte » puisque notre agent était déjà installé. L'écran suivant demandait le système d'exploitation. Nous avons choisi Linux. Cela nous semblait superflu puisque l'agent fonctionnait déjà sur le serveur, mais nous avons poursuivi.
L'écran suivant demandait les informations d'hôte MongoDB. Le terme « SCRAM » est apparu sans explication. La plupart des gens savent qu'il s'agit d'une authentification par nom d'utilisateur et mot de passe, mais ce terme technique ajoute à la confusion.
Après avoir cliqué sur Continuer, New Relic nous a demandé sur quel serveur effectuer l'installation. Cette question aurait dû être posée en premier, et non après la saisie des informations de configuration. L'agent étant déjà installé sur « aimultiple-benchmark », nous l'avons sélectionné et avons poursuivi.
L'écran suivant nous demandait de vérifier la compatibilité de la version MongoDB. New Relic souhaitait que nous exécutions la commande mongod --version et que nous vérifiions que le résultat corresponde à ses exigences. Nous devions copier la commande, ouvrir notre terminal, l'exécuter, vérifier le numéro de version, puis revenir et 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 avons accédé à 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 et les rôles correctement attribués (clusterMonitor et readAnyDatabase). Nous avons également dû exécuter une commande de test de connexion pour vérifier le bon fonctionnement de l'utilisateur.
Cette approche était préférable à la demande d'accès root, mais elle supposait que nous trouverions où exécuter ces commandes.
L'écran suivant nous invitait à installer le package d'intégration. New Relic exigeait alors une installation manuelle via yum. Bien que l'agent soit déjà installé sur Ubuntu, l'interface était configurée par défaut pour Amazon Linux et proposait des commandes d'installation yum au lieu d'apt. Nous nous attendions à ce que la plateforme détecte automatiquement le système d'exploitation approprié à partir de l'agent installé.
Nous avons exécuté la commande apt appropriée pour Ubuntu, puis nous sommes passés à l'écran suivant. New Relic a fourni un fichier de configuration YAML et nous a indiqué précisément où le placer : /etc/newrelic-infra/integrations.d/ . Au moins, le chemin d'accès é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 attendu.
Le test a réussi. Configuration terminée.
3. Datadog
L'opération avec Datadog a pris plus de 20 minutes. L'intégration a finalement fonctionné, mais y parvenir a nécessité un travail manuel considérable.
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 comprenait la surveillance MongoDB, mais cliquer sur « Installer l'intégration » ouvrait simplement un autre écran avec des instructions denses.
C’est là que Datadog nous a impressionnés. L’écran affichait un guide de référence complet couvrant tous les scénarios possibles : instances autonomes, ensembles de réplicas, clusters partitionnés, méthodes d’authentification, configuration SSL, et bien 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 page à la recherche des étapes de base :
- Créer un utilisateur de surveillance dans MongoDB
- Modifiez le fichier YAML de configuration
- Redémarrez l'agent Datadog
Datadog a fourni les commandes MongoDB pour créer l'utilisateur, ce qui s'est avéré utile. Cependant, concernant le fichier YAML, la documentation indiquait de modifier conf.yaml sans préciser clairement son emplacement.
Nous savions par expérience que cela devait se trouver dans /etc/datadog-agent/conf.d/mongo.d/ , mais les instructions avaient 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.
Nous sommes ensuite 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 avons accédé manuellement à la section Tableaux de bord et avons constaté que les indicateurs MongoDB commençaient à se remplir.
2. Consommation des ressources par l'agent
Nous avons surveillé la consommation de ressources de chaque agent pendant son exécution. Le test a duré environ 10 minutes, les trois agents collectant simultanément des données sur la même instance MongoDB sous charge.
Nous avons mis le système à rude épreuve en insérant 2 millions d'enregistrements dans MongoDB à l'aide d'un script générant des données aléatoires. Cela a permis de simuler une activité de base de données réelle, tout en mesurant l'utilisation des ressources de l'agent.
Consommation du processeur
Les trois agents ont utilisé un minimum de ressources CPU pendant le test.
- New Relic a affiché la consommation moyenne de processeur la plus faible, mais a connu des pics occasionnels atteignant 4 %. Ces pics étaient brefs et n'ont pas affecté les performances du système.
- Solarwinds a maintenu l'utilisation du processeur la plus constante, se maintenant autour de 3 % sans variation significative.
- Datadog s'est situé en milieu de tableau, 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 révélé des différences plus significatives entre les agents.
New Relic consommait 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 quantités sont négligeables. Mais si vous exécutez des agents sur des systèmes aux ressources limitées ou si vous surveillez des centaines de bases de données, la différence devient significative.
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 augmentation inattendue n'ont été constatées.
E/S disque
L'activité discale variait considérablement d'un agent à l'autre.
L'agent SolarWinds a effectué un nombre significativement plus élevé 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 plus fréquemment aux données stockées localement, probablement en raison de ses fonctionnalités de profilage des requêtes.
Datadog a écrit le moins de données sur disque, ce qui indique qu'il met en mémoire tampon moins de données localement avant de les envoyer vers le cloud.
New Relic a affiché 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 indiquait la quantité de données que chaque agent envoyait à son serveur.
Les trois agents ont transmis des quantités de données similaires sur le réseau. Datadog en a transmis légèrement moins, probablement en raison d'une compression plus poussée ou de fréquences d'échantillonnage différentes.
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.
Résumé de l'impact sur les ressources
Aucun de ces agents ne sollicitera excessivement votre système. Même en cas de forte charge de la base de données, avec les trois agents fonctionnant simultanément, la consommation totale de ressources est restée largement inférieure à 10 % pour le processeur et la mémoire combinés.
New Relic l'emporte en termes d'efficacité mémoire. Solarwinds consomme plus de ressources, mais offre une analyse plus détaillée au niveau des requêtes. Datadog se situe entre les deux.
Dans la plupart des cas, ces différences de ressources n'influenceront pas votre décision. Privilégiez les fonctionnalités et la facilité d'utilisation plutôt que la consommation de ressources.
3. Tableau de bord et fonctionnalités de surveillance
Une fois la configuration terminée, nous devions observer le comportement de chaque plateforme. Nous avons exécuté la même charge de travail sur les trois : l’insertion de 2 millions d’enregistrements par lots de 5 000, suivie de l’insertion 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, adresses e-mail, adresses postales et numéros de téléphone). Cela nous a permis d'obtenir un ensemble de données réalistes à surveiller.
Pendant l'exécution des insertions, nous avons surveillé la consommation des ressources de l'agent en arrière-plan.
La charge de travail a mis à rude épreuve MongoDB, ce qui nous a permis de voir comment chaque plateforme a capturé et affiché 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 seul clic a suffi pour afficher un tableau de bord complet.
En haut de l'écran s'affichaient l'état du serveur (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 requêtes les plus fréquentes » présentait les modèles de requêtes les plus utilisés, avec leur nombre et leur pourcentage.
Les chiffres parlaient d'eux-mêmes. Le débit affichait en moyenne 3 requêtes par seconde. Le détail indiquait 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, soit 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 leurs temps d'exécution moyens.
Nos requêtes d'insertion prenaient chacune 4 à 5 secondes, ce qui semble long jusqu'à ce qu'on se souvienne que chaque requête écrivait 5 000 lignes.
L'onglet Santé indiquait que tout fonctionnait correctement.
Nous avons arrêté le service MongoDB pour voir à quelle vitesse Solarwinds le détecterait. En 30 à 40 secondes, l'état de santé est passé à « Mauvais ».
L'onglet Requêtes offrait des options de filtrage avancées. Vous pouviez y afficher les requêtes qui :
- Erreurs renvoyées
- Exécuté sans index appropriés
- Réponse lente
- Avertissements générés
Chaque requête indiquait sa date d'apparition initiale, sa dernière exécution, le nombre d'échantillons capturés et des statistiques d'exécution. Ce niveau de détail est essentiel pour le dépannage.
L'onglet Alertes nous permet de créer des alertes spécifiques à MongoDB. Nous avions déjà créé une alerte de mémoire pour l'hôte, mais nous pouvions désormais configurer des notifications spécifiques à la base de données.
L'onglet Ressources affichait des indicateurs au niveau de l'hôte, ainsi que des statistiques (processeur, mémoire, disque et réseau). Ce contexte permet de distinguer les problèmes de base de données des problèmes d'infrastructure sous-jacente.
L'onglet « Conseillers » ne contenait pas encore de recommandations, mais il en avait fourni pour MySQL lors de notre test précédent. Nous 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é l’Agent IA avec la fonctionnalité d’assistance aux requêtes IA (actuellement en version préliminaire). L’assistance aux requêtes IA 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. L’Assistance à la cause racine (désormais disponible pour tous) génère des analyses claires des causes racines à partir des alertes et des anomalies afin de réduire le temps de dépannage. Une disponibilité plus large de l’Agent IA dans l’ensemble du portefeuille SolarWinds est prévue pour 2026. 1 2 .
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 du tableau de bord et avons trouvé deux options MongoDB.
Nous avons sélectionné le tableau de bord standard MongoDB et cliqué sur « Configurer MongoDB ».
Nous avons été redirigés 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 accédé au tableau de bord.
Le tableau de bord s'est ouvert complètement vide. « Aucune valeur n'a été signalée pour la vérification du service mongodb.can_connect. »
Nous avons vérifié notre configuration à l'aide de newrelic-infra agent configtest .
Lors de l'exécution de la commande `newrelic-infra agent configtest` pour vérifier notre configuration, nous avons constaté que le nom de l'intégration était défini sur `nri-prometheus`. Lors de la configuration du tableau de bord, New Relic a affiché deux options `MongoDB`, dont l'une correspondait à la version Prometheus. Rien dans l'interface n'indiquait qu'il s'agissait d'une intégration différente ; je n'aurais donc jamais imaginé avoir sélectionné l'intégration Prometheus. Il ne s'agissait pas d'une erreur de ma part : l'interface ne fournissait aucune indication ni distinction à ce sujet.
Nous sommes retournés en arrière et avons installé le tableau de bord « MongoDB (Prometheus) ».
Cette fois, des données sont apparues.
Mais voilà le problème : comment un utilisateur lambda pourrait-il s’y retrouver ? Le processus d’installation était déjà complexe, et le choix du tableau de bord ajoute une difficulté supplémentaire.
La disposition du tableau de bord était étrange. La partie supérieure affichait des informations sur le nombre total de serveurs et de bases de données qui ne changent qu'une fois par an, et pourtant elle occupait une place de choix à l'écran.
Juste en dessous, la « Saturation de la connexion » apparaissait en évidence. Cet indicateur n'est pertinent qu'en cas de problème. Pourquoi le placer en haut de la liste ?
La section « Opérations de requête » indiquait 11 670 insertions. Ce chiffre était erroné. 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, 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 ? »). Cependant, le comptage en temps réel a échoué.
L'onglet Collections comprenait des graphiques utiles pour les métriques au niveau de la collection : taille (avec des 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 de transaction, opérations d'accès à l'index, nombre d'exécutions de commandes, latence de commande, fréquence des commandes et durée des commandes.
Notamment absentes : les métriques de l’hôte. Nous n’avons pas pu observer l’utilisation du processeur, de la mémoire, du disque ou du réseau pour le serveur exécutant MongoDB. SolarWinds contenait ce contexte, mais Datadog, tout comme New Relic, ne l’a pas fait.
Plus important encore, aucune analyse au niveau des requêtes n'était disponible. Aucun modèle de requête, aucun profilage, aucune identification des requêtes lentes, aucune détection des index manquants. Or, ces fonctionnalités sont essentielles pour le dépannage des bases de données.
Tableau de bord Datadog
Nous avons cliqué sur « Tableaux de bord » dans le menu de gauche. Un tableau de bord intitulé « MongoDB – Vue d'ensemble » est apparu automatiquement.
Nous l'avons ouvert, mais il était vide.
Le diagnostic du problème a été long. Lors de l'installation, la configuration de découverte automatique de Datadog exigeait de spécifier les bases de données à surveiller à l'aide d'un modèle de correspondance. Le modèle par défaut ne correspondait pas au nom de notre base de données. Datadog n'a jamais mentionné ce problème lors de la configuration.
Nous avons modifié tous les modèles en .* (correspondance à tout) et redémarré l'agent.
Mais pourquoi le tableau de bord était-il complètement vide ? Même sans indicateurs spécifiques à la base de données, la disponibilité, le nombre de connexions et les statistiques du serveur auraient dû s'afficher. Or, ce n'était pas le cas.
Nous avons exécuté la commande datadog-agent check mongo pour déboguer. Le fichier de configuration contenait une erreur d'indentation. Les exigences strictes de formatage du YAML nous ont piégés. Après correction et un nouveau 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 », malgré la configuration de la collecte des journaux dans notre fichier YAML. Le processus d'installation de Datadog indiquait que tout était correct, mais les journaux restaient inaccessibles.
La disposition du tableau de bord était peu pertinente pour notre cas d'utilisation. La partie supérieure était consacrée aux statistiques de partitionnement, alors que nous n'utilisions pas de cluster partitionné. La partie centrale affichait les métriques des ensembles de réplicas, or nous n'en avions pas. La partie inférieure revenait au partitionnement. Environ 60 % du tableau de bord présentait des sections vides pour des fonctionnalités que nous n'utilisions pas.
Les informations utiles occupaient environ 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 des requêtes, aucun profilage, aucune détection des requêtes lentes, aucune recommandation d'index.
Nous n'avons même pas pu déterminer le nombre d'opérations exécutées à partir de ce tableau de bord.
Environnement et méthodologie de test
Nous avons exécuté les trois outils sur des configurations identiques afin de garantir une comparaison équitable. Chaque test a utilisé :
- Base de données : MongoDB Édition communautaire 7.0
- Serveur : instance AWS m6i.xlarge
- Point de départ : Installation neuve avec l'agent de surveillance principal déjà installé.
Les trois fournisseurs exigent l'installation de leur agent de base avant l'ajout d'intégrations spécifiques, telles que MongoDB. Cette étape ayant été réalisée au préalable, notre test s'est concentré exclusivement sur l'expérience d'intégration de MongoDB.
Ce que nous avons mesuré :
- Complexité de la configuration : nombre d’étapes manuelles, configuration automatique ou manuelle, clarté des instructions et orientation de l’interface (guide ou recherche des étapes suivantes).
- Consommation de ressources de l'agent : utilisation du processeur, de la mémoire, des E/S disque et du réseau en mode veille et en charge (insertion de 7 millions d'enregistrements).
- Fonctionnalités de surveillance : qualité du tableau de bord, précision des indicateurs, analyse au niveau des requêtes et fonctionnalités de dépannage.
Considérations de sécurité
Une vulnérabilité critique nommée « MongoBleed » a été découverte, affectant les versions du serveur MongoDB antérieures à 8.0.17, 7.0.28, 6.0.27 et les versions précédentes. 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 utilisant MongoDB doivent immédiatement mettre à jour leur système vers les versions corrigées suivantes : 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 ou 4.4.30. 3 4 Lors du choix des outils de surveillance, assurez-vous qu'ils prennent en charge des méthodes d'authentification sécurisées et qu'ils n'introduisent pas de risques de sécurité supplémentaires.
Nous avons abordé chaque outil comme le ferait un utilisateur lambda, sans consulter la documentation au préalable et sans formation. Si un élément de l'interface n'était pas évident, nous l'avons noté.
Verdict final
Nous avons entrepris de répondre à une question simple : quelle plateforme de surveillance facilite l’intégration de MongoDB pour les équipes non techniques ?
Après avoir installé les trois solutions, exécuté des charges de travail identiques et évalué les tableaux de bord, la conclusion est apparue clairement. Notre évaluation repose sur l'intégration de base de Datadog pour MongoDB (janvier 2025). Datadog a depuis lancé Database Monitoring (DBM) pour MongoDB (décembre 2024), qui offre des fonctionnalités nettement plus avancées, 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 limitations identifiées dans ce benchmark. 5 .
Solarwinds : Conçu pour la surveillance des bases de données
La plateforme SolarWinds a remporté ce comparatif haut la main. Elle a immédiatement détecté notre agent, nous a guidés dans la configuration des identifiants par simple copier-coller et a déployé l'intégration automatiquement. L'installation a pris 5 minutes.
Le tableau de bord s'est affiché instantanément avec les informations pertinentes. Le profilage des requêtes a permis d'identifier précisément les opérations les plus gourmandes en ressources. La plateforme a enregistré l'intégralité des 1 400 opérations par lots, sans en manquer une seule. Lors de l'arrêt de l'opération MongoDB, SolarWinds a détecté l'erreur en moins de 40 secondes.
L'onglet Requêtes permet de filtrer les requêtes par erreurs, index manquants, temps de réponse lents et avertissements, des fonctionnalités qui contribuent directement à l'optimisation de la base de données. La fonctionnalité Conseils était censée fournir des recommandations (mais nous n'avons pas généré suffisamment de données pour en déclencher lors de 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
L'installation de New Relic a pris 15 minutes, mais le temps n'était pas le principal problème. La plateforme posait les questions dans le désordre, exigeait une vérification manuelle d'éléments que l'agent pouvait contrôler automatiquement et nous obligeait à installer manuellement des paquets.
La confusion autour du tableau de bord a aggravé les choses. Nous avons installé la surveillance MongoDB, mais la sélection du tableau de bord par défaut a affiché un écran vide. Ce n'est qu'après avoir examiné les fichiers de configuration que nous avons réalisé que nous avions sélectionné le mauvais type d'intégration. Un utilisateur lambda ne s'en serait pas rendu compte.
Lorsque les données sont finalement apparues, les indicateurs étaient erronés. New Relic a signalé 11 670 insertions après 1 400 opérations par lots, soit un total de 7 millions d'enregistrements. La plateforme a sous-estimé le nombre d'insertions d'un ordre de grandeur.
Plus grave encore, New Relic ne propose aucune analyse au niveau des requêtes : ni profilage, ni détection des requêtes lentes, ni identification des index manquants. Or, ces lacunes sont préoccupantes pour le dépannage des bases de données.
Datadog : Travail manuel requis
L'installation de Datadog a nécessité plus de 20 minutes et une configuration très manuelle. Nous avons modifié les fichiers YAML, déterminé leur emplacement et redémarré les services en ligne de commande.
Le tableau de bord s'est affiché automatiquement, mais restait vide. La configuration de découverte automatique utilisait un modèle incompatible avec notre base de données. Après avoir corrigé le modèle et les erreurs d'indentation YAML, les données ont finalement été chargées.
Le tableau de bord s'est avéré mal conçu pour une instance unique (MongoDB). Soixante pour cent de l'écran étaient vides, avec des sections dédiées au partitionnement et aux ensembles de réplicas que nous n'utilisions pas. Les 40 % restants affichaient des indicateurs de base : disponibilité, mémoire, E/S réseau, requêtes par seconde et latence.
Aucune analyse des requêtes. Aucun profilage. Aucune recommandation d'optimisation. Nous n'avons pas pu déterminer avec précision le nombre d'opérations sur le tableau de bord.
Aucune analyse des requêtes. Aucun profilage. Aucune recommandation d'optimisation. Nous n'avons pas pu déterminer avec précision le nombre d'opérations sur le tableau de bord.
Mise à jour critique (décembre 2024) : Suite à la réalisation de cette évaluation comparative, Datadog a lancé la surveillance des bases de données (DBM) pour MongoDB, ce qui modifie considérablement cette évaluation. La DBM pour MongoDB offre désormais :
- Analyse des opérations lentes avec des exemples de requêtes détaillés
- Expliquez les plans d'optimisation des requêtes.
- Surveillance de l'état de réplication et visualisation de l'état du cluster
- Analyse des informations au niveau opérationnel et identification des goulots d'étranglement en matière 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 de base MongoDB testée dans ce benchmark et inclut de nombreuses fonctionnalités d'analyse au niveau des requêtes qui étaient absentes lors de nos tests. 6 7 Les organisations qui évaluent Datadog pour la surveillance MongoDB doivent évaluer spécifiquement le produit de surveillance de base de données 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
La fenêtre SolarWinds s'ouvre sur une fenêtre modale vous demandant ce que vous souhaitez surveiller. Vous choisissez « Performances de la base de données », sélectionnez MongoDB, et la plateforme détecte immédiatement l'agent que vous avez déjà installé, affichant le système d'exploitation, l'ID de l'instance cloud et le numéro de version directement sur l'écran de sélection. Elle vous fournit ensuite trois commandes à copier-coller pour exécuter dans MongoDB, gère les identifiants et confirme le déploiement. Cinq minutes, de bout en bout.
L'installation de New Relic a pris quinze minutes, et le temps n'était même pas le véritable problème. L'interface posait sans cesse des questions auxquelles l'agent aurait pu répondre lui-même, comme le système d'exploitation et la version MongoDB, alors que l'agent était déjà installé sur le serveur. À un moment donné, elle a proposé par défaut les commandes d'installation d'Amazon Linux, alors que nous utilisions clairement Ubuntu. L'étape qui a finalement tout gâché : le catalogue du tableau de bord propose deux options d'intégration MongoDB, une standard et une basée sur Prometheus, sans aucune distinction dans l'interface. Nous avons choisi la mauvaise, obtenu un tableau de bord vide, et nous ne l'avons compris qu'en fouillant dans les fichiers de configuration.
L'installation de Datadog a nécessité plus de vingt minutes de modification de fichiers YAML, de devinettes sur les chemins d'accès et de redémarrage des services en ligne de commande. La documentation fournie lors de l'installation 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 partitionnés et la configuration SSL, le tout simultanément, pour quelqu'un qui souhaite simplement surveiller une seule base de données. Lorsque les données sont enfin apparues, le tableau de bord affichait en premier les statistiques de partitionnement et les métriques des ensembles de réplicas. Nous n'avions ni l'une ni l'autre. Environ 60 % de l'écran était vide.
Précision métrique sous charge
SolarWinds a comptabilisé 1 400. Résultat exact. New Relic a rapporté 11 670, soit un ordre de grandeur d'erreur sans explication apparente, 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 panne en trente à quarante secondes.
Concernant 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 d'un travail de profilage des requêtes local. Dans la plupart des environnements, ces éléments n'influenceront pas votre choix.
La caractéristique qui les distingue réellement
Tous les outils de surveillance vous signaleront un ralentissement. La question est de savoir s'ils vous en indiqueront la cause .
SolarWinds propose un profilage au niveau des requêtes. L'onglet Profiler affiche précisément les modèles de requêtes exécutés, leur durée d'exécution et le nombre d'échantillons capturés. Vous pouvez filtrer les résultats par requêtes exécutées sans index, ayant renvoyé des erreurs ou généré des avertissements.
New Relic et Datadog n'ont fourni que des métriques agrégées concernant la latence, le nombre de connexions et le total des opérations. Aucun profilage, aucune identification des requêtes lentes, aucune détection des index manquants. Pour confirmer qu'une base de données est opérationnelle, ces outils se sont révélés inutiles pour diagnostiquer les problèmes de performance.
Remarque : Datadog a lancé un produit de surveillance de bases de données pour MongoDB en décembre 2024, suite à nos tests. Ce produit 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 la première option utilisée par la plupart des utilisateurs.
SolarWinds : Si l'optimisation des bases de données est votre véritable préoccupation. Des indicateurs précis, une configuration rapide et la seule plateforme ici qui vous indique non seulement qu'une requête est lente, mais aussi comment y remédier.
New Relic : Si vous l'utilisez déjà pour la gestion des performances applicatives (APM) et que vous avez besoin d'informations de base sur l'état de votre base de données au même endroit, le suivi d'une requête lente, du navigateur jusqu'à l'appel à la base de données, est très utile. En revanche, ne vous y fiez pas pour obtenir un nombre précis d'opérations.
Datadog : Si la configuration manuelle ne vous pose pas de problème et que vous souhaitez une plateforme unique pour une architecture complexe, les plus de 600 intégrations justifient les difficultés de mise en place pour les équipes compétentes.
Liens de référence
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.