Welche Metriken Ihrer PostgreSQL-Bereitstellung sollten Sie überwachen? Diese Reihe von Blog-Beiträgen zielt darauf ab, einen minimalen Anfangssatz an wesentlichen Überwachungsmaßnahmen bereitzustellen, die Sie implementieren sollten, um den Zustand und die Stabilität Ihrer Postgres-Server sicherzustellen.
Der erste Teil behandelt Parameter auf Clusterebene.
Teil 1:Clusterebene
Im Postgres-Jargon ein Cluster ist eine Reihe von Datenbanken, die von einer einzelnen Postgres-Serverinstanz verwaltet werden. Funktionen wie Replikation und WAL-Archivierung funktionieren auf Cluster-Ebene.
1. Transaktions-ID-Bereich
Aus der Sicht eines normalen Clients scheinen die Datendateien eines PostgreSQL-Clusters den Snapshot der Daten zu enthalten, wie sie durch die letzte festgeschriebene Transaktion geändert wurden. Aufgrund der MVCC-Architektur von Postgres enthalten die physischen Dateien jedoch nicht nur die Daten für die letzte Transaktion, sondern für eine Reihe von Transaktionen, die mit der neuesten enden. (Regelmäßiges Staubsaugen entfernt die Daten für die älteren Transaktionen.)
Jede Transaktion hat eine eindeutige 32-Bit-Ganzzahlkennung, die als Transaktions-ID bezeichnet wird . Aus verschiedenen Gründen sollte die Differenz zwischen der ersten und der letzten Transaktions-ID weniger als 2 betragen, was ungefähr 2 Milliarden entspricht. Der Bereich muss deutlich unter dieser Grenze gehalten werden, muss – Lesen Sie diese wahre Geschichte darüber, was sonst passiert.
Aktion:Kontinuierliche Überwachung des Transaktions-ID-Bereichs, Warnung, wenn der Wert einen festgelegten Schwellenwert überschreitet.
Vorgehensweise:
-- returns the first and last transactions IDs for the cluster
SELECT oldest_xid::text::int as first,
regexp_replace(next_xid, '^[0-9]+:', '')::int-1 as last
FROM pg_control_checkpoint();
-- returns the transaction ID range for each database
SELECT datname, age(datfrozenxid)
FROM pg_database;2. Anzahl der Backends
Jedes Backend repräsentiert entweder einen Client, der mit dem Server verbunden ist, oder einen Systembackend-Prozess (wie Auto Vacuum Worker, Background Writer usw.). Jedes Backend ist auch ein Betriebssystemprozess, der Betriebssystemressourcen wie Speicher, offene Dateideskriptoren usw. verbraucht. Zu viele Backends, typischerweise aufgrund zu vieler Clients oder zu vieler lang laufender Abfragen, können die Betriebssystemressourcen unter Druck setzen und die Antwortzeiten für Abfragen für jeden Client verlangsamen. P>
Maßnahme:Überwachen Sie die maximale Backend-Anzahl jeden Tag/jede Woche, untersuchen Sie zunehmende Trends.
Vorgehensweise:
-- returns the count of currently running backends
SELECT count(*)
FROM pg_stat_activity;3. Inaktive Replikationsslots
Replikationsslots werden als „inaktiv“ markiert, wenn der mit dem Slot verbundene Replikationsclient die Verbindung trennt. Inaktive Replikationsslots führen dazu, dass WAL-Dateien beibehalten werden, da sie an den Client gesendet werden müssen, wenn er sich wieder verbindet und die Slots aktiv werden. In der Tat ist das erste, was Sie überprüfen sollten, ob Ihre WAL-Dateianzahl nicht sinkt, zu sehen, ob Sie inaktive Replikationsslots haben.
Häufig sind inaktive Replikationsslots das Ergebnis eines entfernten Backup-Clients, eines abgeschalteten Slaves, von Beförderungen, Failovers und dergleichen.
Maßnahme:Kontinuierlich nach inaktiven Replikationsslots suchen, ggf. warnen.
Vorgehensweise:
-- returns the count of inactive replication slots
SELECT count(*)
FROM pg_replication_slots
WHERE NOT active;4. Backends warten auf Sperren
SQL-Anweisungen können explizit oder implizit bewirken, dass andere SQL-Anweisungen warten. Wenn Sie beispielsweise „SELECT .. FOR UPDATE“ ausführen, wird explizit eine Sperre für die ausgewählten Zeilen deklariert, und die Ausführung von „UPDATE“ platziert implizit zeilenexklusive Sperren Wenn Sie auf die Sperre stoßen, müssen Sie warten, bis die erste Anweisung die Sperre aufgibt, bevor sie mit der Ausführung fortfahren kann.
Dies kann sich in einer langsamen Anwendungsleistung bei wöchentlichen Berichtsausführungen, Zeitüberschreitungen bei Transaktionen/Webseiten und dergleichen äußern.
Während ein gewisses Maß an Sperren nicht vermieden werden kann, erfordert ein zunehmender Trend von Backends, die auf Sperren warten, typischerweise eine Neustrukturierung von Abfragen oder Anwendungslogik.
Maßnahme:Überwachen Sie die maximale Anzahl von Back-Ends, die auf Sperren warten, über jeden Tag/Woche, untersuchen Sie zunehmende Trends.
Vorgehensweise:
-- returns the count of backends waiting on locks
SELECT count(*)
FROM pg_stat_activity
WHERE wait_event = 'Lock';5. Backends im Leerlauf in Transaktion
Transaktionen mit langer Laufzeit sind in der PostgreSQL-Welt nicht sehr angenehm. Sie können dazu führen, dass sich WAL-Dateien aufbauen, eine automatische und manuelle Bereinigung verhindern und Ressourcen verbrauchen. Gegen echte Transaktionen, die lange dauern, kann nicht viel getan werden, aber es gibt Fälle wie sich schlecht verhaltende Apps/Skripte und gelegentliche PSQL-Clients, die Transaktionen starten, aber nicht schließen. Back-Ends, die solche Clients bedienen, werden als „in Transaktion im Leerlauf“ angezeigt.
Backends, die sich in einer Transaktion befinden, sollten erkannt und heruntergefahren werden, bevor sie die Systemstabilität beeinträchtigen.
Maßnahme:Überwachen Sie kontinuierlich die Anzahl der Backends, die sich in der Transaktion befinden, und überprüfen Sie, ob welche gefunden werden.
Vorgehensweise:
-- returns the count of backends waiting on locks
SELECT count(*)
FROM pg_stat_activity
WHERE state = 'idle in transaction';6. Replikationsverzögerung für aktive Verbindungen
Wenn aktive Streaming-Replikationsclients (wie Hot-Standbys) oder aktive logische Replikationsclients vorhanden sind, führt Postgres ein System-Back-End namens WAL-Sender aus für jeden aktiven (verbundenen) Client. Der WAL-Sender ist dafür verantwortlich, die WAL-Eintragsdaten zu senden, die der Client benötigt.
Replikationsclients versuchen normalerweise, so weit wie möglich mit dem Primärserver Schritt zu halten. Manchmal jedoch kann die WAL-Erzeugungsrate auf der Primärseite höher werden als die Rate, mit der der Client sie verbrauchen kann. Dies führt zu einer Replikationsverzögerung für jede Replikationsverbindung.
PostgreSQL bietet einen Mechanismus zum Abfragen von Schreibverzögerung (Anzahl der Bytes, die gesendet, aber nicht auf die Festplatte des Clients geschrieben wurden), Flush-Verzögerung (Anzahl der Bytes, die geschrieben, aber nicht auf die Festplatte des Clients geleert wurden) und Wiedergabeverzögerung (Anzahl der Bytes, die geleert, aber nicht auf die Festplatte des Clients zurückgespielt wurden). Datenbankdateien) für jeden aktiven WAL-Sender.
Maßnahme:Kontinuierliche Überwachung von Replikationsverzögerungen auf aktive Verbindungen, Warnung, wenn Werte festgelegte Schwellenwerte überschreiten.
Vorgehensweise:
-- returns the write, flush and replay lags per WAL sender, as described above
SELECT write_lsn - sent_lsn AS write_lag,
flush_lsn - write_lsn AS flush_lag,
replay_lsn - flush_lsn AS replay_lag
FROM pg_stat_replication;7. Replikationsverzögerung für Replikationsslots
Replikationsclients können nicht nur verzögern, sondern aufgrund von Abstürzen, Topologieänderungen oder menschlichem Versagen auch ganz verschwinden. Es kann auch beabsichtigt sein, dass Clients nicht immer online sind.
Wenn der Client von einem Replikationsslot unterstützt wird, werden alle WAL-Dateien, die der Client benötigt, um an der Stelle fortzufahren, an der er aufgehört hat, von PostgreSQL beibehalten. Die WAL-Dateien werden auf unbestimmte Zeit aufbewahrt – es gibt keine Möglichkeit, ein Limit festzulegen. Wenn der Client die Verbindung wieder herstellt, müssen alle aufbewahrten Daten zuerst an den Client gestreamt werden, was viel Festplatten- und Netzwerkverkehr auf dem primären Client verursachen kann. Aus diesen Gründen sollten Sie die Verzögerung auch auf Slot-Ebene überwachen.
(Hinweis:Der WAL-Sender-Prozess wird nur ausgeführt, wenn ein Client verbunden ist, und er wird beendet, wenn der Client die Verbindung trennt. Die WAL-Sender-Methode zum Messen, wie weit ein Client zurückliegt, funktioniert nicht, wenn ein Client getrennt ist.)
Maßnahme:Kontinuierliche Überwachung von Replikationsverzögerungen für logische Replikationsslots, Warnung, wenn Werte einen festgelegten Schwellenwert überschreiten.
Vorgehensweise:
-- returns the replication slot lag in bytes
-- (works only for logical replication slots)
SELECT pg_current_wal_lsn() - confirmed_flush_lsn
FROM pg_replication_slots;8. Anzahl der WAL-Dateien
Das Verwalten von WAL-Dateien kann eine ärgerliche Aufgabe sein, insbesondere wenn Sie WAL-Archivierungs- oder Streaming-Replikationsclients haben. Die Anzahl der WAL-Dateien kann ohne ersichtlichen Grund ansteigen, der WAL-Archivierungsprozess kann mit der WAL-Generierungsrate nicht Schritt halten, und die Gesamtgröße der WAL-Dateien kann in den Terabyte-Bereich gehen.
Sie müssen zumindest die Anzahl der in Ihrem Datenbankverzeichnis vorhandenen WAL-Dateien überwachen und sicherstellen, dass die Anzahl für Ihre Bereitstellung angemessen erscheint.
Maßnahme:Kontinuierliche Überwachung der Anzahl der WAL-Dateien, Warnung, wenn der Wert einen festgelegten Schwellenwert überschreitet.
Vorgehensweise:
-- returns the number of WAL files present in the pg_wal directory (v10+)
SELECT count(*)
FROM pg_ls_waldir();
-- same, for v9.x
SELECT count(*)
FROM pg_ls_dir('pg_xlog')
WHERE pg_ls_dir ~ '^[0-9A-F]{24}$';
-- can also count the files physically present in $DBDIR/pg_wal
-- /bin/ls -l $DBDIR/pg_wal | grep -c '^-'9. Anzahl der archivierbaren WAL-Dateien
Wenn die WAL-Archivierung aktiviert ist, ruft PostgreSQL jedes Mal ein Benutzerskript auf, wenn eine neue WAL-Datei generiert wird. Das Skript soll die einzelne WAL-Datei, für die es aufgerufen wurde, „archivieren“ (normalerweise kopiert es sie auf einen anderen Server oder einen S3-Bucket). archiviert werden.
Maßnahme:Kontinuierliche Überwachung der Anzahl der archivierungsbereiten WAL-Dateien, Warnung, wenn der Wert einen festgelegten Schwellenwert überschreitet.
Vorgehensweise:
-- returns the number of WAL files ready to be archived (v12+)
SELECT count(*)
FROM pg_ls_archive_statusdir()
WHERE name ~ '^[0-9A-F]{24}.ready$';
-- same, for v10+
SELECT count(*)
FROM pg_ls_dir('pg_wal/archive_status')
WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';
-- same, for v9.x
SELECT count(*)
FROM pg_ls_dir('pg_xlog/archive_status')
WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';
-- can also count the *.ready files physically present in $DBDIR/pg_wal/archive_status
-- /bin/ls -l $DBDIR/pg_wal/archive_status | grep -c .readyErfassen dieser Metriken
Die obigen Abschnitte enthalten SQL-Anweisungen zum Extrahieren der erforderlichen Metriken von einem laufenden Postgres-Server. Wenn Sie die Skripte lieber nicht selbst schreiben möchten, sehen Sie sich das Open-Source-Tool pgmetrics an. Es kann die oben genannten Metriken und mehr erfassen und sie im Text- und JSON-Format melden.
Sie können die pgmetrics-Berichte direkt an unser kommerzielles Angebot, pgDash, senden, das diese Berichte speichert und verarbeitet, um Diagramme anzuzeigen und Warnungen auszuführen.
Als Nächstes
Weitere Teile dieser Reihe behandeln Metriken auf Datenbankebene, Tabellenebene, Indexebene und Systemebene. Bleiben Sie dran!
