Surveillance de MySQL: SolarWinds vs New Relic vs Datadog
Nous avons installé trois plateformes de surveillance de bases de données sur un système propre exécutant MySQL pour voir comment elles gèrent la surveillance de bases de données à partir de zéro.
Nous avons examiné : la facilité d'installation, l'expérience d'intégration, la consommation de ressources des agents, la précision des mesures de métriques et l'efficacité des notifications de leurs systèmes d'alerte lorsque des problèmes surviennent sous des charges de travail de base de données réelles.
Résultats du benchmark des outils de surveillance des performances MySQL
Plateforme | Temps d'installation | Profilage des requêtes | Précision des opérations | Rapidité des alertes | Idéal pour |
|---|---|---|---|---|---|
8 min | ✅ | ✅ 5 000/5 000 (100 %) | 3e | Optimisation de base de données | |
New Relic | 8 min | ❌ | ❌ 3 847/5 000 (23 % sous-comptage) | 1er | Surveillance d'applications |
Datadog | 12 min | ❌ | Peu clair | 2e | Surveillance d'infrastructure |
Consultez notre méthodologie complète de test MySQL et ses résultats.
SolarWinds a fourni la seule plateforme avec un profilage au niveau des requêtes, identifiant les requêtes lentes, les index manquants et les goulots d'étranglement de performances. Elle a également suivi avec précision chaque opération de base de données pendant notre test d'importation de 26GB.
New Relic a envoyé les alertes le plus rapidement, mais a nettement sous-compté les opérations et n'a fourni aucune analyse des requêtes.
Datadog a nécessité le plus de configuration manuelle et n'a offert que des métriques de base.
Vous pouvez également voir comment ces plateformes surveillent MongoDB. Notre analyse reflète le paysage de l'observabilité en 2026, dans lequel 60 % des organisations qualifient désormais leurs pratiques de surveillance de matures ou expertes, contre 41 % auparavant. L'évolution vers une observabilité des bases de données pilotée par l'IA et la consolidation des outils rend le choix de la plateforme de plus en plus stratégique1.
Expérience d'installation et d'intégration
1. SolarWinds
SolarWinds s'ouvre sur une question : Que souhaitez-vous surveiller ?
Lorsque vous sélectionnez les performances de la base de données, les bases de données prises en charge s'affichent immédiatement.
Après avoir sélectionné MySQL, la plateforme vérifie si des agents sont déjà en cours d'exécution.
Une fonctionnalité s'est démarquée : si vous avez un agent Kubernetes installé, SolarWinds détecte automatiquement les bases de données exécutées dans votre cluster. Vous pouvez les sélectionner sans configuration manuelle.
SolarWinds propose plusieurs méthodes d'installation :
- Détection automatique (détecte automatiquement le système d'exploitation et sa version)
- Installation manuelle en spécifiant le système d'exploitation
- Scripts d'automatisation (Ansible, Chef, Puppet, SaltStack)
- Image Docker
- Déploiement de l'agent Kubernetes
- Intégration OpenTelemetry (ajoutée en janvier 2026)2
Nous avons sélectionné l'option recommandée : installation par script.
Le script d'installation est simple. SolarWinds vous demande d'abord de créer une clé API, puis vous permet de spécifier un nom d'hôte pour votre instance.
Après avoir créé la clé API, vous spécifiez un nom d'hôte pour l'instance. Nous avons nommé la nôtre « AIMULTIPLE-MYSQL » et activé la surveillance de l'hôte pour suivre les métriques du serveur en même temps que les statistiques de la base de données.
Copiez le script, exécutez-le sur le serveur et l'agent s'installe. Le script inclut automatiquement la clé API, aucune configuration supplémentaire n'est donc nécessaire.
Nous attendions à voir une confirmation « installation réussie », mais rien ne s'affiche. L'exécution de la commande est terminée et vous devez supposer qu'elle a fonctionné.
Après l'installation, SolarWinds propose d'activer la surveillance des journaux pour tous les journaux du serveur. Nous avons ignoré cette étape.
Ensuite, il présente des modèles d'alertes par défaut. Il s'agit d'alertes au niveau de l'hôte (CPU, mémoire, disque) car nous avons activé la surveillance de l'hôte plus tôt. Aucune alerte spécifique à MySQL n'apparaît à ce stade, même si nous configurons la surveillance de la base de données.
Le point déroutant : SolarWinds a installé son agent de base, pas l'agent de surveillance MySQL. Vous devez revenir en arrière et ajouter la surveillance de la base de données séparément. L'interface ne le précise pas clairement lors de la configuration initiale.
Maintenant, SolarWinds demande les identifiants MySQL. L'interface pourrait être plus claire, car elle n'explique pas dès le départ quelles autorisations l'utilisateur de surveillance doit avoir.
Mais voici la partie intéressante : lorsque vous saisissez un nom d'utilisateur et un mot de passe, SolarWinds génère un script SQL complet pour créer cet utilisateur avec toutes les autorisations nécessaires.
Le problème : l'écran précédent ne mentionne pas l'existence de ce script. Lors de notre test, nous avons créé un utilisateur de surveillance manuellement, pour découvrir plus tard que SolarWinds génère automatiquement le script de création.
Le script SQL généré crée l'utilisateur, accorde l'accès au schéma de performance et configure toutes les autorisations requises. Copiez ces commandes, exécutez-les dans MySQL, puis appliquez les éventuels changements de configuration MySQL recommandés.
Une incohérence : Le champ de nom d'utilisateur par défaut affiche « utilisateur sur [system hostname] » au lieu du nom d'hôte spécifié lors de l'installation de l'agent. Dans notre cas, nous avons nommé l'instance « AIMULTIPLE-MYSQL » lors de la configuration, mais l'interface a affiché à la place le nom d'hôte réel du serveur.
Après avoir exécuté les commandes SQL et mis à jour la configuration MySQL, cliquez sur « Observer la base de données ».
Le tableau de bord apparaît, vide et prêt à collecter des données.
Découvrez l'observabilité de base de données de SolarWinds avec une surveillance MySQL approfondie et un profilage des requêtes. Explorez SolarWinds.
Visitez le site web2. New Relic
New Relic adopte une approche différente. Au lieu de demander quoi surveiller, il commence par l'installation de l'agent.
Après la connexion, l'écran d'intégration invite d'abord à installer l'agent. Sélectionnez Linux comme système d'exploitation.
Comme aucune clé API n'existe encore, New Relic demande d'en créer une.
La plateforme génère automatiquement la clé et fournit immédiatement le script d'installation.
L'interface comprend une option utile : « répondre automatiquement oui à toutes les invites ». Activez-la pour une installation plus fluide.
L'exécution du script sur le serveur révèle quelque chose d'intéressant : l'agent de New Relic analyse le système pendant l'installation et détecte automatiquement MySQL. Il tente d'installer l'intégration MySQL par lui-même, sans intervention de l'utilisateur. Mais l'installation échoue.
En sélectionnant l'installation « automatisée sur l'hôte », New Relic demande soit de créer une nouvelle clé API, soit d'utiliser une clé existante. Choisir d'utiliser la clé existante ne propose pas de liste déroulante ; il faut coller la clé manuellement. Cela rend la création d'une nouvelle clé plus simple, c'est donc ce que nous avons fait.
L'option de surveillance des requêtes lentes est une bonne attention.
Mais voici une demande étrange : New Relic demande de spécifier le type de base de données : auto-hébergée, RDS ou Aurora. L'agent est déjà installé sur le serveur et a détecté MySQL plus tôt. Il devrait connaître le type de déploiement.
New Relic fournit un autre script d'installation.
Pendant l'installation, l'interface CLI demande les identifiants d'accès MySQL. Contrairement à SolarWinds, qui fournit un script SQL dans l'interface, New Relic demande le mot de passe root directement dans le terminal.
L'invite initiale suggère d'utiliser root, ce que la plupart des utilisateurs ne fourniront pas, même dans un environnement de test.
La confusion : il demande les identifiants root pour créer automatiquement un utilisateur de surveillance, et non pour utiliser root pour la surveillance. L'interface devrait présenter deux options claires : « Je vais créer l'utilisateur moi-même » ou « Créer l'utilisateur automatiquement (nécessite le mot de passe root) ».
La vérification de la base de données confirme qu'un utilisateur « newrelic » existe. Mais New Relic n'affiche pas les autorisations de cet utilisateur. La transparence aiderait ici à afficher les autorisations accordées (par exemple, « Utilisateur 'newrelic' créé avec les autorisations SELECT, PROCESS et REPLICATION CLIENT ») lors de la demande d'accès root, ce qui clarifierait les attentes.
Une fois l'installation terminée, nous attendions à voir un tableau de bord spécifique à MySQL. Au lieu de cela, l'interface a affiché un tableau de bord générique avec des options pour créer des visualisations personnalisées. Aucun tableau de bord MySQL prédéfini n'est apparu automatiquement.
Le processus de configuration n'a pas permis de savoir clairement si :
- Un tableau de bord MySQL apparaîtrait plus tard après la collecte de données
- Nous devions en créer un manuellement
- Nous avions manqué une étape de configuration
Nous avons attendu de voir si un tableau de bord se remplirait de données au fil du temps.
Résumé de l'installation
Délai d'achèvement : environ 8 minutes
Complexité : Faible (création d'utilisateur automatisée)
Points forts : Installation la plus rapide, création automatique de l'utilisateur, installation en une seule phase
Points faibles : Demande de mot de passe root peu claire, aucun tableau de bord MySQL prédéfini, chemin d'installation manuel peu évident
Datadog
L'approche de Datadog est la plus pratique des trois plateformes.
Après la connexion, l'interface invite d'abord à installer l'agent de base. Plusieurs méthodes de déploiement sont disponibles. Nous avons sélectionné Linux pour l'installation.
Datadog demande une clé API. La création est simple ; le processus avance automatiquement.
Copiez le script d'installation et exécutez-le sur le serveur.
L'agent s'installe rapidement. Mais contrairement à SolarWinds ou New Relic, rien ne se passe ensuite, aucune détection de MySQL, aucune invite pour configurer la surveillance de la base de données. Nous avons dû naviguer manuellement vers la Marketplace et rechercher MySQL.
Après avoir sélectionné l'intégration MySQL, une fenêtre contextuelle apparaît avec les instructions d'installation.
Datadog fournit une liste de contrôle :
- Créer un utilisateur de surveillance dans MySQL
- Accorder des autorisations
- Écrire un fichier de configuration YAML
- Placez-le dans `/etc/datadog-agent/conf.d/mysql.d/conf.yaml`
Le chemin du fichier de configuration n'est pas affiché de manière visible dans l'interface. Vous devez savoir où Datadog stocke les configurations d'intégration, ou faire défiler la documentation pour le trouver.
Cette approche est plus avancée et technique que la configuration guidée par l'interface de SolarWinds ou la création automatique d'utilisateur de New Relic. Vous modifiez des fichiers manuellement et redémarrez des services à partir de la ligne de commande. Nous avons créé l'utilisateur MySQL avec les autorisations requises, écrit le fichier de configuration YAML, placé celui-ci dans le bon répertoire et redémarré l'agent Datadog pour terminer la configuration.
Après le redémarrage, le tableau de bord Datadog est apparu avec des métriques MySQL de base prêtes à collecter des données.
Résumé de l'installation
- Délai d'achèvement : environ 12 minutes
- Complexité : Élevée (configuration YAML manuelle, pas de configuration guidée)
- Points forts : Contrôle total de la configuration, fonctionne bien si vous connaissez déjà Datadog
- Points faibles : Pas de détection automatique, nécessite la modification manuelle de fichiers, pas adapté aux débutants, chemin de fichier non évident dans l'interface
Remarque : ceci couvre le chemin d'installation de base. Datadog, SolarWinds et New Relic offrent de nombreuses options de configuration supplémentaires pour une surveillance avancée. Ces tests se sont concentrés sur l'expérience d'intégration par défaut.
Consommation des ressources de l'agent
Nous avons testé la consommation des ressources de l'agent dans deux scénarios : charge de base de données nulle (surveillance au repos) et charge lourde (pendant une importation de base de données de 26 Go). Les deux tests ont duré environ 6 à 7 minutes, les trois agents collectant des données simultanément.
Consommation CPU
- La consommation CPU est restée minimale pour tous les agents. Sous une charge de base de données lourde, l'utilisation moyenne est restée bien en dessous de 1 % pour les trois plateformes.
- Datadog a montré le pic le plus élevé à 3.20 % pendant la charge lourde, mais ces pics étaient brefs et peu fréquents. Les trois agents ont passé la plupart de leur temps au repos ou en dessous de 0.5 % d'utilisation CPU.
Utilisation de la mémoire
- New Relic a consommé nettement moins de mémoire, environ 3 à 5x moins que les deux autres plateformes. L'utilisation de la mémoire est restée stable dans les scénarios de repos et de charge lourde pour les trois agents.
E/S disque
Charge nulle
Charge lourde
Les modèles d'E/S disque ont montré des caractéristiques distinctes pour chaque agent :
- Datadog a le plus lu sur le disque mais a le moins écrit. Cela suggère des accès disque plus fréquents pour la récupération de données avec une mise en mémoire tampon locale minimale.
- SolarWinds a écrit nettement plus de données localement que les deux autres, environ 2 à 3x fois plus. Cela indique une mise en mémoire tampon locale agressive ou une journalisation plus détaillée.
- New Relic a équilibré les lectures et les écritures, effectuant le moins de lectures disque tout en maintenant une activité d'écriture modérée.
Il est intéressant de noter que les E/S disque ont en fait légèrement diminué sous une charge de base de données lourde pour les trois agents. L'activité disque des agents n'a pas évolué proportionnellement à la charge de travail de la base de données ; ils ont maintenu des modèles cohérents quelle que soit la charge de travail de MySQL.
Précision des métriques
Nous avons exécuté une importation de base de données de 26 Go pour solliciter le système et évaluer avec quelle précision chaque plateforme mesurait la consommation de ressources.
Mesure du CPU
Les trois plateformes ont suivi l'utilisation du CPU pendant l'importation avec une précision similaire. SolarWinds et Datadog ont fourni une granularité d'une minute, tandis que New Relic a échantillonné toutes les 2 minutes. Les mesures étaient cohérentes entre les plateformes, sans écarts significatifs.
Graphique CPU de SolarWinds – montrant une utilisation d'environ 45-60 % pendant l'importation
Graphique CPU de New Relic – montrant un schéma similaire
Graphique CPU de Datadog – montrant un graphique en aires empilées des états du CPU
Mesure de la mémoire
Cela a révélé un problème critique avec New Relic.
Pendant l'importation, le serveur a consommé près de 100 % de la RAM disponible. Voici ce que chaque plateforme a rapporté :
SolarWinds : a montré avec précision environ 100 % d'utilisation de la mémoire
New Relic : n'a signalé qu'environ 10 % d'utilisation de la mémoire
Graphique mémoire de Datadog – montrant la RAM totale par rapport à la RAM utilisée à environ 16GB
New Relic a complètement manqué le pic de mémoire. Ce n'est pas une erreur de mesure mineure ; c'est un ordre de grandeur d'écart. Si vous comptez sur les alertes de mémoire ou la planification de capacité, ce type d'inexactitude compromet toute la configuration de surveillance.
Mesure du réseau
New Relic et Datadog ont capturé avec précision le trafic réseau pendant l'importation, tandis que SolarWinds a sous-déclaré l'utilisation du réseau, manquant une partie de l'activité.
Graphique réseau de SolarWinds – montrant le débit réseau avec quelques lacunes de données
Graphique réseau de New Relic – montrant les données complètes de réception/transmission réseau
Graphique réseau de Datadog – montrant une capture précise du trafic réseau
La granularité des mesures est restée cohérente avec le CPU : SolarWinds et Datadog ont échantillonné chaque minute, New Relic toutes les 2 minutes.
Performances des alertes
Nous avons configuré la même alerte sur les trois plateformes : envoyer une notification si l'utilisation de la mémoire dépasse 50 % pendant 1 minute. Ensuite, nous avons déclenché l'alerte manuellement à l'aide de l'outil stress-ng pour pousser l'utilisation de la mémoire à 70 %.
Configuration d'alerte de SolarWinds – montrant le seuil de mémoire défini à >50 % pendant 1 minute
Configuration d'alerte de New Relic – montrant le mode guidé avec les réglages de seuil et l'aperçu des séries temporelles
Configuration d'alerte de Datadog – montrant la configuration du moniteur de métriques avec les détails d'évaluation
Toutes les alertes ont été définies sur la priorité « Critique ». Nous avons testé les notifications par e-mail et Slack.
Configuration des alertes
New Relic offre les contrôles de durée les plus granulaires. Alors que SolarWinds et Datadog exigent des seuils de durée minimale d'une minute, New Relic vous permet de définir des alertes pour des conditions durant aussi peu que 10 secondes. Cette flexibilité aide à détecter de brefs pics qui pourraient se résorber avant d'atteindre la barre d'une minute sur d'autres plateformes.
SolarWinds et Datadog exigent tous deux des durées minimales d'une minute pour les alertes de seuil.
Canaux de notification
New Relic et SolarWinds offrent tous deux des options de notification. Datadog n'a accepté que les notifications par e-mail dans notre configuration par défaut ; il peut nécessiter une configuration supplémentaire pour d'autres canaux.
Options de notification de New Relic – montrant une liste étendue comprenant ServiceNow, Webhooks, Jira, Slack, Microsoft Teams, Email, PagerDuty
Options de notification de SolarWinds – montrant la liste déroulante des services avec AmazonSNS, Email, Microsoft Teams, New Relic, OpsGenie, PagerDuty, ServiceNow
Vitesse de notification
Nous avons lancé le test de stress mémoire. La mémoire a atteint 70 % presque instantanément et est restée au-dessus de 50 % pendant plus d'une minute. Voici quand les alertes sont arrivées :
Notifications par e-mail :
New Relic – Arrivée en premier
Datadog – Deuxième
SolarWinds – Dernière
Notifications Slack :
Nous avons testé l'intégration Slack pour New Relic et SolarWinds (Datadog ne prenait pas en charge Slack dans notre configuration).
- New Relic – Livré en premier, et comprenait des boutons interactifs directement dans le message Slack pour accuser réception ou examiner les alertes
- SolarWinds – Livré en second, mais sous forme de notifications en texte brut
L'intégration Slack de New Relic s'est démarquée. Le format de message interactif vous permet d'agir sans quitter Slack.
Notifications de résolution
Lorsque l'utilisation de la mémoire est revenue à la normale :
- New Relic a envoyé une notification de résolution
- Datadog a envoyé une notification de résolution
- SolarWinds n'a pas envoyé de notification de résolution
Qualité du contenu des e-mails
Les e-mails d'alerte de Datadog comprenaient un contexte clair : ce qui a déclenché l'alerte, les valeurs actuelles et un lien direct vers les tableaux de bord pertinents. Professionnels et informatifs.
Les e-mails d'alerte de New Relic suivaient un format similaire avec de bons détails et des appels à l'action clairs.
Les e-mails d'alerte de SolarWinds étaient clairsemés, avec un minimum de détails, une mise en forme médiocre et des informations moins exploitables. Les e-mails fonctionnaient, mais ils semblaient moins soignés que ceux des deux autres plateformes.
Configuration de l'intégration Slack
New Relic : Cliquez sur « ajouter Slack », authentifiez-vous instantanément et sélectionnez les canaux. Simple.
SolarWinds : Cliquez sur « ajouter Slack », authentifiez-vous et sélectionnez les canaux. Tout aussi simple.
Les deux configurations ont pris moins d'une minute.
Comparaison des tableaux de bord et de l'interface utilisateur
Nous avons évalué les tableaux de bord MySQL par défaut fournis par chaque plateforme dès l'installation. Il ne s'agit pas de vues personnalisées ; c'est ce que vous voyez immédiatement après avoir installé l'agent et collecté des données.
Aperçu des tableaux de bord
SolarWinds ouvre directement un tableau de bord spécifique à MySQL depuis le menu de gauche. La page d'accueil affiche :
- Temps de réponse moyen
- Débit
- Erreurs de requêtes
- Connexions actives
C'est ce qu'un administrateur de base de données ou un CTO veut voir en premier. Les métriques sont de haut niveau, exploitables et immédiatement utiles pour évaluer la santé de la base de données.
Aperçu du tableau de bord MySQL de SolarWinds – montrant les métriques de qualité de service avec des graphiques de temps de réponse, de débit et d'erreurs
New Relic présente un tableau de bord plus dense en données avec plusieurs graphiques montrant les métriques au fil du temps. Il y a beaucoup d'informations : connexions par seconde, durée des requêtes, débit, mais elles sont organisées sous forme de graphiques de séries temporelles plutôt que de résumés de l'état actuel. Vous obtenez des tendances détaillées mais moins de chiffres en un coup d'œil.
Tableau de bord MySQL de New Relic – montrant les connexions à la base de données, les opérations, les requêtes et les graphiques de débit
Datadog affiche le tableau de bord par défaut le plus minimaliste. Il montre quelques métriques de base mais n'a pas la profondeur de SolarWinds ni le détail des tendances de New Relic. Une bizarrerie : « échecs de connexion » apparaît en bonne place en haut d'une métrique axée sur la sécurité qui est rarement la première chose dont vous avez besoin pour vérifier les performances d'une base de données.
Tableau de bord MySQL de Datadog – montrant un moniteur d'activité de base avec des sections de performances et de débit
Fonctionnalités d'analyse détaillée
SolarWinds comprend plusieurs onglets au-delà de l'aperçu :
- Inventaire – Affiche les modèles de requêtes les plus fréquemment utilisés, les temps d'attente (ce qui ralentit les requêtes) et des options de filtrage détaillées. Vous pouvez voir quelles requêtes consomment le plus de ressources et où se produisent les goulots d'étranglement.
- Profileurs – Affiche les modèles de requêtes classés par temps d'exécution total et consommation CPU. C'est essentiel pour l'optimisation : vous pouvez identifier les types de requêtes qui vous coûtent le plus cher et prioriser les corrections en conséquence. Les options de tri et de filtrage facilitent la recherche des requêtes problématiques.
- Santé – Évalue la santé globale de la base de données et signale les problèmes. Lors de notre test en fonctionnement normal, elle s'affichait en vert.
- Requêtes – Répertorie toutes les requêtes, regroupées par modèle, avec un filtrage étendu. Cliquez sur n'importe quelle requête pour voir combien de fois elle a été exécutée, le temps d'exécution moyen et d'autres statistiques.
- Ressources – Affiche les métriques au niveau de l'hôte (CPU, mémoire, disque) parallèlement aux métriques MySQL. Ce contexte aide à distinguer les problèmes de base de données des problèmes d'infrastructure sous-jacents.
- Conseillers – Fournit des recommandations d'amélioration des performances, de la sécurité et de la configuration. Cette fonctionnalité n'existe pas dans les tableaux de bord par défaut de New Relic ou de Datadog. SolarWinds suggère activement des optimisations plutôt que de simplement afficher des données.
New Relic organise l'information différemment. Le tableau de bord se concentre sur les visualisations de séries temporelles, avec de nombreux graphiques montrant les tendances. Vous pouvez explorer des périodes spécifiques et voir des ventilations détaillées, mais l'accent est moins mis sur les données tabulaires ou les résumés de l'état actuel. L'interface semble plus adaptée à l'exploration de modèles historiques qu'à l'obtention de réponses immédiates sur l'état actuel.
Datadog garde le tableau de bord plus simple. Il affiche des métriques MySQL de base et inclut utilement la consommation des ressources de l'hôte sur la même page. Cependant, il lui manque l'analyse au niveau des requêtes et les fonctionnalités d'optimisation fournies par SolarWinds.
Tableaux de bord de surveillance de l'hôte
Nous avons également vérifié le tableau de bord général de surveillance de l'hôte de chaque plateforme (non spécifique à MySQL).
SolarWinds offre exactement ce dont un administrateur de base de données a besoin : une interface fonctionnelle et organisée, axée sur des informations MySQL exploitables plutôt que sur la finition visuelle.
New Relic présente une vue claire et épurée. Les métriques clés sont faciles à repérer et l'interface ne vous submerge pas d'informations. C'est sophistiqué et moderne, mais toujours fonctionnel.
Datadog affiche des informations détaillées, mais avec une mise en page plus chargée. Des métriques plus avancées sont disponibles, mais il y a moins de chiffres récapitulatifs en un coup d'œil. La présentation visuelle est simple mais moins soignée que celle de SolarWinds.
Fonctionnalités améliorées par l'IA
Les trois plateformes ont intégré des capacités propulsées par l'IA en tant que fonctionnalités standard :
SolarWinds inclut désormais l'analyse prédictive dans son onglet Conseillers, fournissant des recommandations proactives basées sur l'analyse par l'IA des modèles de requêtes et des tendances des ressources.
New Relic a amélioré sa détection d'anomalies avec des modèles de machine learning qui établissent automatiquement des références et alertent sur les écarts statistiques plutôt que sur des seuils fixes.
Datadog propose une analyse des causes profondes propulsée par l'IA qui corrèle les métriques de base de données avec les performances des applications et les données d'infrastructure pour accélérer le dépannage.
Ces fonctionnalités d'IA représentent l'évolution du secteur vers une observabilité autonome, où les systèmes peuvent prédire et prévenir les problèmes plutôt que de simplement y réagir3.
Détail au niveau des requêtes
C'est là que SolarWinds se distingue de la concurrence.
Lorsque vous sélectionnez un modèle de requête spécifique dans SolarWinds, vous obtenez des statistiques avancées :
- Exécutions totales
- Temps d'exécution moyen
- Répartition de la consommation CPU
- Temps d'attente de verrouillage
- Lignes examinées par rapport aux lignes retournées, et plus encore
New Relic et Datadog affichent tous deux des métriques de requêtes, mais le niveau de détail et la facilité de navigation ne rivalisent pas avec les outils de profilage de requêtes dédiés de SolarWinds.
Surveillance MySQL améliorée : les déploiements MySQL modernes bénéficient de capacités améliorées du schéma de performance et d'informations avancées sur l'exécution des requêtes. Les organisations qui exploitent ces fonctionnalités améliorées signalent des améliorations de performances significatives, certaines atteignant jusqu'à 42 % de réduction du temps d'exécution des requêtes grâce à des stratégies de surveillance optimisées4.
Ce que nous avons testé
Nous avons déployé des agents de SolarWinds, New Relic et Datadog sur le même serveur pour surveiller une instance MySQL. Chaque outil est passé par son processus d'installation complet, et nous avons suivi :
- Comment le flux d'intégration vous guide à travers la configuration
- Ce que le processus d'installation vous demande
- La consommation des ressources de l'agent (utilisation de la mémoire et du CPU)
- La précision des métriques pendant la charge de la base de données
- La configuration des alertes et la vitesse de notification
- L'utilisabilité des tableaux de bord et l'architecture de l'information
Environnement de test
Tous les tests ont été exécutés sur une instance Amazon EC2 m6i.xlarge avec les spécifications suivantes :
- Processeur : Intel Xeon 8375C (Ice Lake)
- vCPU : 4 cœurs
- Mémoire : 16 Go
- Stockage : 128 Go avec 3 000 IOPS et un débit de 125 Mo/s
Nous avons mené trois types de tests :
- Surveillance à charge nulle – Agents en cours d'exécution avec MySQL au repos (6 minutes)
- Surveillance à charge lourde – Agents en cours d'exécution pendant une importation de base de données de 26 Go (environ 2.5 heures)
- Fonctionnalité d'alerte – Configuration des alertes, disponibilité des canaux et qualité des alertes
- Test de vitesse des alertes – Vitesse de livraison des notifications par e-mail et Slack
- Évaluation des tableaux de bord – Évaluation de la fonctionnalité de l'interface utilisateur et de l'architecture de l'information
Les organisations qui planifient des évaluations similaires doivent noter que les budgets d'observabilité sont de plus en plus protégés, la plupart des entreprises considérant la surveillance des bases de données comme une infrastructure critique plutôt que comme un outillage optionnel5.
Ajouter comme source préféréeMéthodologie
Nous avons testé chaque plateforme dans des conditions identiques pour garantir une comparaison équitable.
Installation : Nous avons commencé avec des installations d'agents neuves sur le même serveur. Nous avons suivi le flux d'intégration par défaut de chaque plateforme, sans configuration avancée. Nous avons documenté chaque étape, y compris les captures d'écran.
Surveillance des ressources : Exécution de scripts personnalisés pour collecter le CPU de l'agent, la mémoire, les E/S disque et l'utilisation du réseau toutes les 2 secondes. Testés dans deux scénarios : MySQL au repos et pendant une importation de base de données de 26 Go.
Précision des métriques : Exécution d'une importation de base de données pour solliciter le système et évaluation de la précision avec laquelle chaque plateforme mesurait l'utilisation du CPU, la consommation de mémoire et le trafic réseau par rapport aux valeurs réelles du système.
Alertes : Configuré des alertes identiques (mémoire >50 % pendant 1 minute) sur toutes les plateformes. Utilisé stress-ng pour déclencher l'alerte en poussant la mémoire à 70 %. Mesuré le délai de livraison des notifications et testé plusieurs canaux.
Évaluation des tableaux de bord : Évalué les tableaux de bord par défaut, prêts à l'emploi, immédiatement après la configuration. Aucune configuration personnalisée ; nous avons évalué ce que chaque plateforme fournit automatiquement.
Tous les tests ont utilisé les paramètres par défaut. Ces plateformes offrent de nombreuses options de personnalisation, mais nous sommes concentrés sur l'expérience du premier jour : ce que vous obtenez lorsque vous installez l'agent et commencez à collecter des données.
Remarque sur la personnalisation
Les trois plateformes vous permettent de créer des tableaux de bord personnalisés. Vous pouvez glisser-déposer des widgets, ajouter vos propres requêtes et créer précisément les vues dont vous avez besoin. Notre évaluation s'est concentrée sur les tableaux de bord par défaut, prêts à l'emploi, car c'est ce que vous utiliserez pendant les premières heures ou les premiers jours avec une nouvelle plateforme de surveillance.
SolarWinds fournit une analyse au niveau des requêtes et des fonctionnalités d'optimisation qui n'existent ni dans les tableaux de bord par défaut de New Relic ou de Datadog, ni même dans leurs constructeurs de tableaux de bord personnalisés. L'onglet Profileurs, la fonctionnalité Conseillers et les ventilations détaillées de l'exécution des requêtes sont uniques à l'approche de surveillance MySQL de SolarWinds.
Contexte sectoriel
Le paysage de la surveillance des bases de données a considérablement évolué au début de 2026, avec plusieurs tendances clés affectant le choix des plateformes :
Observabilité propulsée par l'IA : Les trois plateformes intègrent désormais la détection d'anomalies pilotée par l'IA et l'analyse prédictive en tant que fonctionnalités standard. Les organisations indiquent que 96 % des responsables informatiques s'attendent à ce que les dépenses d'observabilité restent stables ou augmentent, avec 62 % qui prévoient des hausses5.
Consolidation des outils : 84 % des organisations consolident activement leurs outils d'observabilité, 41 % réduisant déjà leur nombre de plateformes et 43 % supplémentaires évaluant la consolidation5. Cette tendance rend les plateformes complètes comme celles testées ici de plus en plus précieuses.
Capacités MySQL améliorées : Les versions modernes de MySQL offrent des fonctionnalités de schéma de performance améliorées et des capacités avancées d'analyse des requêtes, les organisations atteignant jusqu'à 42 % d'amélioration du temps d'exécution des requêtes grâce à des techniques de surveillance améliorées4.
Pour aller plus loin
Top 8 des logiciels d'observabilité avec comparaison des prix et des fonctionnalités
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 Sezer, Sena},
title = {{Surveillance de MySQL: SolarWinds vs New Relic vs Datadog}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/mysql-monitoring}},
note = {AIMultiple. Consulté le 12 Juin 2026}
}Résultats et horodatages de 18 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 6 fichiers CSV.
Vous voulez les données détaillées derrière ? Rejoindre Premium
Journal des modifications
2 mises à jour- 2026
Ajout de fonctionnalités améliorées par l'IA au corps principal.
- 2025
Une section méthodologique a été ajoutée à l'article.
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.
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.