Wir haben in unserer neuesten Version von ClusterControl 1.7.0 eine Reihe neuer Dashboards für MySQL hinzugefügt. - und in unserem vorherigen Blog haben wir Ihnen gezeigt, wie Sie Ihren ProxySQL mit Prometheus und ClusterControl überwachen können.
In diesem Blog sehen wir uns das MySQL-Übersichts-Dashboard an.
Daher haben wir die agentenbasierte Überwachung auf der Registerkarte Dashboard aktiviert, um mit dem Sammeln von Metriken für die Knoten zu beginnen. Beachten Sie, dass Sie beim Aktivieren der agentenbasierten Überwachung die Option haben, das „Scrape-Intervall (Sekunden) festzulegen “ und „Datenaufbewahrung (Tage) “. Beim Scraping-Intervall möchten Sie festlegen, wie aggressiv Prometheus Daten vom Ziel erfasst, und bei der Datenaufbewahrung legen Sie fest, wie lange Sie Ihre von Prometheus gesammelten Daten aufbewahren möchten, bevor sie gelöscht werden.
Wenn diese Option aktiviert ist, können Sie erkennen, welcher Cluster über Agenten verfügt und welcher über agentenlose Überwachung verfügt.
Im Vergleich zum agentenlosen Ansatz ist die Granularität Ihrer Daten in Diagrammen mit Agenten höher.
Die MySQL-Grafiken
Die neueste Version von ClusterControl 1.7.0 (die Sie kostenlos herunterladen können - ClusterControl Community) hat die folgenden MySQL-Dashboards, für die Sie Informationen für Ihre MySQL-Server sammeln können. Dies sind MySQL-Übersicht, MySQL InnoDB-Metriken, MySQL-Leistungsschema und MySQL-Replikation.
Wir werden die im MySQL-Übersichts-Dashboard verfügbaren Diagramme ausführlich behandeln.
MySQL-Übersichts-Dashboard
Dieses Dashboard enthält die üblichen wichtigen Variablen oder Informationen zum Zustand Ihres MySQL-Knotens. Die in diesem Dashboard enthaltenen Diagramme sind spezifisch für den Knoten, der beim Anzeigen der Dashboards ausgewählt wurde, wie unten gezeigt:
Es besteht aus 26 Diagrammen, die Sie jedoch möglicherweise nicht alle benötigen, wenn Sie Probleme diagnostizieren. Diese Diagramme bieten jedoch eine wichtige Darstellung der Gesamtmetriken für Ihre MySQL-Server. Lassen Sie uns die Grundlagen durchgehen, da dies wahrscheinlich die häufigsten Dinge sind, die sich ein DBA routinemäßig ansehen wird.
Die ersten vier oben gezeigten Diagramme zusammen mit der Verfügbarkeit von MySQL, den Abfragen pro Sekunde und den Pufferpoolinformationen sind die grundlegendsten Hinweise, die wir möglicherweise benötigen. Von den oben angezeigten Diagrammen sind hier ihre Darstellungen:
- MySQL-Verbindungen
Hier möchten Sie Ihre gesamten Client-Verbindungen überprüfen, die bisher in einem bestimmten Zeitraum zugewiesen wurden. - Thread-Aktivität des MySQL-Clients
Es kann vorkommen, dass Ihr MySQL-Server sehr ausgelastet ist. Beispielsweise kann zu einem bestimmten Zeitpunkt ein Anstieg des Datenverkehrs erwartet werden, und Sie möchten die Aktivität Ihrer laufenden Threads überwachen. Es ist wirklich wichtig, sich diesen Graphen anzusehen. Es kann vorkommen, dass Ihre Abfrageleistung nachlässt, wenn beispielsweise ein großes Update dazu führt, dass andere Threads warten, bis sie eine Sperre erhalten. Dies würde zu einer erhöhten Anzahl Ihrer laufenden Threads führen. Die Cache-Miss-Rate wird als Threads_created/Connections.
berechnet - MySQL-Fragen
Dies sind die Abfragen, die in einem bestimmten Zeitraum ausgeführt werden. Ein Thread kann eine Transaktion sein, die aus mehreren Abfragen besteht, und dies kann ein guter Graph sein, den man sich ansehen sollte. - MySQL-Thread-Cache
Dieses Diagramm zeigt den thread_cache_size-Wert, zwischengespeicherte Threads (wiederverwendete Threads) und erstellte Threads (neue Threads). Sie können dieses Diagramm auf solche Fälle überprüfen, in denen Sie Ihre Leseabfragen optimieren müssen, wenn Sie eine hohe Anzahl eingehender Verbindungen feststellen und Ihre erstellten Threads schnell ansteigen. Wenn beispielsweise Ihre Threads_running / thread_cache_size> 2 ist, kann eine Erhöhung Ihrer thread_cache_size Ihrem Server einen Leistungsschub verleihen. Beachten Sie, dass das Erstellen und Zerstören von Threads teuer ist. In den neueren Versionen von MySQL (>=5.6.8) hat diese Variable jedoch standardmäßig eine automatische Größenanpassung, die Sie möglicherweise als unverändert betrachten.
Die nächsten vier Diagramme sind MySQL Temporary Objects, MySQL Select Types, MySQL Sorts und MySQL Slow Queries. Diese Diagramme stehen in Beziehung zueinander, insbesondere wenn Sie lange laufende Abfragen und große Abfragen diagnostizieren, die optimiert werden müssen.
- Temporäre MySQL-Objekte
Dieses Diagramm ist eine gute Quelle, auf die Sie sich verlassen können, wenn Sie lang andauernde Abfragen überwachen möchten, die am Ende Festplatten anstelle von temporären Tabellen oder Dateien verwenden würden, die in den Arbeitsspeicher gehen. Es ist ein guter Ausgangspunkt, um nach regelmäßigen Abfragen zu suchen, die sich zu Speicherplatzproblemen summieren können, insbesondere zu ungewöhnlichen Zeiten. - MySQL Select-Typen
Eine Quelle schlechter Leistung sind Abfragen, die vollständige Verknüpfungen, Tabellenscans und ausgewählte Bereiche verwenden, die keine Indizes verwenden. Dieses Diagramm würde zeigen, wie Ihre Abfrage abschneidet und was in der Liste von vollständigen Joins bis hin zu Full-Range-Joins, Select-Range und Table-Scans die höchsten Trends aufweist. - MySQL-Sortierungen
Diagnose der Abfragen, die eine Sortierung verwenden, und der Abfragen, die viel Zeit in Anspruch nehmen. - MySQL Langsame Abfragen
Trends Ihrer langsamen Abfragen werden hier in diesem Diagramm erfasst. Dies ist sehr nützlich, insbesondere um zu diagnostizieren, wie oft Ihre Abfragen langsam sind. Welche Dinge müssen abgestimmt werden? Es könnte ein zu kleiner Pufferpool sein, Tabellen, denen Indizes fehlen und die einen vollständigen Tabellenscan durchlaufen, logische Sicherungen, die nach einem unerwarteten Zeitplan ausgeführt werden, usw. Die Verwendung unseres Abfragemonitors in ClusterControl zusammen mit diesem Diagramm ist vorteilhaft, da es dabei hilft, langsame Abfragen zu ermitteln.
Die nächsten Diagramme, die wir behandeln, zeigen mehr die Netzwerkaktivität, Tabellensperren und den zugrunde liegenden internen Speicher, den MySQL während der MySQL-Aktivität verbraucht.
- Abgebrochene MySQL-Verbindungen
Die Anzahl der abgebrochenen Verbindungen wird in diesem Diagramm angezeigt. Dies umfasst die abgebrochenen Clients, z. B. bei denen das Netzwerk abrupt geschlossen wurde oder bei denen die Internetverbindung unterbrochen oder unterbrochen wurde. Es zeichnet auch die abgebrochenen Verbindungen oder Versuche wie falsche Passwörter oder fehlerhafte Pakete beim Verbindungsaufbau vom Client auf. - MySQL-Tabellensperren
Trends für Tabellen, die eine sofort erteilte Tabellensperre anfordern, und für Tabellen, die eine nicht sofort erteilte Sperre anfordern. Wenn Sie beispielsweise Sperren auf Tabellenebene für MyISAM-Tabellen und eingehende Anfragen derselben Tabelle haben, können diese nicht sofort gewährt werden. - MySQL-Netzwerkverkehr
Dieses Diagramm zeigt die Trends der eingehenden und ausgehenden Netzwerkaktivität im MySQL-Server. „Eingehend“ sind die vom MySQL-Server empfangenen Daten, während „Ausgehend“ die vom Server vom MySQL-Server gesendeten oder übertragenen Daten sind. Dieses Diagramm ist am besten zu überprüfen, wenn Sie Ihren Netzwerkverkehr überwachen möchten, insbesondere wenn Sie Ihren Datenverkehr diagnostizieren ist moderat, aber Sie fragen sich, warum es sehr viele ausgehende übertragene Daten hat, wie zum Beispiel BLOB-Daten. - MySQL-Netzwerknutzung stündlich
Dasselbe wie der Netzwerkverkehr, der die empfangenen und gesendeten Daten anzeigt. Beachten Sie, dass es auf „pro Stunde“ basiert und mit „letzter Tag“ gekennzeichnet ist, was nicht dem Zeitraum folgt, den Sie in der Datumsauswahl ausgewählt haben. - Überblick über den internen MySQL-Speicher
Diese Grafik ist einem erfahrenen MySQL-DBA vertraut. Jede dieser Legenden im Balkendiagramm ist sehr wichtig, besonders wenn Sie Ihre Speichernutzung, Ihre Pufferpoolnutzung oder Ihre adaptive Hash-Indexgröße überwachen möchten.
Die folgenden Diagramme zeigen die Zähler, auf die sich ein DBA verlassen kann, wie z. B. die Überprüfung der Statistiken, die Statistiken für Auswahlen, Einfügungen, Aktualisierungen, die Anzahl der ausgeführten Master-Status, die Anzahl der ausgeführten SHOW VARIABLES, Überprüfung wenn Sie schlechte Abfragen haben, die Tabellenscans durchführen, oder Tabellen, die keine Indizes verwenden, indem Sie die read_*-Zähler usw. durchsehen.
- Top-Befehlszähler (stündlich)
Dies sind die Diagramme, die Sie wahrscheinlich überprüfen müssen, wenn Sie die Statistiken für Ihre Einfügungen, Löschungen, Aktualisierungen, ausgeführten Befehle wie das Sammeln der Prozessliste, den Slave-Status, den Show-Status (Zustandsstatistiken des MySQL-Servers) sehen möchten ), und viele mehr. Dies ist ein guter Ort, wenn Sie überprüfen möchten, welche Art von MySQL-Befehlszählern ganz oben stehen und ob eine Leistungsoptimierung oder Abfrageoptimierung erforderlich ist. Es könnte Ihnen auch ermöglichen, zu erkennen, welche Befehle aggressiv ausgeführt werden, ohne sie zu benötigen. - MySQL-Handler
Häufig würde ein DBA diese Handler durchgehen und überprüfen, wie die Abfragen auf Ihrem MySQL-Server funktionieren. Grundsätzlich deckt dieses Diagramm die Zähler der Handler-API von MySQL ab. Die gebräuchlichsten Handler-Zähler für einen DBA für die Speicher-API in MySQL sind Handler_read_first, Handler_read_key, Handler_read_last, Handler_read_next, Handler_read_prev, Handler_read_rnd und Handler_read_rnd_next. Es gibt viele MySQL-Handler, die Sie überprüfen können. Sie können darüber in der Dokumentation hier nachlesen. - MySQL-Transaktions-Handler
Wenn Ihr MySQL-Server XA-Transaktionen verwendet, SAVEPOINT-, ROLLBACK TO SAVEPOINT-Anweisungen. Dann ist diese Grafik eine gute Referenz. Sie können dieses Diagramm auch verwenden, um alle internen Commits Ihres Servers zu überwachen. Beachten Sie, dass der Zähler für Handler_commit sogar für SELECT-Anweisungen inkrementiert wird, sich aber von Insert/Update/Delete-Anweisungen unterscheidet, die während eines Aufrufs der COMMIT-Anweisung in das Binärlog gehen.
Das nächste Diagramm zeigt Trends zu Prozesszuständen und deren stündlicher Nutzung. Hier in der Legende des Balkendiagramms gibt es viele wichtige Punkte, die ein DBA überprüfen würde. Auftreten von Speicherplatzproblemen, Verbindungsproblemen und Prüfen, ob Ihr Verbindungspool wie erwartet funktioniert, hohe Festplatten-E/A, Netzwerkprobleme usw.
- Prozesszustände/Top-Prozesszustände stündlich
In diesem Diagramm können Sie die Top-Thread-Zustände Ihrer Abfragen überwachen, die in der Prozessliste ausgeführt werden. Dies ist sehr informativ und hilfreich für solche DBA-Aufgaben, bei denen Sie hier alle ausstehenden Status untersuchen können, die aufgelöst werden müssen. Beispiel:Tische öffnen Der Zustand ist sehr hoch und sein Minimalwert liegt fast nahe am Maximalwert. Dies könnte darauf hindeuten, dass Sie den table_open_cache anpassen müssen. Wenn die Statistiken hoch ist und Sie eine Verlangsamung Ihres Servers bemerken, könnte dies darauf hindeuten, dass Ihr Server festplattengebunden ist und Sie möglicherweise eine Erhöhung Ihres Pufferpools in Betracht ziehen müssen. Wenn Sie eine hohe Anzahl von erstellenden tmp-Tabellen haben dann müssen Sie möglicherweise Ihr langsames Protokoll überprüfen und die anstößigen Abfragen optimieren. Sie können das Handbuch für die vollständige Liste der MySQL-Thread-Zustände hier auschecken.
Die nächste Grafik, die wir überprüfen werden, betrifft den Abfrage-Cache, den MySQL-Tabellendefinitions-Cache und wie oft MySQL Systemdateien öffnet.
- MySQL-Abfrage-Cache-Speicher/Aktivität
Diese Grafiken sind miteinander verbunden. Wenn Sie query_cache_size <> 0 und query_cache_type <> 0 haben, kann dieses Diagramm hilfreich sein. In den neueren Versionen von MySQL wurde der Abfrage-Cache jedoch als veraltet markiert, da bekannt ist, dass der MySQL-Abfrage-Cache Leistungsprobleme verursacht. Möglicherweise benötigen Sie dies in Zukunft nicht mehr. Die neueste Version von MySQL 8.0 hat drastische Verbesserungen; es erhöht tendenziell die Leistung, da es mehrere Strategien zum Umgang mit Cache-Informationen in den Speicherpuffern enthält. - MySQL-Dateiöffnungen
Dieses Diagramm zeigt den Trend für die geöffneten Dateien seit der Betriebszeit des MySQL-Servers, schließt jedoch Dateien wie Sockets oder Pipes aus. Es enthält auch keine Dateien, die von der Speicher-Engine geöffnet werden, da sie ihren eigenen Zähler haben, nämlich Innodb_num_open_files. - Offene MySQL-Dateien
In diesem Diagramm können Sie Ihre aktuell geöffneten InnoDB-Dateien, die aktuell geöffneten MySQL-Dateien und Ihre open_files_limit-Variable überprüfen. - MySQL Table Open Cache Status
Wenn Sie hier einen sehr niedrigen table_open_cache eingestellt haben, informiert Sie dieses Diagramm über die Tabellen, die den Cache nicht erfüllen (neu geöffnete Tabellen) oder aufgrund eines Überlaufs fehlschlagen. Wenn Sie in Ihrer Prozessliste auf eine hohe Anzahl oder zu viel Status „Tische öffnen“ stoßen, dient diese Grafik als Referenz, um dies festzustellen. Dadurch erfahren Sie, ob Sie Ihre table_open_cache-Variable erhöhen müssen. - Offene MySQL-Tabellen
In Bezug auf den Status des geöffneten MySQL-Tabellen-Cache ist dieses Diagramm in bestimmten Fällen nützlich, z. B. wenn Sie feststellen möchten, ob Ihr table_open_cache erhöht oder verringert werden muss, wenn Sie eine starke Zunahme offener Tabellen oder der Open_tables-Statusvariable bemerken . Beachten Sie, dass table_open_cache viel Speicherplatz beanspruchen kann, daher müssen Sie dies besonders in Produktionssystemen mit Bedacht festlegen. - Cache für MySQL-Tabellendefinitionen
Wenn Sie die Anzahl Ihrer Open_table_definitions- und Opened_table_definitions-Statusvariablen überprüfen möchten, dann ist dieses Diagramm genau das, was Sie brauchen. Bei neueren Versionen von MySQL (>=5.6.8) müssen Sie den Wert dieser Variablen möglicherweise nicht ändern und den Standardwert verwenden, da er über eine Funktion zur automatischen Größenanpassung verfügt.
Schlussfolgerung
Die SCUMM-Erweiterung in der neuesten Version von ClusterControl 1.7.0 bietet bedeutende neue Vorteile für eine Reihe wichtiger DBA-Aufgaben. Die neuen Diagramme können dazu beitragen, die Ursache von Problemen, mit denen sich DBAs oder Systemadministratoren normalerweise befassen müssten, leicht zu lokalisieren und geeignete Lösungen schneller zu finden.
Wir würden gerne Ihre Erfahrungen und Gedanken zur Verwendung von ClusterControl 1.7.0 mit SCUMM hören (das Sie kostenlos herunterladen können - ClusterControl Community).
In Teil 2 dieses Blogs werde ich die effektive Überwachung der MySQL-Replikation mit SCUMM-Dashboards diskutieren.
