Surveillance 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 de l'agent, la précision de la mesure des métriques et l'efficacité des notifications de leurs systèmes d'alerte lorsque des problèmes surviennent sous des charges de travail réelles de bases de données.
Résultats du benchmark des outils de surveillance des performances MySQL
Plateforme | Temps d'installation | Profilage des requêtes | Précision des opérations | Vitesse 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-estimation) | 1er | Surveillance d'applications |
Datadog | 12 min | ✕ | Incertain | 2e | Surveillance d'infrastructure |
Voir notre méthodologie complète de test MySQL et nos résultats.
SolarWinds a fourni la seule plateforme offrant 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 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 par une question : Que souhaitez-vous surveiller ?
Lorsque vous sélectionnez les performances de base de données, les bases de données prises en charge sont affichées d'emblée.
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 un agent Kubernetes est 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 la 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 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 plus des statistiques de 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 « installé avec succès », mais rien n'apparaît. 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 option.
Ensuite, il présente des modèles d'alerte par défaut. Il s'agit d'alertes au niveau de l'hôte (CPU, mémoire, disque) puisque 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 bases 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 base de données séparément. L'interface utilisateur ne le précise pas clairement lors de la configuration initiale.
À présent, SolarWinds demande les identifiants MySQL. L'interface pourrait être plus claire, car elle n'explique pas d'emblée 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 « 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 à 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 SolarWinds Database Observability 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, elle 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 pratique : « 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 tout seul, 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. Créer une nouvelle clé est donc plus simple, et c'est ce que nous avons fait.
L'option de surveillance des requêtes lentes est une bonne idée.
Mais voici une demande étrange : New Relic demande de préciser 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 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, et non pour utiliser root pour la surveillance. L'interface devrait proposer 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. Plus de transparence aiderait à 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, afin de mieux définir 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éconfiguré n'est apparu automatiquement.
Le processus de configuration n'a pas précisé clairement si :
- Un tableau de bord MySQL apparaîtrait plus tard après la collecte des 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 de données au fil du temps.
Résumé de l'installation
Temps nécessaire : ~8 minutes
Complexité : Faible (création automatique de l'utilisateur)
Points forts : Configuration la plus rapide, création automatique de l'utilisateur, installation en une seule phase
Points faibles : Demande de mot de passe root peu claire, pas de tableau de bord MySQL préconfiguré, chemin de configuration manuelle peu évident
Datadog
Datadog adopte l'approche la plus manuelle 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 base de données. Nous avons dû naviguer manuellement dans 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éez un utilisateur de surveillance dans MySQL
- Accordez les autorisations
- Écrivez 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 parcourir la documentation pour le trouver.
Cette approche est plus avancée et technique que la configuration guidée de SolarWinds ou la création automatique d'utilisateur de New Relic. Vous modifiez des fichiers manuellement et redémarrez des services en ligne de commande. Nous avons créé l'utilisateur MySQL avec les autorisations requises, écrit le fichier de configuration YAML, l'avons placé dans le bon répertoire, puis 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)
- 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 une modification manuelle des fichiers, peu adapté aux débutants, chemin du fichier peu visible 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 de l'agent
Nous avons testé la consommation de 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 de CPU
- La consommation CPU est restée minime pour tous les agents. Sous une forte charge de base de données, l'utilisation moyenne est restée bien en dessous de 1 % pour les trois plateformes.
- Datadog a affiché 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 du temps inactifs 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.
Entrées/sorties disque
Charge nulle
Charge lourde
Les modèles d'entrées/sorties disque ont montré des caractéristiques distinctes pour chaque agent :
- Datadog a le plus lu depuis 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 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.
Fait intéressant, les entrées/sorties disque ont en fait légèrement diminué sous une forte charge de base de données 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 échantillonnait toutes les 2 minutes. Les mesures étaient alignées entre les plateformes, sans écarts significatifs.
- SolarWinds graphique CPU : affiche une utilisation d'environ 45-60 % pendant l'importation
- New Relic graphique CPU : affiche un schéma similaire à SolarWinds
- Datadog graphique CPU : affiche un graphique à 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 mesure de la mémoire : a affiché avec précision une utilisation de la mémoire d'environ 100 %
- New Relic mesure de la mémoire : n'a signalé qu'environ 10 % d'utilisation de la mémoire
- Datadog mesure de la mémoire : affiche 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 une erreur d'un ordre de grandeur. Si vous appuyez sur des alertes de mémoire ou la planification des capacités, ce type d'imprécision compromet toute la configuration de surveillance.
Mesure du réseau
New Relic et Datadog ont capturé le trafic réseau avec précision pendant l'importation, SolarWinds a sous-déclaré l'utilisation du réseau, manquant une partie de l'activité.
- SolarWinds graphique réseau : affiche le débit réseau avec quelques lacunes de données
- New Relic graphique réseau : affiche des données de réception/transmission réseau complètes
- Datadog graphique réseau : affiche 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.
Performance 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 %.
- SolarWinds configuration d'alerte : affiche un seuil de mémoire défini sur >50 % pendant 1 minute
- New Relic configuration d'alerte : affiche le mode guidé avec les réglages de seuil et un aperçu des séries temporelles
- Datadog configuration d'alerte : affiche la configuration de la surveillance des métriques avec les détails d'évaluation
Toutes les alertes ont été définies avec 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 fins. 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 des pics brefs qui pourraient se résorber avant d'atteindre la barre d'une minute sur les autres plateformes.
SolarWinds et Datadog exigent tous deux une durée minimale d'une minute pour les alertes de seuil.
Canaux de notification
New Relic et SolarWinds offrent tous deux des options de notification. Datadog n'acceptait que les notifications par e-mail dans notre configuration par défaut ; d'autres canaux peuvent nécessiter une configuration supplémentaire.
- Options de notification de New Relic : affiche une liste étendue incluant ServiceNow, Webhooks, Jira, Slack, Microsoft Teams, E-mail, PagerDuty
- SolarWinds options de notification : affiche une liste déroulante de services avec AmazonSNS, E-mail, Microsoft Teams, New Relic, OpsGenie, PagerDuty, ServiceNow
Vitesse de notification
Nous avons lancé le test de stress de la 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 à quel moment les alertes sont arrivées :
Notifications par e-mail :
- Notifications par e-mail de New Relic : arrivées en premier
- Notifications par e-mail de Datadog : arrivées en deuxième
- Notifications par e-mail de SolarWinds : arrivées en 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é en premier, avec des boutons interactifs directement dans le message Slack pour acquitter ou examiner les alertes
- SolarWinds : livré en deuxième, 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 peu fournis, avec un minimum de détails, une mise en forme médiocre et des informations moins 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. Tout aussi simple.
Les deux ont pris moins d'une minute à configurer.
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 immédiatement. Il ne s'agit pas de vues personnalisées ; c'est ce que vous voyez juste après avoir installé l'agent et collecté des données.
Aperçu du tableau de bord
- SolarWinds aperçu du tableau de bord MySQL : affiche des métriques de qualité de service avec graphiques de temps de réponse, de débit et d'erreurs
- Tableau de bord MySQL de New Relic : affiche des graphiques de connexions à la base de données, d'opérations, de requêtes et de débit
- Datadog tableau de bord MySQL : affiche un moniteur d'activité de base avec des sections de performance et de débit
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ête
- Connexions actives
C'est ce qu'un administrateur de bases 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.
New Relic présente un tableau de bord plus dense en données avec de multiples 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 immédiatement visibles.
Datadog affiche le tableau de bord par défaut le plus minimal. Il présente quelques métriques de base, mais n'a pas la profondeur de SolarWinds ni le détail des tendances de New Relic. Une bizarrerie : « failed connects » apparaît en haut, 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 de la base de données.
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 par consommation du CPU. C'est essentiel pour l'optimisation : vous pouvez identifier les types de requêtes qui 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. Lors de notre test en fonctionnement normal, elle était au vert.
- Requêtes : liste toutes les requêtes, groupées par modèle, avec un filtrage étendu. Cliquez sur une 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) à côté des 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 les informations différemment. Le tableau de bord met l'accent sur les visualisations de séries temporelles, 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 mieux 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, de manière utile, 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 bases de données a besoin : une interface fonctionnelle et organisée, axée sur des informations MySQL exploitables plutôt que sur l'esthétique.
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. Elle est élégante et moderne, mais toujours fonctionnelle.
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 de synthèse immédiatement visibles. 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 comprend désormais des analyses prédictives 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 d'apprentissage automatique qui établissent automatiquement des références de base et alertent sur les écarts statistiques plutôt que sur des seuils fixes.
Datadog propose une analyse des causes racines 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 au lieu de simplement y réagir3.
Détail au niveau des requêtes
C'est là que SolarWinds se démarque 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
- Ventilation de la consommation CPU
- Temps d'attente de verrouillage
- Lignes examinées par rapport aux lignes renvoyé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 n'égalent pas ceux des 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 de Performance Schema 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 performance 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é les agents de SolarWinds, de New Relic et de 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 dans la configuration
- Ce que le processus d'installation exige de vous
- Consommation de ressources de l'agent (utilisation de la mémoire et du CPU)
- Précision des métriques pendant la charge de la base de données
- Configuration des alertes et vitesse de notification
- Utilisabilité du tableau de bord et architecture de l'information
Ajouter comme source préféréeEnvironnement de test de la surveillance MySQL
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 fonctionnement avec MySQL au repos (6 minutes)
- Surveillance à charge lourde – Agents en fonctionnement 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 du tableau 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 qu'un outillage optionnel5.
Méthodologie de surveillance MySQL
Nous avons testé chaque plateforme dans des conditions identiques pour garantir une comparaison équitable.
Installation : nous avons commencé avec de nouvelles installations d'agents 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 toutes les 2 secondes. Testé dans deux scénarios : MySQL au repos et pendant une importation de base de données de 26 Go.
Précision des métriques : nous avons exécuté l'importation de base de données pour solliciter le système et évalué avec quelle précision 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, 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.
Note 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 pas 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.
Pour aller plus loin
Citez ce benchmark
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{dogan2026,
author = {Dogan, Sedat and Ermut, Sıla},
title = {{Surveillance MySQL: SolarWinds vs New Relic vs Datadog}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/mysql-monitoring}},
note = {AIMultiple. Consulté le 16 septembre 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 à jourAjout de fonctionnalités améliorées par l'IA au corps principal.
Liens de référence
- A 20 ans d’expérience en tant que hacker white-hat et gourou du développement, avec une expertise approfondie des langages de programmation et des architectures de serveurs.
- Est conseiller d’administration auprès d’un VC qui investit dans des entreprises technologiques en phase de démarrage et chez Ödeal, une plateforme de paiement numérique régionale servant 125 000 commerçants.
- A dirigé l’infrastructure technologique et la cybersécurité de sept élections nationales, et a été reconnu au Hall of Fame de la cybersécurité par des leaders technologiques mondiaux dont Twitter.
Elle a précédemment travaillé comme recruteuse dans des cabinets de gestion de projet et de conseil. Sıla est titulaire d’un master en psychologie sociale et d’une licence en relations internationales.
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.