MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

Agentenloses Datenbank-Monitoring mit ClusterControl

Angesichts der wachsenden Komplexität von Datenbank-Setups wenden sich viele SysAdmins und DBAs einem agentenlosen Ansatz zu, um die Herausforderungen der Datenbanküberwachung zu verringern. Die agentenlose Überwachung von ClusterControl ermöglicht es Ihnen, Datenbanken zu überwachen, ohne Agentensoftware auf jedem überwachten System zu installieren. ClusterControl implementiert die Überwachung mithilfe eines Remote-Datenkollektors, der das SSH-Protokoll verwendet.

Bevor wir direkt in die Besonderheiten der agentenlosen Überwachung eintauchen, wollen wir zunächst den Umfang und die Bedeutung der Überwachung in unserem Kontext hier klären. Die Überwachung erfolgt nach dem Datentrending – dem Erfassungs- und Speicherungsprozess von Metriken – was es dem Überwachungssystem ermöglicht, die gesammelten Daten zu verarbeiten, um eine Begründung für die Optimierung, Warnung und Anzeige von Trenddaten für die Berichterstellung zu liefern.

Ab Version 1.7.0 (veröffentlicht im Dezember 2018) unterstützt ClusterControl zwei Überwachungsmethoden:

  • Agentenlose Überwachung (Standard)
  • Agentenbasierte Überwachung mit Prometheus

Dieser Beitrag führt Sie durch die Überwachung Ihrer Datenbankserver und Cluster mit der agentenlosen Überwachung von ClusterControl. Wenn Sie nach weiteren Informationen zur agentenbasierten Überwachung von ClusterControl suchen, können Sie diese Dokumentation lesen.

Im Allgemeinen führt ClusterControl agentenlose Überwachungs-, Alarmierungs- und Trending-Aufgaben mit den folgenden drei Methoden aus:

  • SSH – Host-Metrikensammlung (Prozess, Load-Balancer-Statistiken, Ressourcennutzung, Verbrauch usw.) unter Verwendung der SSH-Bibliothek
  • Datenbank-Client – ​​Sammlung von Datenbankmetriken (Status, Abfragen, Variablen, Nutzung usw.) unter Verwendung der jeweiligen Datenbank-Client-Bibliothek
  • Advisor – Mini-Programme, die mit ClusterControl DSL geschrieben wurden und innerhalb von ClusterControl selbst zu Überwachungs-, Optimierungs- und Warnzwecken ausgeführt werden

SSH steht für Secure Shell, ein sicheres Netzwerkprotokoll, das von den meisten Linux-basierten Servern für die Fernverwaltung verwendet wird. ClusterControl Controller oder CMON ist der Backend-Dienst, der Automatisierungs-, Verwaltungs-, Überwachungs- und Planungsaufgaben ausführt und auf C++ aufbaut.

ClusterControl DSL (Domain Specific Language) ermöglicht es Ihnen, die Funktionalität Ihrer ClusterControl-Plattform zu erweitern, indem Sie Advisors, Auto Tuner oder "Mini-Programme" erstellen. Die DSL-Syntax basiert auf JavaScript, mit Erweiterungen, um Zugriff auf interne Datenstrukturen und Funktionen von ClusterControl zu ermöglichen. Mit der DSL können Sie SQL-Anweisungen ausführen, Shell-Befehle/-Programme auf allen Ihren Cluster-Hosts ausführen und Ergebnisse abrufen, die für Advisor/Warnungen oder andere Aktionen verarbeitet werden sollen.

Überwachungstools

Alle vorausgesetzten Tools werden vom Installationsskript erfüllt oder automatisch von ClusterControl während der Datenbankbereitstellungsphase installiert oder wenn die erforderliche Datei/Binärdatei/Paket nicht auf dem Zielserver vorhanden ist, bevor ein Auftrag ausgeführt wird. Im Allgemeinen erfordert die ClusterControl-Überwachungspflicht nur das OpenSSH-Serverpaket auf den überwachten Hosts. ClusterControl verwendet die libssh-Client-Bibliothek, um Host-Metriken für die überwachten Hosts zu sammeln – CPU, Arbeitsspeicher, Festplatte, Netzwerk, E/A, Prozess usw. Das OpenSSH-Client-Paket ist auf dem ClusterControl-Host nur erforderlich, um passwortloses SSH und Debugging-Zwecke einzurichten. Andere SSH-Implementierungen wie Dropbear und TinySSH werden nicht unterstützt.

Beim Sammeln der Datenbankstatistiken und -metriken verbindet sich ClusterControl Controller (CMON) direkt mit dem Datenbankserver über Datenbank-Client-Bibliotheken – libmysqlclient (MySQL/MariaDB und ProxySQL), libpq (PostgreSQL) und libmongocxx (MongoDB ). Aus diesem Grund ist es wichtig, die richtigen Berechtigungen für einen ClusterControl-Server aus der Perspektive eines Datenbankservers einzurichten. Für MySQL-basierte Cluster erfordert ClusterControl den Datenbankbenutzer „cmon“, während für andere Datenbanken jeder Benutzername für die Überwachung verwendet werden kann, solange ihm Superuser-Privilegien gewährt werden. Meistens richtet ClusterControl die erforderlichen Berechtigungen (oder verwendet den angegebenen Datenbankbenutzer) automatisch während des Clusterimports oder der Clusterbereitstellungsphase ein.

ClusterControl erfordert die folgenden Tools für Load Balancer:

  • Maxctrl auf dem MariaDB MaxScale-Server
  • netcat und/oder socat auf dem HAProxy-Server, um eine Verbindung zur HAProxy-Socket-Datei herzustellen und die Überwachungsdaten abzurufen
  • ProxySQL erfordert einen MySQL-Client auf dem ProxySQL-Server

Das folgende Diagramm veranschaulicht sowohl Host- als auch Datenbanküberwachungsprozesse, die von ClusterControl unter Verwendung von libssh und Datenbank-Client-Bibliotheken ausgeführt werden:

Obwohl Überwachungs-Threads keine auf dem überwachten Host installierten Datenbank-Client-Pakete benötigen, Es wird dringend empfohlen, sie für Verwaltungszwecke zu haben. Beispielsweise enthält das MySQL-Clientpaket die Programme mysql, mysqldump, mysqlbinlog und mysqladmin, die von ClusterControl beim Durchführen von Sicherungen und Wiederherstellungen zu einem bestimmten Zeitpunkt verwendet werden.

Überwachungsmethoden

Für die Erfassung von Host- und Load-Balancer-Statistiken führt ClusterControl diese Aufgabe über SSH mit Superuser-Privilegien aus. Daher ist passwortloses SSH mit Superuser-Privilegien von entscheidender Bedeutung, damit ClusterControl die erforderlichen Befehle remote mit angemessener Eskalation ausführen kann. Dieser Pull-Ansatz bietet im Vergleich zu anderen Mechanismen einige Vorteile:

  • Ohne Agent – ​​Es muss kein Agent installiert, konfiguriert und gewartet werden.
  • Vereinheitlichung der Verwaltungs- und Überwachungskonfiguration – SSH kann verwendet werden, um Überwachungsmetriken abzurufen oder Verwaltungsjobs auf die Zielknoten zu übertragen.
  • Vereinfachen Sie die Bereitstellung – Die einzige Voraussetzung ist eine ordnungsgemäße passwortlose SSH-Einrichtung, und das war's. SSH ist auch sehr sicher und verschlüsselt.
  • Zentrale Einrichtung – Ein ClusterControl-Server kann mehrere Server und Cluster verwalten, sofern er über ausreichende Ressourcen verfügt.

Allerdings hat der Zugmechanismus auch folgende Nachteile:

  • Die Überwachungsdaten sind nur aus Sicht von ClusterControl korrekt. Wenn beispielsweise ein Netzwerkfehler auftritt und ClusterControl die Kommunikation mit dem überwachten Host verliert, wird das Sampling bis zum nächsten verfügbaren Zyklus übersprungen.
  • Aufgrund der erhöhten Abtastrate, bei der ClusterControl mehr Verbindungen zu jedem Zielhost herstellen muss, entsteht ein Netzwerk-Overhead für die Überwachung mit hoher Granularität.
  • ClusterControl wird weiterhin versuchen, die Verbindung zum Zielknoten wiederherzustellen, da es keinen Agenten hat, der dies in seinem Namen tut.
  • Redundantes Daten-Sampling, wenn Sie mehr als einen ClusterControl-Server haben, der einen Cluster überwacht, da jeder ClusterControl-Server die Überwachungsdaten für sich selbst ziehen muss.

Für die Überwachung von MySQL-Abfragen unterstützt ClusterControl ab ClusterControl 1.9.0 (veröffentlicht im Juli 2021) zwei Typen:

  • Agentenlose Abfrageüberwachung (Standard)
  • Agentenbasierte Abfrageüberwachung mit dem CMON-Abfrageagenten, für dessen Aktivierung zusätzliche Schritte erforderlich sind. Nur für MySQL-basierte und PostgreSQL-basierte Datenbanken.

Die agentenlose Abfrageüberwachung überwacht die Abfragen auf zwei verschiedene Arten:

  • Abfragen werden von PERFORMANCE_SCHEMA abgerufen, indem das Schema auf dem Datenbankknoten über SSH abgefragt wird.
  • Wenn PERFORMANCE_SCHEMA deaktiviert oder nicht verfügbar ist, parst ClusterControl den Inhalt des Slow Query Log über SSH.

Wenn das Leistungsschema aktiviert ist, verwendet ClusterControl es, um nach langsamen Abfragen zu suchen. Andernfalls parst ClusterControl den Inhalt des langsamen MySQL-Abfrageprotokolls (über die dynamische Variable slow_query_log=ON) basierend auf dem folgenden Ablauf:

  1. Langsames Log starten (während MySQL-Laufzeit).
  2. Lassen Sie es für kurze Zeit laufen (eine Sekunde oder ein paar Sekunden).
  3. Stoppprotokoll.
  4. Protokoll parsen.
  5. Protokoll kürzen (neue Protokolldatei).
  6. Gehe zu 1.

Die gesammelten Abfragen werden gehasht, berechnet und verarbeitet (normalisieren, mitteln, zählen, sortieren) und dann in der ClusterControl CMON-Datenbank gespeichert. Beachten Sie, dass bei dieser Sampling-Methode eine geringe Wahrscheinlichkeit besteht, dass einige Abfragen nicht erfasst werden, insbesondere während der Teile „Protokoll stoppen, Protokoll analysieren, Protokoll abschneiden“. Sie können das Leistungsschema aktivieren, wenn dies keine Option ist.

Nur Abfragen, die die lange Abfragezeit überschreiten, werden hier unter Verwendung des Protokolls für langsame Abfragen aufgelistet. Angenommen, die Daten sind nicht korrekt ausgefüllt, und Sie glauben, dass etwas darin sein sollte, dann könnte es Folgendes sein:

  • ClusterControl hat nicht genügend Abfragen gesammelt, um Daten zusammenzufassen und aufzufüllen. Versuchen Sie, die lange Abfragezeit zu verringern.
  • Sie haben die Konfigurationsoptionen für Slow Query Log in my.cnf des MySQL-Servers konfiguriert und Override Local Query ist deaktiviert. Wenn Sie wirklich den Wert verwenden möchten, den Sie in my.cnf definiert haben, müssen Sie wahrscheinlich den Wert von long_query_time verringern, damit ClusterControl ein genaueres Ergebnis berechnen kann.
  • Sie haben einen anderen ClusterControl-Knoten, der auch das Slow Query-Protokoll abruft (falls Sie einen Standby-ClusterControl-Server haben). Erlauben Sie nur einem ClusterControl-Server, diese Aufgabe zu erledigen.

Sie können auch den ClusterControl Query Monitor für MySQL, MariaDB und Percona Server verwenden.

Für die Überwachung von PostgreSQL-Abfragen benötigt ClusterControl das Modul pg_stat_statements, um Ausführungsstatistiken aller SQL-Anweisungen zu verfolgen. Es füllt die Ansichten und Funktionen von pg_stat_statements, wenn die Abfragen in der Benutzeroberfläche angezeigt werden (unter der Registerkarte "Abfrageüberwachung").

Intervalle und Timeouts

ClusterControl Controller (cmon) ist ein Multithread-Prozess. Standardmäßig stellt der ClusterControl Controller-Stichproben-Thread einmal eine Verbindung zu jedem überwachten Host her und hält eine dauerhafte Verbindung aufrecht, bis der Host bei der Stichprobenentnahme von Hoststatistiken unterbrochen oder getrennt wird. Abhängig von den dem Host zugewiesenen Jobs können mehr Verbindungen hergestellt werden, da die meisten Verwaltungsjobs in ihrem eigenen Thread ausgeführt werden. Beispielsweise wird die Cluster-Wiederherstellung auf dem Wiederherstellungs-Thread ausgeführt, die Advisor-Ausführung auf einem Cron-Thread und die Prozessüberwachung auf dem Prozesskollektor-Thread.

ClusterControl-Überwachungsthread führt die folgenden Stichprobenvorgänge im folgenden Intervall aus:

  • MySQL-Abfrage-/Statusmetriken:jede Sekunde
  • Sammlung verarbeiten (/proc):alle 10 Sekunden
  • Servererkennung:alle 10 Sekunden
  • Host-Metriken (/proc, /sys):alle 30 Sekunden (konfigurierbar über host_stats_collection_interval)
  • Datenbankmetriken (nur PostgreSQL und MongoDB):alle 30 Sekunden (konfigurierbar über db_stats_collection_interval)
  • Datenbankschemametriken:alle 3 Stunden (konfigurierbar über db_schema_stats_collection_interval)
  • Load-Balancer-Metriken:alle 15 Sekunden (konfigurierbar über lb_stats_collection_interval)

Die imperativen Skripte (Advisors) können mit den folgenden Einschränkungen SSH- und Datenbank-Client-Bibliotheken verwenden, die mit CMON geliefert werden:

  • 5 Sekunden festes Limit für die SSH-Ausführung.
  • 10 Sekunden Standardlimit für Datenbankverbindung, konfigurierbar über net_read_timeout, net_write_timeout, connect_timeout in der CMON-Konfigurationsdatei.
  • 60 Sekunden Gesamtzeitlimit für die Ausführung des Skripts, bevor CMON es unsanft abbricht.

Advisors können direkt über die Benutzeroberfläche von ClusterControl unter Verwalten → Developer Studio erstellt, kompiliert, getestet und geplant werden . Der folgende Screenshot zeigt ein Beispiel eines Advisors zum Extrahieren der Top-10-Anfragen aus PERFORMANCE_SCHEMA:

Die Ausführung von Advisors hängt davon ab, ob sie aktiviert sind, und von der Planungszeit im Cron-Format:

Die Ergebnisse der Ausführung werden unter Performance → Advisors , wie im folgenden Screenshot gezeigt:

Weitere Informationen zu den standardmäßig bereitgestellten Advisors finden Sie in unserem Developer Studio-Produktseite.

Daten werden direkt in der CMON-Datenbank für kurzzeitige Überwachungsdaten wie MySQL-Abfragen und Status gespeichert. Langfristige Überwachungsdaten wie wöchentliche/monatliche/jährliche Datenpunkte werden alle 60 Sekunden aggregiert und 10 Minuten lang im Speicher gespeichert. Diese Verhaltensweisen sind aufgrund des Architekturdesigns nicht konfigurierbar.

Parameter

ClusterControl hat viele Parameter, die zu Ihrer Überwachungs- und Benachrichtigungsrichtlinie passen. Die meisten von ihnen sind über die ClusterControl-Benutzeroberfläche → Cluster auswählen → Einstellungen konfigurierbar . Die Registerkarte „Einstellungen“ bietet viele Optionen zum Konfigurieren von Warnungen, Schwellenwerten, Benachrichtigungen, Diagrammlayout, Datenbankzählern, Abfrageüberwachung und so weiter. Warnungs- und kritische Schwellenwerte sind beispielsweise wie folgt konfigurierbar:

Die Seite „Runtime Configuration“ zeigt eine zusammengefasste Liste der aktiven ClusterControl Controller (CMON) Laufzeitkonfigurationsparameter:

Es gibt insgesamt mehr als 170 ClusterControl-Controller-Konfigurationsoptionen und einige davon Die erweiterten Einstellungen können zur Feinabstimmung der Überwachungs- und Warnrichtlinien konfiguriert werden. Einige davon sind:

  • monitor_cpu_temperature
  • swap_warning
  • swap_critical
  • redobuffer_warning
  • redobuffer_critical
  • indexmemory_warning
  • indexmemory_critical
  • datamemory_warning
  • datamemory_critical
  • tablespace_warning
  • tablespace_critical
  • redolog_warning
  • redolog_critical
  • max_replication_lag
  • long_query_time
  • log_queries_not_using_indexes
  • query_monitor_use_local_settings
  • enable_query_monitor
  • enable_query_monitor_auto_purge_ps

Sie können die auf der Seite „Laufzeitkonfiguration“ aufgeführten Parameter ändern, indem Sie entweder die UI- oder die CMON-Konfigurationsdatei verwenden, die sich unter /etc/cmon.d/cmon_X.cnf befindet, wobei X die Cluster-ID ist. Sie können alle unterstützten Konfigurationsoptionen für CMON auflisten, indem Sie den folgenden Befehl verwenden:

$ cmon --help-config

Abschließende Gedanken

Agentenloses Monitoring hat sich zu einer der effektivsten Methoden zur Verwaltung immer komplexerer Datenbankinfrastrukturen entwickelt. Es reduziert die Belastung durch viele Herausforderungen im Zusammenhang mit der Datenbanküberwachung und ist einfach zu verwalten.

Es gibt heute viele agentenlose Überwachungstools. Allerdings bieten nicht viele von ihnen auch eine vollständige Plattform voller Funktionen, die Ihnen bei der Verwaltung aller anderen Aspekte Ihrer Datenbank-Cluster helfen. Um zu sehen, was ClusterControl sonst noch kann, laden Sie unbedingt Ihre eigene kostenlose 30-Tage-Testversion herunter.

Suchen Sie eine agentenbasierte Alternative zur Datenbanküberwachung? Sehen Sie sich die agentenbasierte Datenbanküberwachungsinfrastruktur von ClusterControl an – SCUMM.