Surveillance MySQL: SolarWinds contre New Relic contre Datadog
Nous avons installé trois plateformes de surveillance de bases de données sur un système propre exécutant MySQL pour observer comment elles gèrent la surveillance de base de données à partir de zéro.
Nous avons examiné : Facilité de configuration, expérience d'intégration, consommation de ressources par l'agent, précision des mesures de métriques et efficacité des notifications de leurs systèmes d'alerte lorsqu'apparaissent des problèmes sous des charges de travail réelles sur la base de données.
Résultats du test comparatif des outils de surveillance des performances MySQL
Plateforme | Temps de configuration | Analyse 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 (sous-comptage de 23 %) | 1er | Surveillance d'applications |
Datadog | 12 min | ❌ | Indéterminé | 2e | Surveillance d'infrastructure |
Consultez notre méthodologie complète de test MySQL et les résultats.
SolarWinds est la seule plateforme ayant fourni un profilage au niveau des requêtes, identifiant les requêtes lentes, les index manquants et les goulots d'étranglement de performance. Elle a également suivi chaque opération de base de données avec précision lors de notre test d'importation de 26 Go.
New Relic a envoyé les alertes le plus rapidement mais a fortement sous-compté les opérations et n'a fourni aucune analyse de requête.
Datadog a nécessité la configuration manuelle la plus importante et offrait uniquement 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. Le changement vers une observabilité des bases de données pilotée par l'IA et la consolidation des outils rendent la sélection de la plateforme de plus en plus stratégique1 .
Installation et expérience d'intégration
1. SolarWinds
SolarWinds commence par une question : Que voulez-vous surveiller ?
Lorsque vous sélectionnez la performance de la base de données, les bases de données prises en charge sont affichées en premier plan.
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 d'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 API key, puis vous permet de spécifier un nom d'hôte pour votre instance.
Après avoir créé la API key, 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 parallèle des 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 API key, donc aucune configuration supplémentaire n'est nécessaire.
Nous nous attendions à voir une confirmation « installation réussie », mais rien n'apparaît. L'exécution de la commande est terminée et vous devez supposer que cela 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'alerte par défaut. Ce sont des alertes au niveau de l'hôte (CPU, mémoire, disque) car nous avons activé la surveillance de l'hôte précédemment. Aucune alerte spécifique à MySQL n'apparaît à ce stade, même si nous configurons la surveillance de la base de données.
La partie déroutante : 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 au préalable les autorisations dont l'utilisateur de surveillance a besoin.
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. Dans 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 toutes les modifications recommandées de configuration MySQL.
Une incohérence : le champ de nom d'utilisateur par défaut affiche « user on [system hostname] » au lieu du nom d'hôte spécifié lors de l'installation de l'agent. Dans notre cas, nous avions nommé l'instance « AIMULTIPLE-MYSQL » lors de la configuration, mais l'interface affichait le nom d'hôte réel du serveur à la place.
Après avoir exécuté les commandes SQL et mis à jour la configuration MySQL, cliquez sur « Observe database ».
Le tableau de bord apparaît, vide et prêt à collecter des données.
Découvrez SolarWinds Database Observability avec surveillance MySQL approfondie et profilage de requêtes. Explorez SolarWinds.
Visitez le site web2. New Relic
New Relic adopte une approche différente. Au lieu de demander ce qu'il faut surveiller, il commence par l'installation de l'agent.
Après la connexion, l'écran d'intégration invite à installer l'agent en premier. Sélectionnez Linux comme système d'exploitation.
Comme aucune API key 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 inclut un commutateur utile : « répondre automatiquement oui à toutes les invites ». Activez-le 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 tout seul, sans intervention de l'utilisateur. Mais l'installation échoue.
En sélectionnant l'installation « automatisée sur hôte », New Relic demande de créer une nouvelle API key ou d'utiliser une existante. Choisir d'utiliser la clé existante ne propose pas de menu déroulant ; 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.
Le commutateur de surveillance des requêtes lentes est une belle touche.
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 auparavant. Il devrait connaître le type de déploiement.
New Relic fournit un autre script d'installation.
Pendant l'installation, l'interface en ligne de commande 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, pas pour utiliser root pour la surveillance. L'interface devrait présenter deux options claires : « Je créerai 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 ne montre pas quelles autorisations cet utilisateur a. Une transparence ici aiderait à afficher les autorisations accordées (par exemple, « Créé l'utilisateur 'newrelic' avec les autorisations SELECT, PROCESS et REPLICATION CLIENT ») lors de la demande du mot de passe root, établissant ainsi des attentes plus claires.
Après la fin de l'installation, nous nous attendions à voir un tableau de bord spécifique à MySQL. Au lieu de cela, l'interface a montré 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'était pas clair sur :
- Un tableau de bord 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 pour voir si un tableau de bord se remplirait avec des données au fil du temps.
Résumé de l'installation
Temps nécessaire : ~8 minutes
Complexité : Faible (création automatique d'utilisateur)
Atouts : Configuration la plus rapide, création automatique d'utilisateur, installation en une seule phase
Défauts : Demande de mot de passe root peu claire, aucun tableau de bord MySQL prédéfini, chemin de configuration manuel pas évident
Datadog
L'approche de Datadog est la plus manuelle des trois plateformes.
Après la connexion, l'interface invite à installer d'abord l'agent de base. Plusieurs méthodes de déploiement sont disponibles. Nous avons sélectionné Linux pour l'installation.
Datadog demande une API key. 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 MySQL, aucun invite pour configurer la surveillance de la base de données. Nous avons dû naviguer manuellement vers le Marketplace et rechercher MySQL.
Après avoir sélectionné l'intégration MySQL, une fenêtre pop-up apparaît avec les instructions d'installation.
Datadog fournit une liste de contrôle :
- Créer un utilisateur de surveillance dans MySQL
- Accorder les autorisations
- Écrire un fichier de configuration YAML
- Le placer dans `/etc/datadog-agent/conf.d/mysql.d/conf.yaml`
Le chemin du fichier de configuration n'est pas clairement indiqué dans l'interface. Vous devez savoir où Datadog stocke les configurations d'intégration, ou parcourir la documentation pour le trouver.
Cette approche est plus avancée et technique comparée à la configuration guidée par l'interface de SolarWinds ou à la création automatique d'utilisateur de New Relic. Vous modifiez manuellement des fichiers et redémarrez des services depuis la ligne de commande. Nous avons créé l'utilisateur MySQL avec les autorisations requises, rédigé le fichier de configuration YAML, l'avons placé dans le répertoire correct 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
- Temps nécessaire : ~12 minutes
- Complexité : Élevée (configuration YAML manuelle, pas de configuration guidée)
- Atouts : Contrôle total sur la configuration, fonctionne bien si vous connaissez déjà Datadog
- Défauts : Pas de détection automatique, nécessite l'édition manuelle de fichiers, pas convivial pour les débutants, chemin du fichier pas é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 de ressources par l'agent
Nous avons testé l'utilisation des ressources par l'agent dans deux scénarios : aucune charge de base de données (surveillance au repos) et charge élevée (pendant une importation de base de données de 26 Go). Les deux tests ont duré environ 6 à 7 minutes avec les trois agents collectant des données simultanément.
Consommation de CPU
- La consommation de CPU est restée minimale pour tous les agents. Sous charge élevée de la base de données, la moyenne est restée bien en dessous de 1 % pour les trois plateformes.
- Datadog a affiché le pic le plus élevé à 3,20 % sous charge élevée, mais ces pics étaient brefs et peu fréquents. Les trois agents ont passé la majorité de leur temps au repos ou sous 0,5 % de consommation de CPU.
Utilisation de la mémoire
- New Relic a consommé nettement moins de mémoire, environ 3 à 5 fois moins que les deux autres plateformes. L'utilisation de la mémoire est restée stable dans les deux scénarios, au repos et sous charge élevée, pour les trois agents.
Entrées/sorties disque
Aucune charge
Charge élevée
Les schémas d'entrée/sortie disque ont montré des caractéristiques distinctes pour chaque agent :
- Datadog a lu le plus sur le disque mais écrit le moins. Cela suggère un accès disque plus fréquent pour la récupération de données avec un tamponnage local minimal.
- SolarWinds a écrit localement significativement plus de données que les deux autres, environ 2 à 3 fois plus. Cela indique un tamponnage local agressif ou une journalisation plus détaillée.
- New Relic a équilibré lectures et écritures, effectuant le moins de lectures disque tout en maintenant une activité d'écriture modérée.
Curieusement, l'activité disque a légèrement diminué sous charge élevée de la base de données pour les trois agents. L'activité disque des agents n'a pas augmenté avec la charge de travail de la base de données ; ils ont maintenu des schémas cohérents indépendamment de la charge de travail de MySQL.
Précision des métriques
Nous avons effectué une importation de base de données de 26 Go pour stresser le système et évaluer la précision avec laquelle 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 échantillonnait toutes les deux minutes. Les mesures étaient alignées entre les plateformes, sans écarts significatifs.
SolarWinds graphique CPU – 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 correctement montré une utilisation mémoire d'environ 100 %
New Relic : a rapporté seulement environ 10 % d'utilisation mémoire
Graphique mémoire de Datadog – montrant la RAM totale contre la RAM utilisée à environ 16 Go
New Relic a complètement manqué le pic de mémoire. Ce n'est pas une simple erreur de mesure ; c'est une erreur d'un ordre de grandeur. Si vous comptez sur des alertes de mémoire ou sur la planification de la capacité, ce type d'imprécision 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, SolarWinds a sous-estimé l'utilisation du réseau, manquant une partie de l'activité.
Graphique réseau de SolarWinds – montrant le débit réseau avec des 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é de mesure est restée cohérente avec celle du CPU : SolarWinds et Datadog échantillonnaient toutes les minutes, New Relic toutes les deux minutes.
Performance des alertes
Nous avons configuré la même alerte sur les trois plateformes : envoyer une notification si l'utilisation 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 mémoire défini à >50 % pendant 1 minute
Configuration d'alerte de New Relic – montrant le mode guidé avec les paramètres de seuil et l'aperçu de la série temporelle
Configuration d'alerte de Datadog – montrant la configuration du moniteur de métrique avec les détails d'évaluation
Toutes les alertes ont été définies sur priorité « Critique ». Nous avons testé les notifications par e-mail et Slack.
Configuration des alertes
New Relic propose les contrôles temporels les plus granulaires. Alors que SolarWinds et Datadog exigent des seuils de durée minimum d'une minute, New Relic vous permet de définir des alertes pour des conditions durant aussi peu que 10 secondes. Cette flexibilité permet de détecter de brèves pointes qui pourraient se résoudre avant d'atteindre la marque d'une minute sur d'autres plateformes.
SolarWinds et Datadog exigent tous deux des durées minimum d'une minute pour les alertes de seuil.
Canaux de notification
New Relic et SolarWinds proposent 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 incluant ServiceNow, Webhooks, Jira, Slack, Microsoft Teams, E-mail, PagerDuty
Options de notification de SolarWinds – montrant le menu déroulant de service avec AmazonSNS, E-mail, Microsoft Teams, New Relic, OpsGenie, PagerDuty, ServiceNow
Rapidité des notifications
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 – Dernier
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ée en premier, et incluait des boutons interactifs directement dans le message Slack pour reconnaître ou investiguer les alertes
- SolarWinds – Livrée 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 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 incluaient 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 succincts, avec peu de détails, une mauvaise mise en forme et moins d'informations exploitables. Les e-mails fonctionnaient, mais 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. Également simple.
Les deux ont pris moins d'une minute à configurer.
Tableau de bord et comparaison d'interface utilisateur
Nous avons évalué les tableaux de bord MySQL par défaut que chaque plateforme fournit dès le départ. Il ne s'agit pas de vues personnalisées, c'est ce que vous voyez immédiatement après avoir installé l'agent et commencé à collecter des données.
Aperçu du tableau de bord
SolarWinds ouvre directement sur 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ête
- Connexions actives
C'est ce que veut voir un administrateur de base de données ou un directeur technique en premier. Les métriques sont de haut niveau, exploitables et immédiatement utiles pour évaluer la santé de la base de données.
Tableau de bord MySQL de SolarWinds – montrant les métriques de qualité de service avec les 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 des métriques dans le 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 temporels plutôt que de résumés d'état actuel. Vous obtenez des tendances détaillées mais moins de chiffres immédiats.
Tableau de bord MySQL de New Relic – montrant les connexions de base de données, opérations, requêtes et graphiques de débit
Datadog affiche le tableau de bord par défaut le plus minimal. Il affiche certaines métriques de base mais manque de la profondeur de SolarWinds ou du détail des tendances de New Relic. Une bizarrerie : « failed connects » apparaît en évidence en haut d'une métrique axée sur la sécurité, rarement la première chose dont vous avez besoin lors du contrôle des performances de la base de données.
Tableau de bord MySQL de Datadog – montrant un moniteur d'activité de base avec des sections de performance et de débit
Fonctionnalités d'analyse détaillée
SolarWinds inclut plusieurs onglets au-delà de l'aperçu :
- Inventaire – Affiche les modèles de requêtes les plus 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.
- Profilers – Affiche les modèles de requêtes classés par temps d'exécution total et consommation de CPU. C'est essentiel pour l'optimisation : vous pouvez identifier quels types de requêtes vous coûtent le plus 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. Pendant notre test avec un fonctionnement normal, il affichait 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) aux côtés des métriques MySQL. Ce contexte aide à distinguer les problèmes de base de données des problèmes d'infrastructure sous-jacente.
- Advisors – Fournit des recommandations pour l'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 Datadog. SolarWinds suggère activement des optimisations plutôt que de simplement afficher des données.
New Relic organise les informations différemment. Le tableau de bord se concentre sur les visualisations temporelles, beaucoup de graphiques montrant des tendances. Vous pouvez explorer des périodes spécifiques et voir des décomptes détaillés, mais il y a moins d'accent 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, utilement, inclut la consommation des ressources de l'hôte sur la même page. Cependant, il manque des fonctionnalités d'analyse et d'optimisation au niveau des requêtes que SolarWinds fournit.
Tableaux de bord de surveillance d'hôte
Nous avons également vérifié le tableau de bord de surveillance d'hôte général de chaque plateforme (pas spécifique à MySQL).
SolarWinds fournit exactement ce dont un administrateur de base de données a besoin : une interface fonctionnelle et organisée axée sur des informations exploitables sur MySQL plutôt que sur l'aspect visuel.
New Relic présente une vue propre et épurée. Les métriques clés sont faciles à repérer, et l'interface ne vous submerge pas d'informations. Elle est élégante et moderne mais reste fonctionnelle.
Datadog affiche des informations détaillées, mais avec une disposition plus chargée. Plus de métriques avancées sont disponibles, mais il y a moins de chiffres résumés immédiats. 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 fonctionnalités pilotées par l'IA comme fonctionnalités standard :
SolarWinds inclut désormais des analyses prédictives dans son onglet Advisors, fournissant des recommandations proactives basées sur l'analyse IA des modèles de requêtes et des tendances de ressources.
New Relic a amélioré sa détection d'anomalie avec des modèles d'apprentissage automatique qui établissent automatiquement des références et alertent sur les écarts statistiques plutôt que sur des seuils fixes.
Datadog propose une analyse de cause racine piloté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 IA représentent le changement de l'industrie 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 ici 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
- Décomposition de la consommation de CPU
- Temps d'attente de verrou
- Lignes examinées contre lignes retournées et plus encore
New Relic et Datadog affichent tous deux des métriques de requête, mais le niveau de détail et la facilité de navigation ne correspondent pas à ceux des outils de profilage de requête 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 exploitant ces fonctionnalités améliorées rapportent des améliorations significatives des performances, 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 a suivi 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 de ressources par l'agent (mémoire et utilisation du CPU)
- La précision des métriques sous charge de base de données
- La configuration des alertes et la rapidité des notifications
- L'utilisabilité du tableau de bord et l'architecture de l'information
Ajouter comme source préféréeEnvironnement de test
Tous les tests ont été effectués sur une instance Amazon EC2 m6i.xlarge avec les spécifications suivantes :
- Processeur : Intel Xeon 8375C (Ice Lake)
- vCPUs : 4 cœurs
- Mémoire : 16 Go
- Stockage : 128 Go avec 3 000 IOPS et 125 Mo/s de débit
Nous avons effectué cinq types de tests :
- Surveillance sans charge – Agents en cours d'exécution avec MySQL inactif (6 minutes)
- Surveillance sous charge élevée – 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 rapidité des alertes – Rapidité de livraison des notifications par e-mail et Slack
- Évaluation du tableau de bord – Évaluation de la fonctionnalité de l'interface et de l'architecture de l'information
Les organisations planifiant des évaluations similaires devraient noter que les budgets d'observabilité sont de plus en plus protégés, la majorité des entreprises considérant la surveillance de base de données comme une infrastructure critique plutôt qu'un outil optionnel5 .
Méthodologie
Nous avons testé chaque plateforme dans des conditions identiques pour garantir une comparaison équitable.
Installation : Nous avons commencé avec des installations d'agents fraîches 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 des captures d'écran.
Surveillance des ressources : Nous avons exécuté des scripts personnalisés pour collecter l'utilisation du CPU, de la mémoire, des entrées/sorties disque et du réseau de l'agent toutes les 2 secondes. Testé dans deux scénarios : MySQL inactif et pendant une importation de base de données de 26 Go.
Précision des métriques : Nous avons exécuté une importation de base de données pour stresser le système et évalué 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 : Nous avons configuré des alertes identiques (mémoire >50 % pendant 1 minute) sur toutes les plateformes. Nous avons utilisé stress-ng pour déclencher l'alerte en poussant la mémoire à 70 %. Nous avons mesuré le délai de livraison des notifications et testé plusieurs canaux.
Évaluation du tableau de bord : Nous avons évalué les tableaux de bord par défaut, directement après la configuration. Pas de 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 des options de personnalisation étendues, mais nous 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 car c'est ce que vous utiliserez durant les premières heures ou jours avec une nouvelle plateforme de surveillance.
SolarWinds fournit des fonctionnalités d'analyse et d'optimisation au niveau des requêtes qui n'existent pas dans les tableaux de bord par défaut de New Relic ou Datadog, ni même dans leurs générateurs de tableaux de bord personnalisés. L'onglet Profilers, la fonctionnalité Advisors et les décomptes détaillés d'exécution des requêtes sont uniques à l'approche de SolarWinds pour la surveillance MySQL.
Contexte industriel
Le paysage de la surveillance de base de données a évolué considérablement début 2026, avec plusieurs tendances clés affectant le choix de la plateforme :
Observabilité pilotée par l'IA : Les trois plateformes intègrent désormais des analyses prédictives et une détection d'anomalie pilotées par l'IA comme fonctionnalités standard. Les organisations rapportent que 96 % des responsables informatiques s'attendent à ce que les dépenses d'observabilité restent stables ou augmentent, 62 % prévoyant des augmentations6 .
Consolidation des outils : 84 % des organisations sont activement en train de consolider leurs outils d'observabilité, 41 % ayant déjà réduit leur nombre de plateformes et 43 % supplémentaires évaluant une consolidation7 . Cette tendance rend les plateformes complètes comme celles testées ici de plus en plus précieuses.
Capacités améliorées de MySQL : Les versions modernes de MySQL offrent des fonctionnalités améliorées du schéma de performance 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ées8 .
Lectures complémentaires
Les 8 meilleurs logiciels d'observabilité avec comparaison des prix et des fonctionnalités
Citer cette recherche
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{dogan2026,
author = {Dogan, Sedat and Sezer, Sena},
title = {{Surveillance MySQL: SolarWinds contre New Relic contre Datadog}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/mysql-monitoring}},
note = {AIMultiple. Consulté le 12 Juin 2026}
}Liens de référence
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.