ClusterControl 1.7.0 introduit une nouvelle fonctionnalité audacieuse - l'intégration avec Prometheus pour la surveillance basée sur les agents. Nous avons appelé cela SCUMM (Severalnines ClusterControl Unified Management and Monitoring). Dans les versions précédentes, les tâches de surveillance étaient uniquement effectuées sans agent. Si vous vous demandez comment ClusterControl exécute ses fonctions de surveillance, consultez cette page de documentation.
ProxySQL, un proxy inverse hautes performances qui comprend les protocoles MySQL, se trouve généralement au-dessus de MySQL Replication et Galera Cluster pour agir comme une passerelle vers le service backend MySQL. Il peut être configuré comme un routeur de requêtes, un pare-feu de requêtes, une mise en cache des requêtes, un répartiteur de trafic et bien d'autres. ProxySQL collecte et expose également des métriques clés via son schéma STATS qui est très utile pour analyser les performances et comprendre ce qui se passe réellement dans les coulisses. Consultez notre didacticiel complet sur ProxySQL pour en savoir plus.
Dans cet article de blog, nous allons examiner la surveillance en profondeur des instances ProxySQL avec cette nouvelle approche. Dans cet exemple, nous avons une instance ProxySQL au-dessus de notre réplication MySQL à deux nœuds (1 maître, 1 esclave), déployée via ClusterControl. Notre architecture de haut niveau ressemble à ceci :
Nous avons également les règles de requête suivantes définies dans l'instance ProxySQL (juste pour référence, pour donner un sens aux métriques de surveillance collectées plus bas) :
Activer Prometheus
La surveillance basée sur l'agent de ClusterControl est activée par cluster. ClusterControl peut déployer un nouveau serveur Prometheus pour vous ou utiliser un serveur Prometheus existant (déployé par ClusterControl pour un autre cluster). Activer Prometheus est assez simple. Allez simplement dans ClusterControl -> choisissez le cluster -> Tableaux de bord -> Activer la surveillance basée sur l'agent :
Ensuite, spécifiez l'adresse IP ou le nom d'hôte du nouveau serveur Prometheus, ou choisissez simplement un hôte Prometheus existant dans la liste déroulante :
ClusterControl installera et configurera les packages nécessaires (Prometheus sur le serveur Prometheus, les exportateurs sur la base de données et les nœuds ProxySQL), se connectera au Prometheus en tant que source de données et commencera à visualiser les données de surveillance dans l'interface utilisateur.
Une fois la tâche de déploiement terminée, vous devriez pouvoir accéder à l'onglet Tableaux de bord, comme indiqué dans la section suivante.
Tableau de bord ProxySQL
Vous pouvez accéder aux tableaux de bord ProxySQL en accédant au cluster respectif sous l'onglet Tableaux de bord. En cliquant sur la liste déroulante Tableau de bord, vous listerez les tableaux de bord liés à notre cluster (MySQL Replication). Vous pouvez trouver le tableau de bord ProxySQL Overview dans la section "Load Balancers" :
Il existe un certain nombre de panneaux pour ProxySQL, certains d'entre eux sont explicites. Néanmoins, visitons-les un par un.
Taille du groupe d'hôtes
La taille du groupe d'hôtes est simplement le nombre total d'hôtes sur tous les groupes d'hôtes :
Dans ce cas, nous avons deux groupes d'hôtes - 10 (écrivain) et 20 (lecteur). Le groupe d'hôtes 10 se compose d'un hôte (maître) tandis que le groupe d'hôtes 20 a deux hôtes (maître et esclave), ce qui représente un total de trois hôtes.
À moins que vous ne modifiiez la configuration du groupe d'hôtes (introduction d'un nouvel hôte, suppression d'un hôte existant) à partir de ProxySQL, vous devez vous attendre à ce que rien ne change dans ce graphique.
Connexions clients
Le nombre de connexions client en cours de traitement par ProxySQL pour tous les groupes d'hôtes :
Le graphique ci-dessus nous indique simplement qu'il y a constamment 8 clients MySQL connectés à notre instance ProxySQL sur le port 6033 au cours des 45 dernières minutes (vous pouvez modifier cela sous l'option "Sélection de plage"). Si vous arrêtez de connecter votre application à ProxySQL (ou si vous le contournez), la valeur devrait finalement tomber à 0.
Questions des clients
Le graphique visualise le nombre de questions traitées par ProxySQL pour tous les groupes d'hôtes :
Selon la documentation MySQL, les questions sont simplement le nombre d'instructions exécutées par le serveur. Cela inclut uniquement les instructions envoyées au serveur par les clients et non les instructions exécutées dans les programmes stockés, contrairement à la variable Requêtes. Cette variable ne compte pas les commandes COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE ou COM_STMT_RESET. Encore une fois, si vous arrêtez de connecter votre application à ProxySQL (ou si vous le contournez), la valeur devrait tomber à 0.
Connexions backend actives
Le nombre de connexions que ProxySQL maintient avec les serveurs backend MySQL par hôte :
Il nous indique simplement combien de connexions sont actuellement utilisées par ProxySQL pour envoyer des requêtes au serveur principal. Tant que la valeur maximale n'est pas proche de la limite de connexion pour le serveur particulier (définie via max_connections lorsque le serveur est ajouté au groupe d'hôtes ProxySQL), nous sommes en bonne forme.
Échec des connexions backend
Le nombre de connexions qui n'ont pas été établies avec succès par ProxySQL :
L'exemple ci-dessus montre simplement qu'aucun échec de connexion au backend ne s'est produit au cours des 45 dernières minutes.
Requêtes routées
Ce graphique donne un aperçu de la distribution des déclarations entrantes vers les serveurs principaux :
Comme vous pouvez le voir, la plupart des lectures vont au groupe hôte du lecteur (HG20). À partir de là, nous pouvons comprendre le modèle d'équilibrage effectué par ProxySQL qui correspond à nos règles de requête dans cette charge de travail intensive en lecture.
Connexion gratuite
Le graphique montre combien de connexions sont actuellement libres :
Les connexions sont maintenues ouvertes afin de minimiser le temps nécessaire à l'envoi d'une requête au serveur principal.
Latence
Le temps de ping actuel en microsecondes, tel qu'indiqué par le fil de surveillance ProxySQL :
Cela nous indique simplement la stabilité de la connexion entre ProxySQL et les serveurs backend MySQL. Une valeur élevée pendant une longue période cohérente indique principalement un problème de réseau entre eux.
Interroger la mémoire cache
Ce graphique visualise la consommation de mémoire des requêtes mises en cache par ProxySQL :
D'après le graphique ci-dessus, nous pouvons dire que ProxySQL consomme une quantité totale de 8 Mo de mémoire par le cache de requêtes. Après avoir atteint la limite de 8 Mo (configurable via mysql-query_cache_size_MB variable), la mémoire sera purgée par le thread de purge de ProxySQL. Ce graphique ne sera pas rempli si aucune règle de cache de requête n'est définie.
Au fait, la mise en cache d'une requête dans ProxySQL peut se faire en seulement deux clics avec ClusterControl. Accédez à la page des principales requêtes de ProxySQL, survolez une requête, cliquez sur Query Cache et cliquez sur "Add Rule":
Efficacité du cache des requêtes
Ce graphique visualise l'efficacité des requêtes mises en cache :
La ligne bleue nous indique le taux de réussite des requêtes GET exécutées par rapport au cache de requêtes où le jeu de résultats était présent et n'a pas expiré. La ligne rose indique le ratio de données écrites (insérées) dans ou lues à partir du cache de requêtes. Dans ce cas, nos données lues à partir de Query Cache sont supérieures aux données écrites indiquant une configuration de cache efficace.
Ce graphique ne sera pas rempli si aucune règle de cache de requête n'est définie.
Trafic réseau
Ce graphique visualise le trafic réseau (données reçues + données envoyées) depuis/vers les serveurs backend MySQL, par hôte :
La capture d'écran ci-dessus nous indique qu'une quantité importante de trafic est transmise/reçue depuis/vers le groupe d'hôtes du lecteur (HG20). Dans cette charge de travail intensive en lecture, les opérations de lecture consomment généralement un trafic beaucoup plus élevé, principalement en raison de la taille de l'ensemble de résultats des instructions SELECT.
Seul un plus petit pourcentage du trafic est transféré/reçu depuis/vers le groupe d'hôtes d'écriture (HG10), ce qui est attendu puisque les opérations d'écriture consomment généralement moins de trafic réseau avec un ensemble de résultats considérablement réduit renvoyé aux clients.
Efficacité de la mise en miroir
Le graphique montre simplement le statut lié à la mise en miroir du trafic, comme Mirror_concurrency vs Mirror_queue_length :
Le graphique n'est rempli que si vous avez configuré la mise en miroir du trafic (mirror_hostgroup à l'intérieur de la règle de requête). Si la file d'attente miroir reprend, la réduction de la limite de simultanéité de la mise en miroir augmentera l'efficacité de la mise en miroir, qui peut être contrôlée via mysql-mirror_max_concurrency variable. En termes simples, l'absence d'entrées dans la file d'attente est ce qu'est la mise en miroir la plus efficace.
Utilisation de la mémoire
Le graphique illustre l'utilisation de la mémoire par les principaux composants de ProxySQL - pool de connexions, cache de requêtes et stockage persistant (SQLite) :
La capture d'écran ci-dessus nous indique que l'empreinte mémoire de ProxySQL est plutôt petite, soit moins de 12 Mo au total. Le pool de connexions ne consomme que 1,3 Mo pour s'adapter à notre charge de travail à 8 threads (clients). Avec plus de RAM libre disponible sur l'hôte, nous devrions être en mesure d'augmenter de trois à quatre le nombre de connexions client à ProxySQL ou de mettre en cache beaucoup plus de requêtes à chaud dans ProxySQL pour décharger nos serveurs backend MySQL.
Fonctionnalité bonus - Performances des nœuds
ClusterControl 1.7.0 inclut désormais des mesures de performances de l'hôte pour les instances ProxySQL. Dans la version précédente, ClusterControl surveillait uniquement les métriques liées à ProxySQL telles qu'exposées par le schéma de statistiques ProxySQL. Cette nouvelle fonctionnalité est accessible sous l'onglet Node -> Instance ProxySQL -> Node Performance :
Les histogrammes fournissent un aperçu des métriques clés de l'hôte, similaires à ce qui est échantillonné pour les nœuds de base de données sous la section Nœuds -> Présentation. Si votre instance ProxySQL est colocalisée sur le même serveur avec l'application, vous utilisez littéralement ClusterControl pour surveiller également le serveur d'application. C'est cool ? !
Réflexions finales
L'intégration de ClusterControl avec Prometheus offre une autre façon de surveiller et d'analyser votre pile de base de données, jusqu'au niveau de proxy inverse. Vous avez maintenant le choix de décharger les tâches de surveillance sur Prometheus ou de continuer à utiliser l'approche de surveillance sans agent ClusterControl par défaut pour votre infrastructure de base de données.
