Überwachen (Monitoring)

Voraussetzungen

• Sie haben eine STACKIT PostgreSQL Flex Instanz erstellt. Prüfen Sie Erstellen und Verwalten von Instanzen.
• Sie haben einen STACKIT Observability Managed Service konfiguriert und dieser ist in Betrieb. Prüfen Sie Ihre erste Observability-Instanz erstellen und konfigurieren.
• Oder Sie haben einen STACKIT Metrics Managed Service konfiguriert und dieser ist in Betrieb.

Einführung

Monitoring und Observability in Kombination mit Ihrer Datenbank sind entscheidend, um eine gute Customer Experience zu bieten und Ihre eigenen SLAs gegenüber Ihren Kunden nachzuweisen. Mit STACKIT Observability bietet STACKIT einen Managed Service an, der Observability und Monitoring abdeckt. Lesen Sie das Kapitel über Observability, um zu erfahren, wie Sie den Managed Service nach Ihren Bedürfnissen konfigurieren.

Dieser Artikel folgt dem Paradigma, dass Sie Monitoring mit Schwellenwerten für bestimmte Metriken verwenden, um Situationen zu erkennen, die Ihre Aufmerksamkeit erfordern, und Observability nutzen, um zu analysieren, wie Sie Maßnahmen ergreifen können.

Zugriff auf die Metriken

Das Portal verwenden

PostgreSQL Flex bietet mehrere Metriken direkt im STACKIT Portal an. Dies ist ein zusätzlicher vorkonfigurierter Service und läuft parallel zu einer optionalen selbstkonfigurierten Observability-Instanz.

Befolgen Sie diese Schritte, um auf die Metriken zuzugreifen:

1. Klicken Sie in der Seitenleiste auf PostgreSQL Flex.

2. Klicken Sie auf die Instanz, für die Sie auf die Metriken zugreifen möchten.

3. Klicken Sie in der Seitenleiste auf Metrics.

Wenn Sie Logs und Traces benötigen, um Ihr PostgreSQL Flex Problem weiter zu analysieren, müssen Sie die Telemetrie an eine Observability-Instanz übertragen.

Das Panel zeigt die aktuelle Auslastung der wichtigsten Ressourcen aller Knoten. Konsultieren Sie Metriken, um eine Vorstellung von der Bedeutung der Metriken zu bekommen.

Observability verwenden, um potenzielle Probleme mit Ihrem PostgreSQL Flex Service zu analysieren und zu lösen

Unabhängig davon, ob Sie die interne Observability-Lösung von STACKIT oder ein externes Tool verwenden, müssen Sie das Scraping manuell konfigurieren. Fügen Sie Ihrer Prometheus-Instanz einen Scraper hinzu und fahren Sie dann fort, indem Sie ein Dashboard in STACKIT Grafana hinzufügen, um die Metriken zu visualisieren, an denen Sie interessiert sind. Eine Liste der verfügbaren Metriken finden Sie unter Metriken.

Interpretation der Metriken

Die Metriken und Schwellenwerte sind wichtige Werkzeuge zur Wartung Ihrer Instanz. Neben dem Nachweis gegenüber Ihren Kunden, dass Ihre SLAs eingehalten werden, erhalten Sie wichtige Informationen für das Sizing Ihrer Instanz. Es ist Best Practice, die Alarmschwellenwerte zwischen 60 % und 80 % festzulegen, abhängig von Ihrer Risikoaffinität und Reaktionszeit.

Bevor Sie mehr Ressourcen zuweisen, versuchen Sie zuerst, Ihre Datenbank und Abfragen zu optimieren. Es gibt mehrere Muster in den Metriken, die Ihnen Hinweise auf Optimierungspotenziale geben. Lesen Sie die Performance-Tipps von PostgreSQL, um zu erfahren, wie Sie diese Muster erkennen und die Ursachen beheben können.

Wenn Sie sicher sind, dass Sie mehr Ressourcen benötigen, nutzen Sie ebenfalls die Metriken. Für jeden Instanztyp (Single und Replica) gibt es drei Parameter, welche die zugewiesenen Ressourcen steuern: Instanztyp, Performance-Klasse und Flavor.

Datenbankgröße

Wenn die Metrik Disk Util % über 80 % steigt, ist es Best Practice, die Performance-Größe zu erhöhen.

Performance-Klasse

Wenn Sie Performance-Probleme beim Speicher analysieren, müssen Sie zwischen zwei Parametern unterscheiden: IOPS und Festplattenbandbreite. Ersterer ist wichtiger für interne Datenbankaufgaben und die Verarbeitung vieler kleiner Abfragen, letzterer ist wichtig, wenn Sie große Bulk-Dateien mit Ihren Abfragen bedienen.

Wenn die Metrik Disk IOPS 80 % der IOPS Ihres Performance-Klasse-Plans erreicht, ist es Best Practice, auf eine Instanz mit einer höheren Performance-Klasse zu klonen. Lesen Sie Flavors und Leistungsklassen, um nachzuschlagen, welcher Plan über wie viele IOPS verfügt.

Wenn die Metrik Disk Util % dauerhaft 60 % erreicht, sollten Sie ein Upgrade der Performance-Klasse in Betracht ziehen.

Ineffiziente Abfragen können ebenfalls hohe Disk IOPS und Disk Util verursachen. Ziehen Sie immer eine Abfrageanalyse in Betracht, bevor Sie mehr Ressourcen zuweisen.

Flavor

PostgreSQL ist stark auf Speicher angewiesen. Als Faustregel sollte Ihr RAM etwa 60 % Ihres PostgreSQL DB Storage entsprechen. Mit dem Parameter Flavor können Sie Ihrer Instanz mehr Speicher- und CPU-Ressourcen zuweisen.

Bei der Interpretation von Speichermetriken können Sie sich auf den Parameter Speicher verlassen. Wenn dieser dauerhaft über 80 % liegt, sollten Sie ein Upgrade des Flavor in Betracht ziehen.

Um den Bedarf an CPUs zu analysieren, überwachen Sie den Parameter CPU. Wenn dieser dauerhaft über 80 % liegt, sollten Sie ein Upgrade des Flavor in Betracht ziehen.

Ineffiziente Abfragen können ebenfalls eine hohe CPU-Auslastung verursachen. Ziehen Sie immer eine Abfrageanalyse in Betracht, bevor Sie mehr Ressourcen zuweisen.