Supervision 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 afin de voir comment elles gèrent la surveillance des bases de données à partir de zéro.
Nous avons examiné : la facilité d'installation, l'expérience d'intégration, la consommation des ressources des agents, la précision des mesures et l'efficacité des notifications de leurs systèmes d'alerte lorsque des problèmes surviennent dans des conditions réelles de charge de travail de bases de données.
Résultats des tests de performance des outils de surveillance des performances MySQL
Plate-forme | Temps de préparation | Profilage des requêtes | Précision de l'opération | Vitesse d'alerte | Idéal pour |
|---|---|---|---|---|---|
8 min | ✅ | ✅ 5 000/5 000 (100 %) | 3ème | Optimisation des bases de données | |
New Relic | 8 min | ❌ | ❌ 3 847/5 000 (sous-dénombrement de 23 %) | 1er | Surveillance des applications |
Datadog | 12 min | ❌ | Peu clair | 2ème | Surveillance de l'infrastructure |
Consultez notre méthodologie de test MySQL complète et nos résultats.
La plateforme SolarWinds était la seule à proposer un profilage au niveau des requêtes, permettant d'identifier les requêtes lentes, les index manquants et les goulots d'étranglement des performances. Elle a également suivi avec précision chaque opération de base de données lors de notre test d'importation de 26 Go.
New Relic a envoyé les alertes le plus rapidement, mais a largement sous-estimé le nombre d'opérations et n'a fourni aucune analyse des requêtes.
Datadog nécessitait une configuration manuelle très poussée et n'offrait que des indicateurs de base.
Vous pouvez également observer comment ces plateformes surveillent MongoDB . Notre analyse reflète le paysage de l'observabilité en 2026, où 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 rendent le choix de la plateforme de plus en plus stratégique. 1 .
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 sont affichées en premier.
Après avoir sélectionné MySQL, la plateforme vérifie si des agents sont déjà en cours d'exécution.
Une fonctionnalité se distingue particulièrement : 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 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 d'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 l'avons nommée « AIMULTIPLE-MYSQL » et avons activé la surveillance de l'hôte pour suivre les indicateurs du serveur ainsi que les statistiques de la base de données.
Copiez le script, exécutez-le sur le serveur et l'agent s'installera. La clé API est automatiquement incluse dans le script ; aucune configuration supplémentaire n'est donc nécessaire.
Nous nous attendions à une confirmation d'installation réussie , mais rien ne s'affiche. L'exécution de la commande est terminée, mais nous ne pouvons que 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.
Il présente ensuite les modèles d'alerte 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 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.
Le point confus : SolarWinds a installé son agent de base, et non l’agent de surveillance MySQL. Vous devez donc ajouter la surveillance de la base de données séparément. L’interface utilisateur n’indique pas clairement ce point lors de la configuration initiale.
Le programme SolarWinds demande désormais les identifiants MySQL. L'interface pourrait être plus claire, car elle n'indique pas d'emblée les autorisations nécessaires à l'utilisateur de surveillance.
Mais voici la partie intéressante : lorsque vous entrez 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.
Problème : l’écran précédent n’indique pas l’existence de ce script. Lors de notre test, nous avons créé manuellement un utilisateur de surveillance, pour découvrir ensuite que SolarWinds génère automatiquement le script de création.
Le script SQL généré crée l'utilisateur, lui accorde l'accès au schéma de performance et configure toutes les permissions requises. Copiez ces commandes, exécutez-les dans MySQL, puis appliquez les modifications de configuration MySQL recommandées.
Une incohérence : le champ 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 avons nommé l’instance « AIMULTIPLE-MYSQL » lors de la configuration, mais l’interface affichait 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é des bases de données SolarWinds grâce à une surveillance approfondie de MySQL et au profilage des requêtes. Explorez SolarWinds.
Visitez le site web2. Nouvelle relique
New Relic adopte une approche différente. Au lieu de se demander ce qu'il faut surveiller, l'entreprise commence par l'installation de l'agent.
Après la connexion, l'écran d'accueil vous invite à 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 un fait 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 de manière autonome, sans intervention de l'utilisateur. Mais l'installation échoue.
En sélectionnant l'installation automatisée sur l'hôte, New Relic propose de créer une nouvelle clé API ou d'en utiliser une existante. L'utilisation d'une clé existante ne propose pas de menu déroulant ; il faut la coller manuellement. La création d'une nouvelle clé étant plus simple, nous avons opté pour cette solution.
L'option permettant de surveiller les requêtes lentes est une fonctionnalité appréciable.
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. Il devrait connaître le type de déploiement.
New Relic fournit un autre script d'installation.
Lors de l'installation, l'interface de ligne de commande demande les identifiants d'accès à MySQL. Contrairement à SolarWinds, qui propose un script SQL dans l'interface utilisateur, New Relic demande le mot de passe root directement dans le terminal.
Le message initial suggère d'utiliser les droits root, que la plupart des utilisateurs ne fourniront pas, même dans un environnement de test.
La confusion vient du fait que le système demande les identifiants root pour créer automatiquement un utilisateur de surveillance , et non pour utiliser root à des fins de surveillance. L'interface devrait proposer deux options claires : « Je vais créer l'utilisateur moi-même » ou « Créer l'utilisateur automatiquement (mot de passe root requis) ».
La vérification de la base de données confirme l'existence d'un utilisateur « newrelic ». Cependant, New Relic n'indique pas les permissions de cet utilisateur. Une plus grande transparence à ce niveau permettrait d'afficher les permissions accordées (par exemple : « Utilisateur « newrelic » créé avec les permissions SELECT, PROCESS et REPLICATION CLIENT ») lors d'une demande d'accès root, ce qui clarifierait les attentes.
Une fois l'installation terminée, nous nous attendions à voir un tableau de bord spécifique à MySQL. Or, l'interface affichait un tableau de bord générique proposant des options pour créer des visualisations personnalisées. Aucun tableau de bord MySQL préconfiguré n'apparaissait automatiquement.
Le processus d'installation n'indiquait pas clairement si :
- Un tableau de bord MySQL apparaîtra ultérieurement, après la collecte des données.
- Nous devions en construire un manuellement.
- Nous avons oublié 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
Temps nécessaire pour terminer : environ 8 minutes
Complexité : Faible (création automatisée d'utilisateurs)
Points forts : Installation ultra-rapide, création automatique des utilisateurs, installation monophasée
Points faibles : Demande de mot de passe root peu claire, absence de tableau de bord MySQL préconfiguré, procédure d’installation manuelle peu intuitive.
Datadog
L'approche de Datadog est la plus interventionniste 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 choisi Linux pour l'installation.
Datadog demande une clé API. Sa création est simple ; le processus se déroule 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û accéder manuellement au 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 les autorisations
- Rédigez un fichier de configuration YAML
- Placez-le dans `/etc/datadog-agent/conf.d/mysql.d/conf.yaml`
Le chemin d'accès au fichier de configuration n'est pas clairement indiqué dans l'interface utilisateur. Vous devez savoir où Datadog stocke les configurations d'intégration, ou consulter la documentation pour le trouver.
Cette approche est plus avancée et technique que la configuration guidée par l'interface utilisateur (voir SolarWinds) ou la création automatique d'utilisateurs par New Relic. Elle nécessite la modification manuelle des fichiers et le redémarrage des services en ligne de commande. Nous avons créé l'utilisateur MySQL avec les permissions requises, rédigé le fichier de configuration YAML, l'avons placé dans le répertoire approprié et avons redémarré l'agent Datadog pour finaliser la configuration.
Après le redémarrage, le tableau de bord Datadog est apparu avec les indicateurs MySQL de base prêts à collecter des données.
Résumé de l'installation
- Temps nécessaire : environ 12 minutes
- Complexité : Élevée (configuration YAML manuelle, aucune configuration guidée)
- Points forts : Contrôle total de la configuration, fonctionne bien si vous connaissez déjà Datadog.
- Points faibles : Absence de détection automatique, nécessite une modification manuelle des fichiers, interface peu intuitive pour les débutants, chemin d’accès aux fichiers peu évident.
Remarque : Ceci décrit 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 des agents
Nous avons testé l'utilisation des ressources des agents dans deux scénarios : charge nulle sur la base de données (surveillance en veille) et charge importante (lors de l'importation d'une base de données de 26 Go). Les deux tests ont duré environ 6 à 7 minutes, les trois agents collectant les données simultanément.
Consommation du processeur
- La consommation du processeur est restée minimale sur tous les agents. Même en cas de forte charge de la base de données, l'utilisation moyenne est restée largement inférieure à 1 % sur les trois plateformes.
- Datadog a enregistré un pic d'utilisation du processeur de 3,20 % lors d'une forte charge, mais ces pics étaient brefs et peu fréquents. Les trois agents ont passé la majeure partie de leur temps inactifs ou avec une utilisation du processeur inférieure à 0,5 %.
Utilisation de la mémoire
- New Relic a consommé beaucoup moins de mémoire, environ 3 à 5 fois moins que les deux autres plateformes. L'utilisation de la mémoire est restée stable, aussi bien en mode veille qu'en pleine charge, pour les trois agents.
E/S disque
Charge zéro
Charge lourde
Les profils d'E/S disque présentaient des caractéristiques distinctes pour chaque agent :
- Datadog a effectué la plupart des lectures sur disque, mais la plus faible écriture. Cela suggère des accès disque plus fréquents pour la récupération des données, avec une mise en mémoire tampon locale minimale.
- Le fichier SolarWinds a enregistré localement une quantité de données nettement supérieure aux deux autres (environ deux à trois fois plus). Cela indique une mise en mémoire tampon locale plus importante ou une journalisation plus détaillée.
- New Relic a équilibré les lectures et les écritures, effectuant le moins de lectures disque possible tout en maintenant une activité d'écriture modérée.
Il est intéressant de noter que les E/S disque ont légèrement diminué sous forte charge de base de données pour les trois agents. L'activité disque des agents n'a pas varié proportionnellement à la charge de travail de la base de données ; elle a conservé des schémas constants, quelle que soit la charge de travail de MySQL.
Précision métrique
Nous avons effectué une importation de base de données de 26 Go pour mettre le système à l'épreuve et évaluer la précision avec laquelle chaque plateforme mesurait la consommation de ressources.
Mesure du processeur
Les trois plateformes ont suivi l'utilisation du processeur pendant l'importation avec une précision similaire. Datadog et SolarWinds ont fourni une granularité d'une minute, tandis que New Relic a échantillonné toutes les deux minutes. Les mesures concordaient entre les plateformes, sans écart significatif.
Graphique du processeur SolarWinds – indiquant une utilisation d'environ 45 à 60 % pendant l'importation
Graphique du processeur New Relic – présentant un schéma similaire
Graphique du processeur Datadog – affichant un graphique à aires empilées des états du processeur
Mesure de la mémoire
Cela a révélé un problème critique chez New Relic.
Lors de l'importation, le serveur a consommé près de 100 % de la RAM disponible. Voici les résultats obtenus sur chaque plateforme :
SolarWinds: A affiché avec précision une utilisation de la mémoire d'environ 100 %
New Relic : utilisation de la mémoire signalée à seulement ~10 %.
Graphique de mémoire Datadog – comparant la RAM totale à la RAM utilisée à environ 16 Go
New Relic n'a absolument pas détecté le pic de mémoire. Il ne s'agit pas d'une simple erreur de mesure ; l'écart est considérable. Si vous vous fiez aux alertes de mémoire ou à la planification de la capacité, ce type d'imprécision compromet l'ensemble du système de surveillance.
Mesure du réseau
New Relic et Datadog ont capturé le trafic réseau avec précision lors de l'importation, SolarWinds ont sous-estimé l'utilisation du réseau, manquant une partie de l'activité.
Graphique de réseau SolarWinds – illustrant le débit du réseau avec quelques lacunes dans les données
Graphique du réseau New Relic – affichant l'ensemble des données de réception/transmission du réseau
Graphique réseau Datadog – illustrant une capture précise du trafic réseau
La granularité des mesures est restée cohérente avec le processeur : SolarWinds et Datadog échantillonnait toutes les minutes, New Relic toutes les 2 minutes.
Performances d'alerte
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 une minute. Ensuite, nous avons déclenché manuellement l’alerte à l’aide de l’outil stress-ng pour pousser l’utilisation de la mémoire à 70 %.
SolarWinds Configuration de l'alerte – affichage du seuil de mémoire défini à >50 % pendant 1 minute
Configuration des alertes New Relic – présentation du mode guidé avec les paramètres de seuil et un aperçu des séries temporelles
Configuration des alertes Datadog – affichage de la configuration du moniteur de métriques avec les détails d'évaluation
Toutes les alertes ont été paramétrées au niveau de priorité « Critique ». Nous avons testé les notifications par e-mail et Slack.
Configuration des alertes
New Relic offre le contrôle précis du temps d'attente. Alors que Datadog et d'autres plateformes imposent un seuil minimal d'une minute, New Relic permet de configurer des alertes pour des conditions d'une durée aussi courte que 10 secondes. Cette flexibilité permet de détecter les pics d'activité brefs qui pourraient se résorber avant d'atteindre la minute sur d'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 proposent tous deux des options de notification. Datadog n'accepte que les notifications par e-mail dans sa configuration par défaut ; une configuration supplémentaire peut être nécessaire pour d'autres canaux.
Options de notification New Relic – affichant une liste exhaustive incluant ServiceNow, Webhooks, Jira, Slack, Teams, Email et PagerDuty
SolarWinds options de notification – affichage du menu déroulant des services avec AmazonSNS, Email, Microsoft Teams, New Relic, OpsGenie, PagerDuty, ServiceNow
Vitesse de notification
Nous avons lancé le test de charge 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 courriel :
New Relic – Premier à arriver
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é en premier, et incluant des boutons interactifs directement dans le message Slack pour accuser réception des alertes ou les examiner.
- SolarWinds – Livré en second, mais sous forme de notifications en texte brut
L'intégration de Slack par New Relic s'est particulièrement distinguée. Le format de messagerie interactif 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 alertes par e-mail de Datadog contenaient des informations claires : l’élément déclencheur, les valeurs actuelles et un lien direct vers les tableaux de bord pertinents. Professionnelles et informatives.
Les e-mails d'alerte de New Relic suivaient un format similaire, avec des détails précis et des appels à l'action clairs .
Les courriels d'alerte « SolarWinds » étaient succincts, peu détaillés, mal formatés et contenaient peu d'informations exploitables. Bien qu'ils fonctionnaient, leur présentation était moins soignée que celle des deux autres plateformes.
Configuration de l'intégration Slack
New Relic : Cliquez sur « Ajouter Slack », authentifiez-vous instantanément et sélectionnez vos canaux. C’est simple comme bonjour.
SolarWinds : Cliquez sur « Ajouter Slack », authentifiez-vous et sélectionnez les canaux. Tout aussi simple.
La configuration des deux a pris moins d'une minute.
Comparaison du tableau de bord et de l'interface utilisateur
Nous avons évalué les tableaux de bord MySQL par défaut fournis par chaque plateforme. Il ne s'agit pas de vues personnalisées ; c'est ce que vous voyez immédiatement après l'installation de l'agent et la collecte des données.
Aperçu du tableau 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ête
- Connexions actives
C’est ce qu’un administrateur de base de données ou un directeur technique souhaite voir en premier. Ces indicateurs sont généraux, exploitables et immédiatement utiles pour évaluer l’état de santé de la base de données.
SolarWinds Vue d'ensemble du tableau de bord MySQL – affichage des indicateurs de qualité de service avec des graphiques de temps de réponse, de débit et d'erreurs
New Relic propose un tableau de bord plus riche en données, avec de nombreux graphiques affichant les indicateurs au fil du temps. On y trouve une multitude d'informations telles que le nombre de connexions par seconde, la durée des requêtes et le débit, mais ces données sont organisées sous forme de graphiques chronologiques plutôt que de synthèses de l'état actuel. L'interface permet d'obtenir des tendances détaillées, mais moins de chiffres visibles d'un seul coup d'œil.
Tableau de bord MySQL de New Relic – affichant les connexions à la base de données, les opérations, les requêtes et les graphiques de débit
Datadog propose le tableau de bord par défaut le plus minimaliste. Il affiche quelques indicateurs de base, mais manque de la profondeur de données de SolarWinds ou du niveau de détail des tendances de New Relic. Une bizarrerie : les « connexions échouées » apparaissent en évidence en haut d’un indicateur axé sur la sécurité, alors que c’est rarement la première chose dont on a besoin pour vérifier les performances d’une base de données.
Tableau de bord Datadog MySQL – affichant un moniteur d'activité de base avec des sections sur les performances et le débit
Fonctionnalités d'analyse détaillée
SolarWinds comprend plusieurs onglets en plus de l'aperçu :
- Inventaire – Affiche les modèles de requêtes les plus fréquents, les temps d'attente (causes des ralentissements) et des options de filtrage détaillées. Vous pouvez ainsi identifier les requêtes les plus gourmandes en ressources et les points de blocage.
- Profilage – Affiche les modèles de requêtes classés par temps d'exécution total et consommation du processeur. Cette fonctionnalité est essentielle pour l'optimisation : elle permet d'identifier les types de requêtes les plus coûteux et de prioriser les corrections en conséquence. Les options de tri et de filtrage facilitent la recherche des requêtes problématiques.
- Santé – Évalue l'état général de la base de données et signale les problèmes. Lors de notre test en fonctionnement normal, le résultat était au vert.
- Requêtes – Affiche la liste de toutes les requêtes, regroupées par modèle, avec des options de filtrage avancées. Cliquez sur une requête pour consulter le nombre d'exécutions, 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) ainsi que les métriques MySQL. Ce contexte permet de distinguer les problèmes de base de données des problèmes d'infrastructure sous-jacente.
- Conseillers – Fournit des recommandations pour améliorer les performances, la sécurité et la configuration. Cette fonctionnalité n'est pas présente 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 l'information différemment. Le tableau de bord privilégie les visualisations de séries temporelles, avec de nombreux graphiques illustrant les tendances. Il est possible d'explorer des périodes spécifiques et d'obtenir des analyses détaillées, mais l'accent est moins mis sur les données tabulaires ou les synthèses de l'état actuel. L'interface semble davantage adaptée à l'exploration des tendances historiques qu'à l'obtention de réponses immédiates sur la situation actuelle.
Datadog simplifie le tableau de bord. Il affiche les indicateurs MySQL de base et, point utile, la consommation des ressources de l'hôte sur la même page. Cependant, il lui manque les fonctionnalités d'analyse et d'optimisation au niveau des requêtes proposées par SolarWinds.
Tableaux de bord de surveillance des hôtes
Nous avons également vérifié le tableau de bord de surveillance général 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 exploitables concernant MySQL plutôt que sur une apparence soignée.
New Relic offre une vue claire et épurée. Les indicateurs clés sont faciles à repérer et l'interface ne surcharge pas d'informations. Elle est élégante et moderne tout en restant fonctionnelle.
Datadog affiche des informations détaillées, mais avec une mise en page plus chargée. Des indicateurs plus avancés sont disponibles, mais les chiffres récapitulatifs sont moins nombreux. 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 intègrent des fonctionnalités basées sur l'IA en standard :
SolarWinds inclut désormais des analyses prédictives dans son onglet Conseillers, fournissant des recommandations proactives basées sur l'analyse par IA des modèles de requêtes et des tendances des ressources.
New Relic a amélioré sa détection d'anomalies grâce à des modèles d'apprentissage automatique qui établissent automatiquement des bases de référence et signalent les écarts statistiques plutôt que des seuils fixes.
Datadog propose une analyse des causes profondes basée sur l'IA qui met en corrélation les indicateurs de base de données avec les performances des applications et les données d'infrastructure afin d'accélérer le dépannage.
Ces fonctionnalités d'IA représentent la transition 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éagir. 3 .
Détails au niveau de la requête
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 :
- Nombre total d'exécutions
- Temps d'exécution moyen
- Analyse de la consommation du processeur
- Temps d'attente pour les serrures
- Lignes examinées par rapport aux lignes renvoyé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êtes dédiés de SolarWinds.
Surveillance MySQL améliorée : Les déploiements MySQL modernes bénéficient de fonctionnalités de schéma de performance optimisées et d’informations avancées sur l’exécution des requêtes. Les entreprises qui exploitent ces fonctionnalités améliorées constatent des gains de performance significatifs, certaines atteignant une réduction de 42 % du temps d’exécution des requêtes grâce à des stratégies de surveillance optimisées. 4 .
Ce que nous avons testé
Nous avons déployé des agents de SolarWinds , New Relic et Datadog sur le même serveur afin de surveiller une instance MySQL. Chaque outil a suivi l'intégralité de son processus d'installation et nous avons enregistré les opérations suivantes :
- Comment le processus d'intégration vous guide tout au long de la configuration
- Ce que le processus d'installation vous demande
- Consommation de ressources de l'agent (utilisation de la mémoire et du processeur)
- Précision des métriques lors du chargement de la base de données
- Configuration des alertes et vitesse de notification
- ergonomie du tableau de bord et 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 réalisé trois types de tests :
- Surveillance de la charge nulle – Agents fonctionnant avec MySQL inactif (6 minutes)
- Surveillance des charges importantes – Agents en cours d'exécution pendant l'importation d'une base de données de 26 Go (environ 2,5 heures)
- Fonctionnalités d'alerte – Configuration des alertes, disponibilité des canaux et qualité des alertes
- Test de vitesse d'alerte – Vitesse de distribution des notifications par e-mail et Slack
- Évaluation du tableau de bord – Analyse des fonctionnalités de l’interface utilisateur et de l’architecture de l’information
Les organisations qui prévoient 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 outil optionnel. 5 .
Méthodologie
Nous avons testé chaque plateforme dans des conditions identiques afin de garantir une comparaison équitable.
Installation : J’ai commencé par installer les agents sur le même serveur. J’ai suivi la procédure d’intégration par défaut de chaque plateforme sans configuration avancée. J’ai documenté chaque étape, captures d’écran à l’appui.
Surveillance des ressources : Des scripts personnalisés ont été exécutés pour collecter l’utilisation du processeur, de la mémoire, des E/S disque et du réseau de l’agent toutes les 2 secondes. Tests effectués dans deux scénarios : MySQL inactif et lors de l’importation d’une base de données de 26 Go.
Précision des mesures : Nous avons effectué une importation de base de données pour tester la robustesse du système et évalué la précision avec laquelle chaque plateforme mesurait l'utilisation du processeur, la consommation de mémoire et le trafic réseau par rapport aux valeurs réelles du système.
Alertes : Des alertes identiques (mémoire > 50 % pendant 1 minute) ont été configurées sur toutes les plateformes. Un test de charge a été utilisé avec stress-ng pour déclencher l’alerte en poussant la mémoire à 70 %. Le délai de notification a été mesuré et plusieurs canaux ont été testés.
Évaluation des tableaux de bord : Nous avons évalué les tableaux de bord par défaut, prêts à l’emploi, immédiatement après leur installation. Sans configuration personnalisée, nous avons évalué les fonctionnalités fournies automatiquement par chaque plateforme.
Tous les tests ont été effectués avec les paramètres par défaut. Ces plateformes offrent de nombreuses options de personnalisation, 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.
Note de personnalisation
Les trois plateformes 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 ce sont ceux que vous utiliserez lors des premières heures ou des premiers jours avec une nouvelle plateforme de supervision.
SolarWinds propose 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 outils de création de tableaux de bord personnalisés. L'onglet Profilers, la fonctionnalité Advisors et les analyses détaillées de l'exécution des requêtes sont spécifiques à l'approche de surveillance MySQL de SolarWinds.
Contexte industriel
Le paysage de la surveillance des bases de données a considérablement évolué début 2026, avec plusieurs tendances clés influençant le choix de la plateforme :
Observabilité basée sur l'IA : Les trois plateformes intègrent désormais la détection d'anomalies et l'analyse prédictive pilotées par l'IA en standard. Selon les entreprises, 96 % des responsables informatiques prévoient que leurs dépenses en matière d'observabilité resteront stables ou augmenteront, dont 62 % anticipent une hausse. 6 .
Consolidation des outils : 84 % des organisations consolident activement leurs outils d’observabilité, dont 41 % réduisent déjà le nombre de leurs plateformes et 43 % évaluent une éventuelle consolidation. 7 Cette tendance rend les plateformes complètes comme celles testées ici de plus en plus précieuses.
Améliorations des fonctionnalités MySQL : Les versions modernes de MySQL offrent des fonctionnalités de schéma optimisées pour de meilleures performances et des capacités d’analyse de requêtes avancées. Grâce à des techniques de surveillance améliorées, les entreprises peuvent ainsi réaliser jusqu’à 42 % d’amélioration du temps d’exécution des requêtes. 8 .
Pour en savoir plus
Les 8 meilleurs logiciels d'observabilité : comparaison des prix et des fonctionnalités
Liens de référence
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.