Überwachen und Konfigurieren eines Datenbankservers
Nachdem ein Unternehmen seine lokalen Datenbanken zu Azure Database for MySQL/PostgreSQL migriert hat, benötigt es weiterhin eine Möglichkeit, die Leistung zu überwachen.
Als Datenbankentwickler sind Sie es gewohnt, datenbankspezifische Tools und die Überwachung lokaler VMs zu verwenden. Da Ihre Datenbanken nun in Azure ausgeführt werden, können Sie das Portal nutzen, um mit nur einem einzelnen Tool alle unterschiedlichen Datenbanken zu überwachen.
In dieser Lerneinheit erfahren Sie, wie Ihnen Azure Monitor dabei hilft, die Integrität der Datenbanken zu überwachen, für die Sie verantwortlich sind. Außerdem erfahren Sie, wie Sie bei erkannten Problemen die Konfiguration Ihrer Datenbanken ändern, um diese Probleme zu beheben.
Verwenden von Azure Monitor zum Anzeigen der Integrität Ihrer Datenbanken
Sie verwenden Azure Monitor, um den Ressourcenverbrauch in Azure Database for MySQL/PostgreSQL nachzuverfolgen. Die Seite Metriken Ihres Servers im Azure-Portal ermöglicht das Erstellen von Diagrammen, mit denen Sie Leistungstrends und Anomalien erkennen können.
Metriken für Azure Database for MySQL/PostgreSQL
Die verfügbaren Metriken für die Überwachung eines Servers lassen sich in vier allgemeine Kategorien unterteilen:
- Speichermetrik
- Verbindungsmetriken
- Metriken zur Ressourcenverwendung bei der Datenverarbeitung
- Replikationsmetriken
Speichermetrik
Mit Speichermetriken können Sie die Gesamtgröße Ihrer Datenbanken auf dem Server (Verwendeter Speicher) und die aktuelle Menge an Speicherplatz auf dem Server (Speicherlimit) nachverfolgen. Auf einem aktiven System werden Sie sehr wahrscheinlich feststellen, dass die Metrik Verwendeter Speicher im Lauf der Zeit zunimmt. Wenn Sie für den Server die Option für automatische Vergrößerung ausgewählt haben, erhöht sich die Metrik Speicherlimit gelegentlich, wenn die Menge an freiem Speicherplatz abnimmt. Zusätzlicher Speicherplatz wird immer dann hinzugefügt, wenn die Menge an freiem Speicherplatz unter 5 % des aktuellen Verbrauchs sinkt. Verwenden Sie die Metrik Speicher %, um das Verhältnis von genutztem und freiem Speicherplatz auf dem Server anzuzeigen.
Wenn Ihr Server regelmäßig Zeit für das Erhöhen des Speicherplatzes aufbringt, sollten Sie darüber nachdenken, den Speicherplatz manuell zu erhöhen. Wählen Sie hierzu im Azure-Portal die Seite Tarif für Ihren Server aus, und verwenden Sie den Schieberegler Speicher. Denken Sie daran, dass Ihnen der Speicher in Rechnung gestellt wird. Legen Sie daher den verfügbaren Speicher nicht zu hoch fest.
Die Metrik Genutzter Sicherungsspeicher zeigt an, wie viel Speicherplatz Ihre Sicherungen einnehmen. Diese Metrik ist aus Kostengründen wichtig. Der Sicherungsspeicher wird Ihnen nicht in Rechnung gestellt, solange er unter der Größe des Speicherplatzes liegt, der dem Server zugewiesen ist (wie im Tarif angegeben). Wenn Sie diesen Grenzwert überschreiten, fallen Gebühren für den Sicherungsspeicher an.
Verbindungsmetriken
Die Metrik Aktive Verbindungen zeigt an, wie viele gleichzeitige Verbindungen der Server zurzeit unterstützt. Dieser Wert ist möglicherweise nicht mit der Anzahl gleichzeitiger Benutzer identisch. Dies hängt davon ab, ob Sie eine Form von Verbindungspooling konfiguriert haben. Azure Database for MySQL/PostgreSQL bietet derzeit keine Funktion für das Verbindungspooling. Sie können jedoch einen Proxydienst wie PgBouncer* (für PostgreSQL) verwenden, um diese Funktion zu implementieren. Weitere Informationen finden Sie unter Performance best practices for using Azure Database for PostgreSQL – Connection Pooling (Bewährte Methoden für die Leistung von Azure Database for PostgreSQL – Verbindungspooling).
Die Metrik Verbindungsfehler zeigt an, wie oft Benutzer ungültige Anmeldeinformationen angegeben haben. Wenn diese Ereignisse über einen kurzen Zeitraum sehr häufig auftreten, kann dies auf einen Brute-Force-Angriff hindeuten.
Metriken zur Ressourcenverwendung bei der Datenverarbeitung
Mit diesen Metriken können Sie überwachen, wie der Server die Workload verarbeitet.
Die Metrik CPU % zeigt an, wie ausgelastet die CPU ist. Eine hohe CPU-Auslastung ist kein Problem, es sei denn, sie ist im Lauf der Zeit gestiegen. Eine CPU-Auslastung von über 90 %, die weiterhin steigt, deutet darauf hin, dass sich Ihr System der maximalen Verarbeitungskapazität nähert. Sie sollten in diesem Fall eine Hochskalierung auf einen Tarif mit mehr Ressourcen in Erwägung ziehen.
Die Metrik Arbeitsspeicher % gibt die Arbeitsspeicherauslastung an. Azure Database for MySQL/PostgreSQL nutzt den Arbeitsspeicher zum Zwischenspeichern von Daten und zum Ausführen der von den einzelnen Clientanforderungen initiierten Prozesse. Ein Problem tritt erst bei einer übermäßigen Arbeitsspeicherauslastung auf. Diese liegt in der Regel bei über 95 % und ist von der tatsächlichen Menge an verfügbarem Arbeitsspeicher abhängig. Eine sehr geringe Verfügbarkeit an Arbeitsspeicher kann aufgrund der Speicherfragmentierung zu Verbindungsfehlern und einer langsamen Leistung führen. Sie sollten diese Metrik überwachen, um festzustellen, ob die Arbeitsspeicherauslastung im Lauf der Zeit zunimmt, und den Server entsprechend skalieren zu können.
Die Metrik E/A % verfolgt die Menge der Datenträgeraktivitäten, die vom Server ausgeführt werden. Dieser Wert sollte idealerweise möglichst klein sein. Datenträger-E/A-Vorgänge sind langsam. Ein hoher Wert bei dieser Metrik kann zusammen mit einem hohen Wert für Arbeitsspeicher % darauf hindeuten, dass der Server nicht über genügend Ressourcen verfügt, um Daten effektiv zwischenzuspeichern, und stattdessen Daten über den Datenträgerspeicher lesen und schreiben muss. Ein gewisses Maß an E/A-Aktivität ist unvermeidlich, da Ihre Daten irgendwann auf dem Datenträger persistent gespeichert und die Transaktionsprotokolle verwaltet werden müssen. Bei den meisten Datenbankservern erfolgt dieser Schreibvorgang über einen separaten Prozess oder Thread, der asynchron ausgeführt wird.
Die Metriken Netzwerk eingehend und Netzwerk ausgehend zeigen das Datenverkehrsvolumen an, das der Server über aktive Verbindungen empfängt oder sendet. Die Grenzwerte für diese Metriken werden durch die Bandbreite entlang des Pfads zwischen den Clientanwendungen und dem Server bestimmt.
Replikationsmetriken
Azure Database for PostgreSQL bietet die Metriken Max Lag Across Replicas (Maximale Verzögerung zwischen Replikaten) und Replikatverzögerung, mit denen Sie bestimmen können, wie aktuell Replikate sind. Diese Metriken sind nur dann aussagekräftig, wenn Sie schreibgeschützte Replikate konfiguriert haben.
Die Metrik Max Lag Across Replicas (Maximale Verzögerung zwischen Replikaten) zeigt an, wie viele Bytes das langsamste Replikat hinter dem Master liegt. Sie können diese Metrik nur vom Master aus überwachen.
Die Metrik Replikatverzögerung zeigt die Zeit in Sekunden an, seit die letzte Transaktion vom Master empfangen und auf ein Replikat angewandt wurde. Diese Metrik ist nur bei der Anzeige auf einem Replikat sinnvoll.
Azure Database for MySQL bietet die Metrik Replication lag in seconds (Replikationsverzögerung in Sekunden). Diese Metrik, die Sie nur von einem Replikat aus überwachen können, zeigt die Anzahl der Sekunden an, die das Replikat hinter dem Master zurückliegt.
Erstellen von Diagrammen und Warnungen zum Überwachen der Leistung
Sie können im Azure-Portal auf der Seite Metriken für einen Server Diagramme erstellen, mit denen Metrikwerte nachverfolgt werden. Metriken werden in Intervallen von einer Minute erfasst. Sie geben für jede Metrik eine Aggregation an, die bestimmt, wie diese Metrik gemeldet wird.
- Average generiert jede Minute einen Durchschnittswert für die Metrik.
- Max zeigt den maximalen Wert an, der in jeder Minute erreicht wurde.
- Min zeigt den kleinsten Wert an.
- Sum zeigt die Summe der Metrik an.
- Count zeigt an, wie oft das Ereignis, das die Metrik erzeugt, aufgetreten ist.
Nicht alle Aggregationen sind für jede Metrik sinnvoll.
Im folgenden Beispieldiagramm wurden die Metriken für den CPU-Prozentsatz, den Arbeitsspeicherprozentsatz, den E/A-Prozentsatz und die aktiven Verbindungen auf Minutenbasis aufgezeichnet. Sie sehen, dass 101 aktive Verbindungen gleichzeitig ausgeführt werden. CPU- und Arbeitsspeicherauslastung sind stabil, und der E/A-Prozentsatz beträgt 0. In diesem Beispiel führen die Clientanwendungen leseintensive Workloads aus, und die erforderlichen Daten werden im Arbeitsspeicher zwischengespeichert.
Beachten Sie, dass zwischen dem Aufzeichnen der Metriken und dem Anzeigen der Ergebnisse in einem Diagramm eine Verzögerung von bis zu fünf Minuten auftritt.
Wenn eine Metrik anzeigt, dass eine Ressource einen kritischen Punkt erreicht, können Sie eine Warnung festlegen, um einen Administrator zu benachrichtigen. Im folgenden Beispiel wird eine E-Mail an einen Administrator gesendet, wenn die Arbeitsspeicherauslastung 90 % überschreitet.
Konfigurieren von Serverparametern
Native MySQL- und PostgreSQL-Server bieten sehr viele Konfigurationsmöglichkeiten, da beide Konfigurationseinstellungen verwenden, die in Parameterdateien gespeichert werden. Für PostgreSQL werden diese Informationen in der Datei postgresql.conf gespeichert. Für MySQL werden die Konfigurationsdaten in verschiedenen Dateien mit dem Namen my.cnf gespeichert. In Azure Database for MySQL/PostgreSQL haben Sie keinen direkten Zugriff auf diese Dateien. Stattdessen können Sie Serverparameter über das Azure-Portal oder mithilfe der Azure-Befehlszeilenschnittstelle anzeigen und ändern.
Anzeigen und Festlegen von Parametern über das Azure-Portal
Sie finden die Serverkonfigurationsparameter im Azure-Portal auf der Seite Serverparameter für Ihren Server. Sie können die Parameterwerte entsprechend Ihrem Server ändern. Die folgende Abbildung zeigt die Seite „Serverparameter“ für Azure Database for PostgreSQL. Die entsprechende Seite für Azure Database for MySQL ist dieser sehr ähnlich.
Es sind nicht alle Serverkonfigurationsparameter verfügbar, da ein großer Teil der Serverkonfiguration von Azure gesteuert wird. Beispielsweise fehlen Parameter für die Arbeitsspeicherzuteilung. Darüber hinaus unterstützt Azure Database for MySQL keine ISAM-Speicher, daher fehlen die myisam-Parameter.
Änderungen an Parametern, die als Dynamisch gekennzeichnet sind, treten sofort in Kraft. Für Parameter, die als Statisch gekennzeichnet sind, müssen Sie den Server neu starten. Dies führen Sie auf der Seite Übersicht für Ihren Server durch.
Anzeigen und Festlegen von Parametern mithilfe der Azure-Befehlszeilenschnittstelle
Sie können Parameter auch programmgesteuert mit den Befehlen az mysql/postgres server configuration anzeigen und ändern. Zeigen Sie die Einstellungen aller Konfigurationsparameter mit az mysql/postgres server configuration list an, und verwenden Sie für einen einzelnen Parameter az mysql/postgres server configuration show [parameter-name]. Der folgende Codeausschnitt zeigt ein Beispiel für Azure Database for PostgreSQL:
az postgres server configuration show \
--resource-group northwindrg \
--server-name northwind101 \
--name vacuum_defer_cleanup_age
Das Ergebnis sollte dem folgenden ähneln:
{
"allowedValues": "0-1000000",
"dataType": "Integer",
"defaultValue": "0",
"description": "Number of transactions by which VACUUM and HOT cleanup should be deferred, if any.",
"id": "**********************",
"name": "vacuum_defer_cleanup_age",
"resourceGroup": "northwindrg",
"source": "system-default",
"type": "Microsoft.DBforPostgreSQL/servers/configurations",
"value": "0"
}
Das wichtige Element in der Ausgabe ist das Feld value (Wert), das die aktuelle Einstellung für den Parameter anzeigt.
Verwenden Sie den Befehl az mysql/postgres server configuration set wie folgt, um den Wert eines Konfigurationsparameters zu ändern:
az postgres server configuration set \
--resource-group northwindrg \
--server-name northwind101 \
--name vacuum_defer_cleanup_age \
--value 5
Wenn Sie einen Server neu starten müssen, nachdem Sie einen statischen Parameter geändert haben, führen Sie den folgenden Befehl az mysql/postgres server restart aus:
az postgres server restart \
--resource-group northwindrg \
--name northwind101