Überwachen und Nachverfolgen von Aktivitäten

  • 11 Minuten

Einen großen Teil der Verwaltung von Datenbanken nimmt die Leistungsoptimierung ein. Die gleichen Protokolldateien, die Sie für die Überprüfung Ihrer lokalen Datenbanken verwendet haben, sind auch weiterhin in Azure Database for MySQL/PostgreSQL verfügbar.

Nachdem Sie Ihre Datenbanken zu Azure migriert haben, müssen Sie die Protokolldateien weiterhin überprüfen, um sicherzustellen, dass die Leistung der Datenbanken gewahrt bleibt.

In dieser Lerneinheit erfahren Sie, wo die Protokolldateien für PostgreSQL und MySQL in Azure gespeichert werden und welche Details sie enthalten.

Verwenden von Serverprotokollen zum Nachverfolgen von Datenbankaktivitäten

Azure Database for MySQL/PostgreSQL zeichnet auch Diagnoseinformationen in den Serverprotokollen auf. Serverprotokolle sind die nativen Nachrichtenprotokolldateien für MySQL und PostgreSQL (nicht die Transaktionsprotokolldateien, auf die in Azure Database for MySQL/PostgreSQL nicht zugegriffen werden kann). Diese Dateien enthalten Meldungen, den Serverstatus und Fehlerinformationen, die Sie zum Debuggen von Problemen mit Ihren Datenbanken verwenden können. Die Serverprotokolle werden bis zu sieben Tage lang aufbewahrt (weniger, wenn die Gesamtgröße der Serverprotokolldateien 7 GB überschreitet).

Azure Database for MySQL und Azure Database for PostgreSQL erfassen unterschiedliche Details in den Serverprotokollen. In den folgenden Abschnitten werden die Serverprotokolle für jeden Dienst separat beschrieben.

Serverprotokolle in Azure Database for MySQL

In Azure Database for MySQL liefert das Serverprotokoll die Informationen, die auf einem MySQL-Server normalerweise im Protokoll für langsame Abfragen und im Überwachungsprotokoll verfügbar sind.

Mithilfe der Informationen im Protokoll für langsame Abfragen können Sie Abfragen ermitteln, deren Ausführung sehr langsam erfolgt. Das Protokoll für langsame Abfragen ist standardmäßig deaktiviert. Sie aktivieren es, indem Sie den Serverparameter slow_query_log auf ON festlegen. Beim Konfigurieren des Protokolls für langsame Abfragen legen Sie mithilfe der folgenden Serverparameter auch fest, was mit langsamer Abfrage gemeint ist:

  • log_queries_not_using_indexes: Dieser Parameter ist entweder ON oder OFF. Legen Sie ihn auf ON fest, um alle Abfragen zu erfassen, bei denen wahrscheinlich eine vollständige Tabellenüberprüfung durchgeführt wird und nicht nur eine Indexsuche.
  • log_throttle_queries_not_using_indexes: Gibt die maximale Anzahl langsamer Abfragen an, die keine Indizes verwenden und die pro Minute protokolliert werden sollen.
  • log_slow_admin_queries: Legen Sie diesen Parameter auf ON fest, um langsame administrative Abfragen in das Protokoll einzubeziehen.
  • long_query_time: Der Schwellenwert (in Sekunden), ab dem die Ausführung einer Abfrage als langsam gilt.

Nachdem Sie das Protokoll für langsame Abfragen und das Überwachungsprotokoll aktiviert haben, werden die Protokolldateien auf der Seite Serverprotokolle für den Server angezeigt. Es wird jeden Tag ein neues Protokoll für langsame Abfragen erstellt. Klicken Sie auf eine Protokolldatei, um sie herunterzuladen:

Image of the Server logs page for Azure Database for MySQL.

Legen Sie den Serverparameter audit_log_enabled auf ON fest, um die Überwachungsprotokollierung zu aktivieren. Sie konfigurieren die Überwachungsprotokollierung mit den folgenden Parametern:

  • audit_log_events: Geben Sie die zu überwachenden Ereignisse an. Im Azure-Portal steht für diesen Parameter eine Dropdownliste mit Ereignissen wie CONNECTION, DDL, DML, ADMIN zur Verfügung.
  • audit_log_exclude_users: Dieser Parameter ist eine durch Trennzeichen getrennte Liste von Benutzern, deren Aktivitäten nicht in das Überwachungsprotokoll einbezogen werden.

Wenn Sie das Protokoll für langsame Abfragen und das Überwachungsprotokoll länger als sieben Tage aufbewahren möchten, können Sie die Übertragung in Azure Storage einrichten. Verwenden Sie die Seite Diagnoseeinstellungen für den Server, und wählen Sie dann + Diagnoseeinstellung hinzufügen aus. Wählen Sie auf der Seite Diagnoseeinstellungen die Option In ein Speicherkonto archivieren und dann ein Speicherkonto aus, in dem die Protokolldateien gespeichert werden sollen (muss bereits vorhanden sein). Wählen Sie MySqlSlowLogs und MySqlAuditLogs aus, und geben Sie eine Beibehaltungsdauer von maximal 365 Tagen an. Sie können die Protokolldateien jederzeit aus Azure Storage herunterladen. Wählen Sie Speichern aus:

Image of the Diagnostic settings page for Azure Database for MySQL.

Die Daten im Protokoll für langsame Abfragen werden im JSON-Format in Blobs in einem Container mit dem Namen insights-logs-mysqlslowlogs geschrieben. Es kann bis zu 10 Minuten dauern, bis die Protokolldateien in Azure Storage angezeigt werden. Überwachungsdatensätze werden ebenfalls im JSON-Format im Blobcontainer insights-logs-mysqlslowlogs gespeichert.

Serverprotokolle in Azure Database for PostgreSQL

In Azure Database for PostgreSQL enthält das Serverprotokoll auch Dateien mit Fehlerprotokoll und Abfrageprotokoll. Verwenden Sie die Informationen in diesen Dateien, um die Quellen von Fehlern und die Ursachen ineffizienter Abfragen zu ermitteln.

Sie aktivieren die Protokollierung, indem Sie die verschiedenen Serverkonfigurationsparameter, die mit log_ beginnen, auf ON festlegen. Diese Parameter umfassen:

  • log_checkpoints: Ein Prüfpunkt wird gesetzt, wenn jede Datendatei mit den neuesten Informationen aus dem Transaktionsprotokoll aktualisiert wurde. Wenn ein Serverfehler auftritt, kennzeichnet dieser Punkt die Zeit, zu der eine Wiederherstellung durch einen Rollforward aus dem Transaktionsprotokoll ausgeführt werden muss.
  • log_connection und log_disconnections: Mit diesen Einstellungen wird festgelegt, dass alle erfolgreichen Verbindungen und das Ende jeder Sitzung aufgezeichnet werden.
  • log_duration: Diese Einstellung bewirkt, dass die Dauer jeder abgeschlossenen SQL-Anweisung aufgezeichnet wird.
  • log_lock_waits: Diese Einstellung bewirkt, dass Sperrwarteereignisse aufgezeichnet werden. Sperrwarteereignisse können durch schlecht implementierte Transaktionen im Anwendungscode verursacht werden.
  • log_statement_stats: Mit dieser Einstellung werden kumulative Informationen zur Leistung des Servers in das Protokoll geschrieben.

Azure Database for PostgreSQL bietet noch weitere Parameter zur Feinabstimmung der aufgezeichneten Informationen:

  • log_error_verbosity: Mit dieser Einstellung wird die Detailtiefe für jede protokollierte Nachricht angegeben.
  • log_retention_days: Dies ist die Anzahl von Tagen, die der Server die einzelnen Protokolldateien aufbewahrt, bevor sie entfernt werden. Der Standardwert ist drei Tage, und Sie können den Wert auf maximal sieben Tage festlegen.
  • log_min_messages und log_min_error_statement: Verwenden Sie diese Parameter, um die Warnungs- und Fehlerebenen für Aufzeichnungsanweisungen anzugeben.

Wie bei Azure Database for MySQL sind die von Azure Database for PostgreSQL generierten Protokolldateien auf der Seite Serverprotokolle verfügbar. Sie können auch die Seite Diagnoseeinstellungen verwenden, um die Protokolle in Azure Storage zu kopieren.

Nachverfolgen der Abfrageleistung

Der Abfragespeicher ist ein zusätzliches Feature von Azure, mit dem Sie Abfragen mit schlechter Leistung identifizieren und nachverfolgen können. Sie können ihn mit Azure Database for MySQL und Azure Database for PostgreSQL verwenden.

Aktivieren der Nachverfolgung der Abfrageleistung

Im Abfragespeicher werden Informationen für Azure Database for MySQL im mysql-Schema und für Azure Database for PostgreSQL in einer Datenbank mit dem Namen azure_sys aufgezeichnet. Im Abfragespeicher können zwei Arten von Informationen erfasst werden: Daten zur Abfrageausführung und Informationen zur Wartestatistik. Der Abfragespeicher ist standardmäßig deaktiviert. So aktivieren Sie es:

  • Wenn Sie Azure Database for MySQL verwenden, legen Sie die Serverparameter query_store_capture_mode und query_store_wait_sampling_capture_mode auf ALL fest.
  • Wenn Sie Azure Database for PostgreSQL verwenden, legen Sie den Serverparameter pg_qs.query_capture_mode auf ALL oder TOP und den Parameter pgms_wait_sampling.query_capture_mode auf ALL fest.

Analysieren der Daten zur Abfrageleistung

Sie können die vom Abfragespeicher verwendeten Tabellen direkt abfragen. Wenn Sie Azure Database for MySQL ausführen, stellen Sie eine Verbindung mit dem Server her und führen die folgenden Abfragen aus:

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

Wenn Sie Azure Database for PostgreSQL verwenden, führen Sie stattdessen die folgenden Abfragen aus:

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

In beiden Fällen wird bei der ersten Abfrage der Text für die zuletzt ausgeführten Abfragen sowie eine Vielzahl von Statistiken darüber angezeigt, wie lange das Kompilieren und Ausführen der Abfrage gedauert hat. Die zweite Abfrage zeigt Informationen zu Warteereignissen an. Ein Warteereignis tritt auf, wenn eine Abfrage nicht ausgeführt werden kann, da sie Ressourcen benötigt, die gerade reserviert sind.

Wenn Sie den Abfragespeicher direkt untersuchen, können Sie eigene benutzerdefinierte Berichte generieren und damit detaillierte Erkenntnisse zur Funktionsweise Ihres Systems gewinnen. Allerdings kann die riesige Menge an verfügbaren Daten es schwierig machen, die Ereignisse zu verstehen. Azure Database for MySQL/PostgreSQL bietet zwei zusätzliche Tools, die Ihnen bei der Navigation in diesen Daten helfen: Query Performance Insight und Abfrageempfehlungen.

Query Performance Insight ist ein grafisches Hilfsprogramm, das auf der Seite Query Performance Insight für Ihren Server verfügbar ist. Auf der Registerkarte Abfragen mit langer Ausführungszeit werden Statistiken zu den Abfragen mit der längsten Ausführungszeit angezeigt. Sie können den Zeitraum angeben und Details für Zeiträume von bis zu wenigen Minuten anzeigen. Die Legende zeigt den Text der einzelnen Abfragen sowie die Dauer und die Häufigkeit, mit der die Abfrage ausgeführt wurde. Das Diagramm bietet eine vergleichende Ansicht der Dauer der einzelnen Abfragen. Sie können die Daten nach der durchschnittlichen Zeit für jede Abfrage anzeigen, es ist aber auch aufschlussreich, die Gesamtzeit (Dauer * Ausführungsanzahl) für jede Abfrage anzuzeigen. In der folgenden Abbildung wird ein Beispiel gezeigt:

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Long running queries tab.

Auf der Registerkarte Wartestatistik werden Informationen zu den Warteereignissen für jede Abfrage angezeigt. Sie erkennen daran, wie lange die jeweilige Abfrage auf verschiedene Ressourcen gewartet hat.

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Wait statistics tab.

Warteereignisse gehören in der Regel zu einer von drei Kategorien:

  • Sperrwarteereignisse: Diese Ereignisse treten auf, wenn eine Abfrage versucht, Daten zu lesen oder zu ändern, die durch eine andere Abfrage gesperrt sind. Wenn eine große Anzahl von Sperrwarteereignissen auftritt, überprüfen Sie, ob zeitintensive Transaktionen oder Vorgänge mit einer stark restriktiven Isolationsstufe ausgeführt werden.
  • E/A-Warteereignisse: Dieser Wartetyp tritt auf, wenn eine Abfrage eine beträchtliche Anzahl an E/A-Vorgängen ausführt. Dies kann an einer nicht optimal entworfenen Abfrage (überprüfen Sie die WHERE-Klausel), einem ineffizienten Joinvorgang oder einer vollständigen Tabellenüberprüfung aufgrund eines fehlenden Index liegen.
  • Speicherwarteereignisse: Ein Speicherwarteereignis tritt auf, wenn nicht genügend Arbeitsspeicher zur Verarbeitung einer Abfrage zur Verfügung steht. Ihre Abfrage könnte versuchen, eine große Datenmenge zu lesen, oder sie wird möglicherweise durch andere Abfragen blockiert, die Arbeitsspeicher belegen. Auch dies kann darauf hindeuten, dass Indizes fehlen und die Abfragen daher ganze Tabellen in den Arbeitsspeicher lesen.

Es ist auch sehr wahrscheinlich, dass ein Warteereignis ein anderes auslöst. Daher können Sie diese Probleme in der Regel nicht isoliert voneinander untersuchen. Beispielsweise könnte eine Transaktion, die Daten in verschiedenen Tabellen liest und aktualisiert, auf Speicher warten. Diese Transaktion könnte wiederum Daten sperren, sodass bei einer anderen Transaktion ein Sperrwarteereignis ausgelöst wird.

Auf der Seite mit den Leistungsempfehlungen für den Server werden die im Abfragespeicher enthaltenen Informationen verwendet, um Empfehlungen zum Optimieren der Datenbank für die ermittelten Workloads zu geben.