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.
Dies ist der zweite Teil einer Blogserie und behandelt Parameter auf Datenbankebene. Der erste behandelte Parameter auf Clusterebene.
Teil 2:Datenbankebene
In diesem Teil sehen wir uns Metriken und Informationen an, die für jede wichtige Datenbank, die Sie verwenden, überwacht werden sollten.
Die meisten der unten aufgeführten SQL-Abfragen sollten ausgeführt werden, während Sie mit der betreffenden Datenbank verbunden sind.
1. Verbundene Clients
Verbundene Clients verbrauchen Betriebssystem- und Systemressourcen. Postgres hat eine Prozess-pro-Client-Architektur, und zu viele Clients können die Antwortzeiten für Abfragen für alle verlangsamen. Erwägen Sie die Verwendung von PgBouncer orpgpool, um die Anzahl der Verbindungen zu reduzieren, die der Postgres-Server bedienen muss.
Behalten Sie Änderungen der Baseline nach Anwendungsaktualisierungen und Verbindungsspitzen aufgrund von erhöhtem Datenverkehr im Auge.
Maßnahme:Überwachen Sie die maximale Anzahl verbundener Clients jeden Tag/jede Woche, untersuchen Sie Trendänderungen.
Vorgehensweise:
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. Größe
Die tatsächliche Festplattengröße, die von der Datenbank verwendet wird, muss überwacht werden. In den meisten Fällen wächst die Datenbankgröße weiter, daher ist die Wachstumsrate interessanter. Seien Sie erneut vorsichtig mit einer erhöhten Wachstumsrate nach neuen Anwendungsversionen.
Maßnahme:Überwachen Sie das Wachstum der Größe der Datenbank über jede Woche/jeden Monat, untersuchen Sie Trends, stellen Sie sie erneut bereit.
Vorgehensweise:
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. Tabellenaufblähung in allen Tabellen
Aufgrund der MVCC-Architektur von Postgres liegen ältere Versionen von Zeilen in den physischen Datendateien für jede Tabelle herum und werden als bloat bezeichnet . Die Operation zum Löschen veralteter Zeilenversionen wird vacuum genannt . Postgres führt einen Hintergrundprozess namens autovacuum aus , das Kandidatentabellen (basierend auf konfigurierbaren Parametern) aufnimmt und sie für Sie leert.
Bloat verlangsamt Tabellenoperationen und verschwendet Speicherplatz und kann sogar mit Autovacuum davonlaufen. Die Überwachung des Aufblähens als absolute Anzahl von Bytes sowie als Prozentsatz (von toten Daten zu Gesamtdaten) ist erforderlich. Dies kann auf Datenbankebene als Summe über alle Tabellen erfolgen, mit der Möglichkeit, in die „aufgeblähtesten Tabellen“ einzudringen.
Maßnahme:Kontinuierliches Überwachen der gesamten Aufblähung als Byte und Prozentsatz, Warnung, wenn Werte einen festgelegten Schwellenwert überschreiten.
Vorgehensweise:
Verwenden Sie check_postgres orpgmetrics, um aufgeblähte Schätzungen zu erhalten. Weitere Informationen finden Sie im Wiki.
4. Indexaufblähung über alle Indizes
Aufgeblähte Indizes können Einfügungen verlangsamen und die Suchleistung verringern. Überwachen Sie das Aufblähen von Indizes sowohl als absoluten Wert (Anzahl Bytes) als auch als Prozentsatz. Indizes müssen neu erstellt werden, wenn sie zu aufgebläht werden.
Maßnahme:Kontinuierliches Überwachen der gesamten Aufblähung als Byte und Prozentsatz, Warnung, wenn Werte einen festgelegten Schwellenwert überschreiten.
Vorgehensweise:
Verwenden Sie check_postgres orpgmetrics, um aufgeblähte Schätzungen zu erhalten. Weitere Informationen finden Sie im Wiki.
5. Transaktionen mit langer Laufzeit
Zu lange geöffnete Transaktionen sind keine guten Nachrichten für PostgreSQL. Lang andauernde Transaktionen können dazu führen, dass WAL-Dateien zurückbehalten werden, Sperren hängen bleiben und ein Vakuum verhindern. Anwendungen sollten so gestaltet sein, dass die Transaktionsdauer so gering wie möglich gehalten wird.
Ein Backend, das eine lange laufende Transaktion ausführt, kann mit pg_cancel_backend() beendet werden und pg_terminate_backend() Funktionen.
Maßnahme:Kontinuierliche Überwachung der Anzahl von Transaktionen, die länger als eine festgelegte Zeitdauer ausgeführt wurden, Warnung, wenn Werte einen festgelegten Schwellenwert überschreiten.
Vorgehensweise:
-- returns the count of transactions that have been running for more than a day
SELECT count(*)
FROM pg_stat_activity
WHERE xact_start < now() - '24 hours'::interval;6. Deadlocks
In PostgreSQL platzieren Backends implizit Sperren auf Zeilen und Tabellen, wenn Abfragen ausgeführt werden, die Zeilen ändern. Abfragen können auch explizite Sperren setzen (wie SELECT .. FOR UPDATE ). Genau wie bei der Multithread-Programmierung können zwei Transaktionen, die entweder implizit oder explizit Sperren in entgegengesetzter Reihenfolge platzieren, zu einem Deadlock führen.
PostgreSQL erkennt Deadlocks und setzt eine der beteiligten Transaktionen zurück (alle von einer Transaktion gehaltenen Sperren werden aufgehoben, wenn sie festgeschrieben oder zurückgesetzt wird). Details werden im PostgreSQL-Protokollierungsziel protokolliert.
Anwendungen sollten so entworfen werden, dass die Möglichkeit eines Deadlocks vermieden wird. Sie können sich auch dafür entscheiden, eine Transaktion im Falle eines Deadlocks erneut zu versuchen.
Maßnahme:Überwachen Sie die Anzahl der Deadlocks über jeden Tag/Woche, gestalten Sie die Anwendung neu, um die Anzahl zu reduzieren, untersuchen Sie Änderungen.
Vorgehensweise:
Das Auftreten von Deadlocks wird zusammen mit zusätzlichen Informationen in der PostgreSQL-Protokolldatei protokolliert. Verwenden Sie pgmetrics, pgbadger oder andere PostgreSQL-spezifische Protokollverarbeitungstools, um diese Informationen zu extrahieren.
7. Ältester Staubsauger
Das regelmäßige Staubsaugen von Tischen, entweder mit Autovakuum oder mit geplanten Jobs oder manuell, ist ein Muss, um den Tischbetrieb schnell zu halten. Staubsauger können jedoch aus verschiedenen Gründen fehlschlagen, einschließlich lang andauernder Transaktionen, inaktiver Replikationsslots usw.
Da das regelmäßige Staubsaugen von Tischen in der Postgres-Welt sehr wichtig ist, ist es am besten, regelmäßig zu überprüfen, ob alle Tische mindestens einmal in einem festgelegten Intervall gesaugt wurden.
Und obwohl sie dazu neigen, aus den Augen und aus dem Sinn zu verschwinden, sollten auch die Katalogtabellen des Systems gesaugt werden.
Maßnahme:Kontinuierlich prüfen, ob ein Tisch in der letzten festgelegten Anzahl von Stunden/Tagen nicht gesaugt wurde, ggf. Benachrichtigung.
Vorgehensweise:
-- returns the top 5 tables vacuumed least recently
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
ORDER BY last_vacuum ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been vacuumed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
WHERE last_vacuum < now() - '7 days'::interval;8. Älteste Analyse
Um Ihre SELECT-Abfragen auszuführen, wird der Abfrageplaner erstellt einen Ausführungsplan das beschreibt, welche Indizes und Tabellen gelesen werden müssen und wie. Um einen effizienten Ausführungsplan zu erstellen, benötigt der Planer Statistiken über die Verteilung von Werten, Größen von Tupeln und so weiter. Solche statistischen Informationen über die Daten in einer Tabelle werden von analyze gesammelt und verwaltet Operationen. Tabellen mit aktuellen Statistiken führen zu schnelleren Abfragen und weniger I/O.
Der oben erwähnte Autovacuum-Prozess führt normalerweise auch ANALYZE aus Auf dem Tisch wird gesaugt, um diese Informationen auf dem neuesten Stand zu halten. Dies allein bietet jedoch möglicherweise keine ausreichende Analyseabdeckung für Ihre Tabellen. Sie sollten ANALYZE ergänzen, indem Sie sie als geplante Jobs oder nach signifikanten Tabellenänderungen ausführen.
Im Interesse der Abfrage-Performance ist es am besten, kontinuierlich zu prüfen, ob alle Tabellen mindestens einmal in einem festgelegten Intervall analysiert wurden.
Maßnahme:Kontinuierlich prüfen, ob eine Tabelle in der letzten festgelegten Anzahl von Stunden/Tagen nicht analysiert wurde, ggf. Benachrichtigung.
Vorgehensweise:
-- returns the top 5 tables analyzed least recently
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
ORDER BY last_analyze ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been analyzed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
WHERE last_analyze < now() - '7 days'::interval;Erfassen 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
Der nächste Teil dieser Reihe behandelt Metriken auf Tabellenebene, Indexebene und Systemebene. Bleiben Sie dran!
