ClusterControl 1.7.0 führt eine mutige neue Funktion ein – die Integration mit Prometheus für agentenbasierte Überwachung. Wir nannten dies SCUMM (Severalnines ClusterControl Unified Management and Monitoring). In den Vorgängerversionen wurden die Überwachungsaufgaben ausschließlich agentenlos durchgeführt. Wenn Sie sich fragen, wie ClusterControl seine Überwachungsfunktionen ausführt, sehen Sie sich diese Dokumentationsseite an.
ProxySQL, ein Hochleistungs-Reverse-Proxy, der MySQL-Protokolle versteht, sitzt üblicherweise auf MySQL Replication und Galera Cluster, um als Gateway zum Backend-MySQL-Dienst zu fungieren. Es kann als Abfrage-Router, Abfrage-Firewall, Abfrage-Caching, Traffic-Dispatcher und vieles mehr konfiguriert werden. ProxySQL sammelt und zeigt auch wichtige Metriken über sein STATS-Schema, was sehr nützlich ist, um die Leistung zu analysieren und zu verstehen, was tatsächlich hinter den Kulissen passiert. Besuchen Sie unser umfassendes Tutorial für ProxySQL, um mehr darüber zu erfahren.
In diesem Blog-Beitrag werden wir uns eingehend mit der Überwachung der ProxySQL-Instanzen mit diesem neuen Ansatz befassen. In diesem Beispiel haben wir eine ProxySQL-Instanz auf unserer Zwei-Knoten-MySQL-Replikation (1 Master, 1 Slave), bereitgestellt über ClusterControl. Unsere High-Level-Architektur sieht etwa so aus:
Wir haben auch die folgenden Abfrageregeln in der ProxySQL-Instanz definiert (nur als Referenz, um die gesammelten Überwachungsmetriken weiter unten zu verstehen):
Prometheus aktivieren
Die agentenbasierte Überwachung von ClusterControl wird pro Cluster aktiviert. ClusterControl kann einen neuen Prometheus-Server für Sie bereitstellen oder einen vorhandenen Prometheus-Server verwenden (von ClusterControl für andere Cluster bereitgestellt). Die Aktivierung von Prometheus ist ziemlich einfach. Gehen Sie einfach zu ClusterControl -> wählen Sie den Cluster -> Dashboards -> Agentenbasierte Überwachung aktivieren:
Geben Sie dann die IP-Adresse oder den Hostnamen des neuen Prometheus-Servers an oder wählen Sie einfach einen vorhandenen Prometheus-Host aus der Dropdown-Liste aus:
ClusterControl installiert und konfiguriert die erforderlichen Pakete (Prometheus auf dem Prometheus-Server, Exporter auf der Datenbank und ProxySQL-Knoten), verbindet sich mit Prometheus als Datenquelle und beginnt mit der Visualisierung der Überwachungsdaten in der Benutzeroberfläche.
Sobald der Bereitstellungsjob abgeschlossen ist, sollten Sie auf die Registerkarte „Dashboards“ zugreifen können, wie im nächsten Abschnitt gezeigt.
ProxySQL-Dashboard
Sie können auf die ProxySQL-Dashboards zugreifen, indem Sie auf der Registerkarte „Dashboards“ zum jeweiligen Cluster gehen. Wenn Sie auf das Dropdown-Menü Dashboard klicken, werden Dashboards aufgelistet, die sich auf unseren Cluster beziehen (MySQL-Replikation). Sie finden das ProxySQL-Übersichts-Dashboard im Abschnitt „Load Balancer“:
Es gibt eine Reihe von Panels für ProxySQL, von denen einige selbsterklärend sind. Besuchen wir sie trotzdem nacheinander.
Größe der Hostgruppe
Die Hostgruppengröße ist einfach die Gesamtzahl der Hosts in allen Hostgruppen:
In diesem Fall haben wir zwei Hostgruppen – 10 (Schreiber) und 20 (Leser). Hostgruppe 10 besteht aus einem Host (Master), während Hostgruppe 20 aus zwei Hosts (Master und Slave) besteht, was insgesamt drei Hosts ergibt.
Sofern Sie die Konfiguration der Hostgruppe nicht von ProxySQL aus ändern (neuen Host einführen, vorhandenen Host entfernen), sollten Sie damit rechnen, dass sich in diesem Diagramm nichts ändert.
Client-Verbindungen
Die Anzahl der Client-Verbindungen, die von ProxySQL für alle Hostgruppen verarbeitet werden:
Das obige Diagramm sagt uns einfach, dass in den letzten 45 Minuten durchgehend 8 MySQL-Clients mit unserer ProxySQL-Instanz auf Port 6033 verbunden waren (Sie können dies unter der Option „Bereichsauswahl“ ändern). Wenn Sie Ihre Anwendung nicht mehr mit ProxySQL verbinden (oder umgehen), sollte der Wert schließlich auf 0 fallen.
Kundenfragen
Das Diagramm visualisiert die Anzahl der Fragen, die von ProxySQL für alle Hostgruppen verarbeitet werden:
Laut MySQL-Dokumentation sind Fragen einfach die Anzahl der Anweisungen, die vom Server ausgeführt werden. Dies umfasst nur Anweisungen, die von Clients an den Server gesendet werden, und keine Anweisungen, die in gespeicherten Programmen ausgeführt werden, im Gegensatz zur Abfragevariablen. Diese Variable zählt nicht die Befehle COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE oder COM_STMT_RESET. Auch hier gilt:Wenn Sie Ihre Anwendung nicht mehr mit ProxySQL verbinden (oder umgehen), sollte der Wert auf 0 fallen.
Aktive Backend-Verbindungen
Die Anzahl der Verbindungen, die ProxySQL zu den Back-End-MySQL-Servern pro Host aufrechterhält:
Es sagt uns einfach, wie viele Verbindungen derzeit von ProxySQL verwendet werden, um Anfragen an den Backend-Server zu senden. Solange der Max-Wert nicht in der Nähe des Verbindungslimits für den jeweiligen Server liegt (eingestellt über max_connections wenn der Server zur ProxySQL-Hostgruppe hinzugefügt wird), sind wir in einer guten Verfassung.
Fehlgeschlagene Backend-Verbindungen
Die Anzahl der Verbindungen, die von ProxySQL nicht erfolgreich hergestellt wurden:
Das obige Beispiel zeigt einfach, dass in den letzten 45 Minuten kein Ausfall der Backend-Verbindung aufgetreten ist.
Weitergeleitete Abfragen
Dieses Diagramm gibt Aufschluss über die Verteilung eingehender Anweisungen an die Backend-Server:
Wie Sie sehen können, gehen die meisten Lesevorgänge an die Reader-Hostgruppe (HG20). Von hier aus können wir das von ProxySQL durchgeführte Ausgleichsmuster verstehen, das unseren Abfrageregeln in dieser leseintensiven Arbeitslast entspricht.
Verbindung kostenlos
Die Grafik zeigt, wie viele Verbindungen derzeit frei sind:
Die Verbindungen werden offen gehalten, um den Zeitaufwand für das Senden einer Anfrage an den Backend-Server zu minimieren.
Latenz
Die aktuelle Ping-Zeit in Mikrosekunden, wie vom ProxySQL-Überwachungsthread gemeldet:
Dies sagt uns einfach, wie stabil die Verbindung von ProxySQL zu den Backend-MySQL-Servern ist. Ein hoher Wert für eine lange konsistente Zeit weist meistens auf ein Netzwerkproblem zwischen ihnen hin.
Cache-Speicher abfragen
Dieses Diagramm visualisiert den Speicherverbrauch von Abfragen, die von ProxySQL zwischengespeichert werden:
Aus dem obigen Diagramm können wir erkennen, dass ProxySQL insgesamt 8 MB Speicher durch den Abfrage-Cache verbraucht. Nach Erreichen der 8-MB-Grenze (konfigurierbar über mysql-query_cache_size_MB -Variable), wird der Speicher vom Purge-Thread von ProxySQL gelöscht. Dieses Diagramm wird nicht ausgefüllt, wenn Sie keine Abfrage-Cache-Regel definiert haben.
Übrigens:Das Zwischenspeichern einer Abfrage in ProxySQL ist mit ClusterControl mit nur zwei Klicks erledigt. Gehen Sie zur Seite „Top Queries“ von ProxySQL, bewegen Sie den Mauszeiger auf eine Abfrage, klicken Sie auf „Query Cache“ und dann auf „Add Rule“:
Abfrage-Cache-Effizienz
Dieses Diagramm visualisiert die Effizienz zwischengespeicherter Abfragen:
Die blaue Linie gibt uns das erfolgreiche Verhältnis von GET-Anforderungen an, die für den Abfrage-Cache ausgeführt wurden, wo die Ergebnismenge vorhanden und nicht abgelaufen war. Die rosa Linie zeigt das Verhältnis der Daten, die in den Abfrage-Cache geschrieben (insert) oder aus ihm gelesen wurden. In diesem Fall sind unsere aus dem Abfrage-Cache gelesenen Daten höher als die geschriebenen Daten, was auf eine effiziente Cache-Konfiguration hinweist.
Dieses Diagramm wird nicht ausgefüllt, wenn Sie keine Abfrage-Cache-Regel definiert haben.
Netzwerkverkehr
Dieses Diagramm visualisiert den Netzwerkverkehr (empfangene Daten + gesendete Daten) von/zu den Backend-MySQL-Servern pro Host:
Der obige Screenshot zeigt uns, dass eine erhebliche Menge an Datenverkehr von/zu der Reader-Hostgruppe (HG20) weitergeleitet/empfangen wird. Bei dieser leseintensiven Arbeitslast verbrauchen Lesevorgänge im Allgemeinen einen viel höheren Datenverkehr, hauptsächlich aufgrund der Größe der Ergebnismenge der SELECT-Anweisungen.
Nur ein kleinerer Anteil des Datenverkehrs wird von/zu der Schreib-Hostgruppe (HG10) weitergeleitet/empfangen, was zu erwarten ist, da die Schreibvorgänge normalerweise weniger Netzwerkverkehr verbrauchen und eine deutlich kleinere Ergebnismenge an die Clients zurückgegeben wird.
Spiegelungseffizienz
Das Diagramm zeigt einfach den Status der Traffic-Spiegelung wie Mirror_concurrency vs Mirror_queue_length:
Das Diagramm wird nur ausgefüllt, wenn Sie die Verkehrsspiegelung konfiguriert haben (mirror_hostgroup innerhalb der Abfrageregel). Wenn die Spiegelungswarteschlange zunimmt, erhöht das Reduzieren des Spiegelungsgleichzeitigkeitslimits die Spiegelungseffizienz, die über mysql-mirror_max_concurrency gesteuert werden kann Variable. In einfachen Worten, die Null-Warteschlangeneinträge sind das, worum es bei der effizientesten Spiegelung geht.
Speicherauslastung
Das Diagramm veranschaulicht die Speicherauslastung durch die Hauptkomponenten in ProxySQL – Verbindungspool, Abfrage-Cache und dauerhafter Speicher (SQLite):
Der obige Screenshot zeigt uns, dass der ProxySQL-Speicherbedarf ziemlich gering ist und insgesamt weniger als 12 MB beträgt. Der Verbindungspool verbraucht nur maximal 1,3 MB, um unsere Arbeitslast mit 8 Threads (Clients) zu bewältigen. Mit mehr freiem RAM auf dem Host sollten wir in der Lage sein, die Anzahl der Client-Verbindungen zu ProxySQL um das Drei- bis Vierfache zu erhöhen oder viel mehr heiße Abfragen in ProxySQL zwischenzuspeichern, um unsere MySQL-Backend-Server zu entlasten.
Bonusfunktion - Knotenleistung
ClusterControl 1.7.0 enthält jetzt Hostleistungsmetriken für die ProxySQL-Instanzen. In der vorherigen Version überwachte ClusterControl nur die ProxySQL-bezogenen Metriken, wie sie vom ProxySQL-Statistikschema offengelegt wurden. Auf diese neue Funktion kann unter der Registerkarte „Knoten“ -> „ProxySQL-Instanz“ -> „Knotenleistung“ zugegriffen werden:
Die Histogramme bieten Einblick in die wichtigsten Host-Metriken, ähnlich denen, die für Datenbankknoten im Abschnitt Knoten -> Übersicht abgetastet werden. Wenn sich Ihre ProxySQL-Instanz zusammen mit der Anwendung auf demselben Server befindet, verwenden Sie ClusterControl buchstäblich auch zur Überwachung des Anwendungsservers. Wie cool ist das denn?!
Abschließende Gedanken
Die ClusterControl-Integration mit Prometheus bietet eine alternative Möglichkeit zur Überwachung und Analyse Ihres Datenbankstapels bis hin zur Reverse-Proxy-Ebene. Sie haben jetzt die Wahl, die Überwachungsjobs an Prometheus auszulagern oder weiterhin den standardmäßigen agentenlosen ClusterControl-Überwachungsansatz für Ihre Datenbankinfrastruktur zu verwenden.
