MySQL Suivi
Surveillez en temps réel les performances des requêtes MySQL, l'état de la réplication, les pools de connexions et les indicateurs de stockage, sans aucune configuration.
Pourquoi surveiller ? MySQL?
MySQL est la base de données relationnelle open source la plus populaire au monde ; elle est utilisée par des millions d'applications, des start-ups aux entreprises du classement Fortune 500. La surveillance de MySQL est essentielle pour détecter les requêtes lentes, éviter l'épuisement du pool de connexions, suivre le décalage de réplication et optimiser l'utilisation du stockage. L'intégration MySQL de Xitoring offre une visibilité approfondie sur les performances de votre base de données.
La supervision MySQL, expliquée
La supervision MySQL détecte le churn du buffer pool, les requêtes lentes, la dérive de réplication et la saturation des threads de connexions avant qu'elles ne ralentissent chaque lecture de votre application ou ne provoquent en cascade une tempête de failover de réplica. Pour WordPress, Laravel, Magento et toute charge appuyée sur RDS/Aurora, la visibilité par base est le signal le plus utile entre la lenteur rapportée par l'utilisateur et la cause racine. Xitoring détecte automatiquement votre MySQL, interroge performance_schema et les vues de statut standard, et achemine les alertes vers Slack, PagerDuty, Telegram ou votre rotation d'astreinte existante.
Ce que nous surveillons
Requêtes par seconde
Taux de requêtes SELECT, INSERT, UPDATE et DELETE.
Connexions actives
Nombre de connexions actuellement actives à MySQL.
Requêtes lentes
Nombre de requêtes dépassant le seuil de slow query.
Lag de réplication
Secondes de retard par rapport au master en réplication.
Buffer pool InnoDB
Utilisation du buffer pool et ratio de hit.
États des threads
Distribution des états de threads (running, sleeping, locked).
Verrous de tables
Taux d'attentes de verrous de tables et acquisitions immédiates.
Tables temporaires
Taux de tables temporaires créées sur disque.
Octets envoyés/reçus
Débit réseau vers et depuis MySQL.
Connexions abandonnées
Tentatives de connexion échouées et clients abandonnés.
Open_tables vs table_open_cache
Handles de tables actuellement ouverts vs taille de cache configurée. Lorsque Open_tables approche la limite du cache, MySQL évince et rouvre — un coût de latence mesurable.
Innodb_os_log_pending_fsyncs
Fsyncs en attente vers le redo log InnoDB. Des valeurs non nulles soutenues signifient que vos réglages `sync_binlog`/`innodb_flush_log_at_trx_commit` sont en goulot d'étranglement sur le disque.
Configurables déclencheurs d'alerte
Configurez des déclencheurs personnalisés dans votre tableau de bord pour être averti dès que les indicateurs d{name}s dépassent les seuils que vous avez définis.
Connexions actives
crucialSe déclenche lorsque les connexions actives approchent max_connections, risquant le refus de nouvelles connexions et des erreurs applicatives.
Lag de réplication
crucialSe déclenche lorsque la réplication prend du retard, risquant l'incohérence des données entre master et replicas.
Requêtes lentes
avertissementAlerte lorsque le nombre de requêtes lentes dépasse le seuil, indiquant une dégradation des performances.
Buffer pool InnoDB
avertissementSe déclenche lorsque le ratio de hit du buffer pool chute, indiquant une I/O disque excessive.
Connexions abandonnées
avertissementSe déclenche sur des pics d'échecs de connexion, indiquant des problèmes d'authentification ou de réseau.
Attentes de verrous de tables
crucialAlerte lorsque la contention de verrous augmente, dégradant les performances de requêtes.
Importance de la surveillance MySQL
MySQL gère des données critiques pour des millions d'applications. Sans surveillance appropriée, les requêtes lentes, la dérive de réplication et l'épuisement des connexions peuvent entraîner des pannes et une incohérence des données.
- Détectez les requêtes lentes avant qu'elles n'impactent l'expérience utilisateur
- Évitez l'épuisement du pool de connexions avec des alertes de seuil
- Surveillez la réplication pour la cohérence des données entre replicas
- Suivez les performances InnoDB pour une santé optimale du moteur de stockage
- Identifiez tôt la contention de verrous et les goulets d'étranglement de requêtes
Pourquoi choisir Xitoring
Xitoring offre une surveillance MySQL de qualité entreprise avec une configuration zéro-config. Notre agent léger détecte automatiquement vos instances MySQL, commence à collecter des métriques en moins de 60 secondes et s'intègre à vos canaux de notification existants.
- Installation en une commande — pas de YAML complexe ni de fichiers de configuration
- 15+ nœuds de surveillance mondiaux pour des contrôles à faible latence
- Tableau de bord unifié pour serveurs, bases de données et uptime
- Alerting flexible via Slack, PagerDuty, Telegram et plus
- Conservation de l'historique pour la planification de capacité et les audits
Scénarios courants de supervision MySQL
Où MySQL fonctionne généralement aujourd'hui — et ce qui pourrait mal tourner si personne ne surveille.
Base de données cloud gérée (AWS, Azure, Google)
Les fournisseurs de cloud gèrent les serveurs, mais ils ne vous disent pas quand vos propres requêtes sont lentes, vos connexions s'épuisent, ou qu'une copie de sauvegarde prend discrètement du retard. Nous détectons les problèmes que le fournisseur vous laisse, afin qu'un ralentissement ne prenne pas l'équipe au dépourvu.
Base de données principale avec copies de sauvegarde en direct
Les bases de données de production exécutent généralement une sauvegarde en direct prête à prendre le relais si la principale tombe en panne. Lorsque cette sauvegarde prend discrètement du retard, ce qui devrait être un transfert en douceur devient une véritable panne — parfois avec perte de données. Nous surveillons chaque copie afin que la sauvegarde soit vraiment prête lorsque vous en avez besoin.
Base de données fonctionnant dans Kubernetes
Les bases de données dans Kubernetes sont déplacées, redémarrées et mises à jour automatiquement par la plateforme. La plupart du temps, c'est sûr — quand ce n'est pas le cas, vous le découvrez généralement par des utilisateurs frustrés. Nous mettons en évidence les signes avant-coureurs afin que l'équipe puisse intervenir avant qu'une mise à jour de routine ne devienne un incident.
Prérequis pour MySQL
Assurez-vous d'avoir tout cela en place — la plupart des installations sont une affaire de 60 secondes une fois ces conditions réunies.
- MySQL 5.7 ou 8.x tournant sur le serveur
- performance_schema = ON (par défaut à partir de 5.7+, à définir dans [mysqld] si désactivé)
- Un utilisateur de monitoring avec PROCESS, REPLICATION CLIENT, et SELECT sur performance_schema
Commencez par procès-verbal
Installer Xitogent sur votre serveur
Si ce n'est pas déjà fait, installez l'agent de monitoring léger Xitogent sur votre serveur.
curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEYCréer un utilisateur de monitoring dans MySQL
Créez un utilisateur en lecture seule dédié pour que Xitogent collecte les métriques :
CREATE USER 'xitoring'@'%' IDENTIFIED BY 'your_secure_password';
GRANT REPLICATION CLIENT ON *.* TO 'xitoring'@'%' WITH MAX_USER_CONNECTIONS 5;
GRANT PROCESS ON *.* TO 'xitoring'@'%';
GRANT SELECT ON performance_schema.* TO 'xitoring'@'%';
FLUSH PRIVILEGES;Activer l'intégration MySQL
Utilisez le tableau de bord Xitoring ou la CLI pour activer l'intégration MySQL avec les identifiants de monitoring.
sudo xitogent integrateConfigurer les seuils d'alerte (facultatif)
Définissez des seuils personnalisés pour des métriques comme le retard de réplication, les requêtes lentes ou le nombre de connexions afin d'être notifié dès que quelque chose mérite votre attention.
Vérifier que tout fonctionne
Exécutez cette commande sur le serveur pour confirmer que Xitogent a bien détecté l'intégration. De nouvelles métriques apparaîtront sur votre tableau de bord dans environ 30 secondes.
sudo xitogent statusVous envisagez des alternatives ?
Découvrez comment Xitoring se positionne face aux alternatives pour la surveillance de MySQL — tarifs forfaitaires, intégrations plus poussées et un seul agent pour couvrir tout votre stack.
Souvent a posé des questions
De quelles autorisations l'utilisateur chargé de la surveillance a-t-il besoin ?
Cette intégration aura-t-elle un impact sur les performances de MySQL ?
Puis-je surveiller la réplication MySQL ?
Cela fonctionne-t-il avec MySQL sur RDS ou avec des bases de données dans le cloud ?
Quelles versions de MySQL sont prises en charge ?
À quelle fréquence les indicateurs sont-ils collectés ?
Quelle est la différence entre la supervision MySQL et MariaDB ?
Cette intégration affectera-t-elle les performances de MySQL ?
Quelles versions de MySQL sont prises en charge ?
Commencer à surveiller MySQL aujourd'hui
Configuration en moins de 60 secondes. Aucune carte bancaire requise. Statistiques complètes dès le premier jour.
Commencer l'essai gratuitContinuez à explorer
