Nous avons ajouté un certain nombre de nouveaux tableaux de bord pour MySQL dans notre dernière version de ClusterControl 1.7.0. - et dans notre blog précédent, nous vous avons montré comment surveiller votre ProxySQL avec Prometheus et ClusterControl.
Dans ce blog, nous examinerons le tableau de bord MySQL Overview.
Nous avons donc activé la surveillance basée sur l'agent sous l'onglet Tableau de bord pour commencer à collecter des métriques sur les nœuds. Notez que lors de l'activation de la surveillance basée sur l'agent, vous avez la possibilité de définir l'"intervalle de grattage (secondes) ” et “Conservation des données (jours) ”. L'intervalle de grattage est l'endroit où vous souhaitez définir l'agressivité avec laquelle Prometheus récoltera les données de la cible et la conservation des données correspond à la durée pendant laquelle vous souhaitez conserver vos données collectées par Prometheus avant qu'elles ne soient supprimées.
Lorsqu'il est activé, vous pouvez identifier quel cluster a des agents et lequel a une surveillance sans agent.
Par rapport à l'approche sans agent, la granularité de vos données dans les graphiques sera plus élevée avec les agents.
Les graphiques MySQL
La dernière version de ClusterControl 1.7.0 (que vous pouvez télécharger gratuitement - ClusterControl Community) dispose des tableaux de bord MySQL suivants pour lesquels vous pouvez collecter des informations pour vos serveurs MySQL. Il s'agit de la présentation de MySQL, des métriques MySQL InnoDB, du schéma de performances MySQL et de la réplication MySQL.
Nous couvrirons en détail les graphiques disponibles dans le tableau de bord MySQL Overview.
Tableau de bord de présentation de MySQL
Ce tableau de bord contient les variables ou informations importantes habituelles concernant la santé de votre nœud MySQL. Les graphiques contenus dans ce tableau de bord sont spécifiques au nœud sélectionné lors de la visualisation des tableaux de bord comme indiqué ci-dessous :
Il se compose de 26 graphiques, mais vous n'aurez peut-être pas besoin de tous pour diagnostiquer des problèmes. Cependant, ces graphiques fournissent une représentation essentielle des métriques globales de vos serveurs MySQL. Passons en revue les éléments de base, car ce sont probablement les éléments les plus courants qu'un administrateur de base de données examinera régulièrement.
Les quatre premiers graphiques présentés ci-dessus ainsi que la disponibilité de MySQL, les requêtes par seconde et les informations sur le pool de mémoire tampon sont les pointeurs les plus élémentaires dont nous pourrions avoir besoin. A partir des graphiques affichés ci-dessus, voici leurs représentations :
- Connexions MySQL
C'est ici que vous souhaitez vérifier le nombre total de connexions client allouées jusqu'à présent sur une période de temps spécifique. - Activité du thread client MySQL
Il peut arriver que votre serveur MySQL soit très occupé. Par exemple, on peut s'attendre à recevoir une augmentation du trafic à un moment précis et vous souhaitez surveiller l'activité de vos threads en cours d'exécution. Ce graphique est vraiment important à regarder. Il peut arriver que les performances de votre requête diminuent si, par exemple, une mise à jour importante oblige d'autres threads à attendre pour acquérir le verrou. Cela conduirait à une augmentation du nombre de vos threads en cours d'exécution. Le taux d'échec du cache est calculé comme Threads_created/Connections. - Questions MySQL
Il s'agit des requêtes exécutées dans une période de temps spécifique. Un thread peut être une transaction composée de plusieurs requêtes et cela peut être un bon graphique à regarder. - Cache de threads MySQL
Ce graphique affiche la valeur thread_cache_size, les threads mis en cache (threads réutilisés) et les threads créés (nouveaux threads). Vous pouvez vérifier sur ce graphique des cas tels que vous devez régler vos requêtes de lecture lorsque vous remarquez un nombre élevé de connexions entrantes et que vos threads créés augmentent rapidement. Par exemple, si votre Threads_running / thread_cache_size> 2, l'augmentation de votre thread_cache_size peut améliorer les performances de votre serveur. Notez que la création et la destruction de threads coûtent cher. Cependant, dans les versions récentes de MySQL (>=5.6.8), cette variable a un dimensionnement automatique par défaut que vous pourriez considérer comme intact.
Les quatre graphiques suivants sont les objets temporaires MySQL, les types de sélection MySQL, les tris MySQL et les requêtes lentes MySQL. Ces graphiques sont liés les uns aux autres, en particulier si vous diagnostiquez des requêtes longues et des requêtes volumineuses nécessitant une optimisation.
- Objets temporaires MySQL
Ce graphique serait une bonne source sur laquelle s'appuyer si vous souhaitez surveiller les requêtes de longue durée qui finiraient par utiliser le disque au lieu de tables ou de fichiers temporaires en mémoire. C'est un bon endroit pour commencer à rechercher l'occurrence périodique de requêtes qui pourraient s'additionner pour créer des problèmes d'espace disque, en particulier pendant les périodes irrégulières. - Types de sélection MySQL
Les requêtes qui utilisent des jointures complètes, des analyses de table, des plages de sélection qui n'utilisent aucun index sont une source de mauvaises performances. Ce graphique montre les performances de votre requête et ce qui, parmi la liste, des jointures complètes aux jointures complètes, sélection de plage, analyses de table, a les tendances les plus élevées. - Tris MySQL
Diagnostiquer les requêtes qui utilisent le tri et celles qui prennent beaucoup de temps à terminer. - Requêtes lentes MySQL
Les tendances de vos requêtes lentes sont collectées ici sur ce graphique. Ceci est très utile, en particulier pour diagnostiquer la fréquence à laquelle vos requêtes sont lentes. Quelles sont les choses qui doivent être réglées ? Il peut s'agir d'un pool de mémoire tampon trop petit, de tables manquant d'index et effectuant une analyse complète de la table, de sauvegardes logiques exécutées selon un calendrier inattendu, etc. L'utilisation de notre moniteur de requêtes dans ClusterControl avec ce graphique est bénéfique, car il aide à déterminer les requêtes lentes.
Les prochains graphiques que nous avons couvrent concernent davantage l'activité du réseau, les verrous de table et la mémoire interne sous-jacente que MySQL consomme pendant l'activité de MySQL.
- Connexions MySQL abandonnées
Le nombre de connexions abandonnées s'affichera sur ce graphique. Cela couvre les clients abandonnés, par exemple lorsque le réseau a été fermé brusquement ou lorsque la connexion Internet était en panne ou interrompue. Il enregistre également les connexions ou les tentatives abandonnées telles que les mots de passe erronés ou les mauvais paquets lors de l'établissement d'une connexion à partir du client. - Verrous de table MySQL
Tendances pour les tables qui demandent un verrou de table qui a été accordé immédiatement et pour les tables qui demandent un verrou qui n'a pas été acquis immédiatement. Par exemple, si vous avez des verrous au niveau de la table sur les tables MyISAM et les demandes entrantes de la même table, celles-ci ne peuvent pas être accordées immédiatement. - Trafic réseau MySQL
Ce graphique montre les tendances de l'activité réseau entrante et sortante dans le serveur MySQL. "Inbound" est les données reçues par le serveur MySQL tandis que "Outbound" est les données envoyées ou transférées par le serveur depuis le serveur MySQL. Ce graphique est préférable de vérifier si vous souhaitez surveiller votre trafic réseau, en particulier lors du diagnostic de votre trafic. est modéré mais vous vous demandez pourquoi il a un très grand nombre de données transférées sortantes, comme par exemple les données BLOB. - Utilisation horaire du réseau MySQL
Identique au trafic réseau qui affiche les données reçues et envoyées. Notez qu'il est basé sur "par heure" et étiqueté avec "dernier jour" qui ne suivra pas la période que vous avez sélectionnée dans le sélecteur de date. - Présentation de la mémoire interne MySQL
Ce graphique est familier pour un DBA MySQL chevronné. Chacune de ces légendes dans le graphique à barres est très importante, en particulier si vous souhaitez surveiller votre utilisation de la mémoire, l'utilisation de votre pool de mémoire tampon ou la taille de votre index de hachage adaptatif.
Les graphiques suivants montrent les compteurs sur lesquels un DBA peut s'appuyer, tels que la vérification des statistiques, par exemple, les statistiques pour les sélections, les insertions, les mises à jour, le nombre d'états maîtres qui ont été exécutés, le nombre de SHOW VARIABLES qui ont été exécutés, la vérification si vous avez de mauvaises requêtes en effectuant des analyses de table ou des tables n'utilisant pas d'index en examinant les compteurs read_*, etc.
- Meilleurs compteurs de commandes (par heure)
Ce sont les graphiques que vous auriez probablement à vérifier chaque fois que vous voudriez voir les statistiques de vos insertions, suppressions, mises à jour, commandes exécutées telles que la collecte de la liste des processus, le statut de l'esclave, le statut d'affichage (statistiques de santé du serveur MySQL ), et beaucoup plus. C'est un bon endroit si vous voulez vérifier quel type de compteurs de commandes MySQL sont les plus élevés et si un réglage des performances ou une optimisation des requêtes est nécessaire. Cela peut également vous permettre d'identifier les commandes qui s'exécutent de manière agressive sans en avoir besoin. - Gestionnaires MySQL
Souvent, un administrateur de base de données passe en revue ces gestionnaires et vérifie les performances des requêtes sur votre serveur MySQL. Fondamentalement, ce graphique couvre les compteurs de l'API Handler de MySQL. Les compteurs de gestionnaire les plus courants pour un DBA pour l'API de stockage dans MySQL sont Handler_read_first, Handler_read_key, Handler_read_last, Handler_read_next, Handler_read_prev, Handler_read_rnd et Handler_read_rnd_next. Il existe de nombreux gestionnaires MySQL à vérifier. Vous pouvez lire à leur sujet dans la documentation ici. - Gestionnaires de transactions MySQL
Si votre serveur MySQL utilise des transactions XA, des instructions SAVEPOINT, ROLLBACK TO SAVEPOINT. Alors ce graphique est une bonne référence à regarder. Vous pouvez également utiliser ce graphique pour surveiller tous les commits internes de votre serveur. Notez que le compteur pour Handler_commit s'incrémente même pour les instructions SELECT, mais diffère des instructions d'insertion/mise à jour/suppression qui vont dans le journal binaire lors d'un appel à l'instruction COMMIT.
Le graphique suivant montrera les tendances concernant les états de processus et leur utilisation horaire. Il y a beaucoup de points clés ici dans la légende du graphique à barres qu'un administrateur de base de données vérifierait. Rencontrer des problèmes d'espace disque, des problèmes de connexion et voir si votre pool de connexions fonctionne comme prévu, des E/S disque élevées, des problèmes de réseau, etc.
- États de processus/États de processus principaux par heure
Ce graphique vous permet de surveiller les états des principaux threads de vos requêtes exécutées dans la liste des processus. Ceci est très instructif et utile pour de telles tâches DBA où vous pouvez examiner ici tous les statuts en attente qui doivent être résolus. Par exemple, ouvrir des tables l'état est très élevé et sa valeur minimale est presque proche de la valeur maximale. Cela pourrait indiquer que vous devez ajuster le table_open_cache. Si les statistiques est élevé et que vous remarquez un ralentissement de votre serveur, cela peut indiquer que votre serveur est lié au disque et que vous devrez peut-être envisager d'augmenter votre pool de mémoire tampon. Si vous avez un grand nombre de création de table tmp alors vous devrez peut-être vérifier votre journal lent et optimiser les requêtes incriminées. Vous pouvez consulter le manuel pour la liste complète des états de thread MySQL ici.
Le prochain graphique que nous allons vérifier concerne le cache de requêtes, le cache de définition de table MySQL, la fréquence à laquelle MySQL ouvre les fichiers système.
- Mémoire/activité du cache de requêtes MySQL
Ces graphiques sont liés les uns aux autres. Si vous avez query_cache_size <> 0 et query_cache_type <> 0, alors ce graphique peut être utile. Cependant, dans les nouvelles versions de MySQL, le cache de requêtes a été marqué comme obsolète car le cache de requêtes MySQL est connu pour causer des problèmes de performances. Vous n'en aurez peut-être plus besoin à l'avenir. La version la plus récente de MySQL 8.0 a des améliorations drastiques; il a tendance à augmenter les performances car il est livré avec plusieurs stratégies pour gérer les informations de cache dans les tampons de mémoire. - Ouvertures de fichiers MySQL
Ce graphique montre la tendance des fichiers ouverts depuis la disponibilité du serveur MySQL, mais il exclut les fichiers tels que les sockets ou les pipes. Il n'inclut pas non plus les fichiers ouverts par le moteur de stockage car ils ont leur propre compteur qui est Innodb_num_open_files. - Ouvrir des fichiers MySQL
Ce graphique est l'endroit où vous souhaitez vérifier vos fichiers InnoDB actuellement ouverts, les fichiers ouverts MySQL actuels et votre variable open_files_limit. - État du cache ouvert de la table MySQL
Si vous avez défini ici un table_open_cache très faible, ce graphique vous indiquera les tables qui échouent dans le cache (tables nouvellement ouvertes) ou manquent en raison d'un débordement. Si vous rencontrez un nombre élevé ou trop de statuts "Ouvrir des tables" dans votre liste de processus, ce graphique vous servira de référence pour le déterminer. Cela vous indiquera s'il est nécessaire d'augmenter votre variable table_open_cache. - Tables ouvertes MySQL
Par rapport à l'état du cache ouvert de la table MySQL, ce graphique est utile dans certaines occasions, comme si vous souhaitez identifier s'il est nécessaire d'augmenter votre table_open_cache ou de le réduire si vous remarquez une forte augmentation des tables ouvertes ou de la variable d'état Open_tables . Notez que table_open_cache peut prendre une grande quantité d'espace mémoire, vous devez donc le définir avec soin, en particulier dans les systèmes de production. - Cache de définition de table MySQL
Si vous souhaitez vérifier le nombre de vos variables d'état Open_table_definitions et Opened_table_definitions, alors ce graphique est ce dont vous avez besoin. Pour les versions plus récentes de MySQL (>=5.6.8), vous n'aurez peut-être pas besoin de modifier la valeur de cette variable et d'utiliser la valeur par défaut car elle dispose d'une fonction de redimensionnement automatique.
Conclusion
L'ajout de SCUMM dans la dernière version de ClusterControl 1.7.0 offre de nouveaux avantages significatifs pour un certain nombre de tâches DBA clés. Les nouveaux graphiques peuvent aider à identifier facilement la cause des problèmes auxquels les administrateurs de base de données ou les administrateurs système doivent généralement faire face et à trouver plus rapidement les solutions appropriées.
Nous aimerions connaître votre expérience et vos réflexions sur l'utilisation de ClusterControl 1.7.0 avec SCUMM (que vous pouvez télécharger gratuitement - ClusterControl Community).
Dans la partie 2 de ce blog, je discuterai de la surveillance efficace de la réplication MySQL avec les tableaux de bord SCUMM.
