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 dritte und letzte Teil einer Blogserie und behandelt Metriken auf Tabellen-, Index- und Systemebene. Der erste behandelte Metriken auf Cluster-Ebene und der zweite behandelte Metriken auf Datenbank-Ebene.
Tabellenebene
Typischerweise folgen Daten in einer Datenbank der 80-20-Regel. 20 % der Tabellen enthalten die meisten Daten und werden am häufigsten aufgerufen oder verändert. Durch das Einrichten einer zusätzlichen Überwachung nur für diese Tabellen können Erkenntnisse gewonnen werden, die zwar wichtig sind, aber nur ein geringes Volumen aufweisen.
Hier sind einige Messwerte auf Tabellenebene, die einen Blick wert sind:
1. Tabellengröße
Die tatsächliche Plattengröße, die von der Tabelle verwendet wird, muss überwacht werden. In den meisten Fällen wächst die Tabelle weiter, daher ist die Wachstumsrate interessanter.
Es ist oft der Fall, dass sich die Wachstumsrate nach der Einführung einer neuen Version der Anwendung oder einer grundlegenden Änderung der Datenverkehrs-/Last-/Eingabemuster der Anwendung selbst ändert. Solche Änderungen müssen untersucht werden, um zumindest zu verifizieren, dass die neue Rate von der bereitgestellten Hardware getragen werden kann.
Maßnahme:Überwachen Sie die Vergrößerung der Tabelle jede Woche/jeden Monat und untersuchen Sie plötzliche Änderungen.
Vorgehensweise:
-- returns the size for each table
SELECT schemaname || '.' || relname,
pg_size_pretty(pg_table_size(schemaname || '.' || relname))
FROM pg_stat_user_tables;2. Tabellenaufblähung
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.
Diese Metrik kann entweder auf individueller Tabellenebene oder als Aggregat ausgewählter Tabellen oder auf Datenbankebene überwacht werden.
Maßnahme:Kontinuierliches Überwachen der Tabellenaufblähung als Byte und Prozentsatz, Warnung, wenn Werte einen festgelegten Schwellenwert überschreiten, VACUUM bei Bedarf.
Vorgehensweise:
Verwenden Sie check_postgres orpgmetrics, um aufgeblähte Schätzungen zu erhalten. Weitere Informationen finden Sie im Wiki.
3. Sequentielle Scans
Wenn Abfragen ausgeführt werden, die die verfügbaren Indizes nicht optimal nutzen, oder wenn die mit einer Tabelle verknüpften statistischen Informationen zu veraltet sind, muss Postgres möglicherweise jede Zeile der Tabelle durchlaufen. Dies wird als sequentieller Scan bezeichnet , und ist im allgemeinen Fall nicht sehr wünschenswert. Besser wäre ein Index-Scan , wobei auf die Zeilen einer Tabelle indirekt über Index-Lookup zugegriffen wird.
PostgreSQL kann Ihnen mitteilen, wie oft eine Tabelle nacheinander gescannt wurde und wie oft ein Index verwendet wurde. Sie können dies verwenden, um entweder die Anzahl aufeinanderfolgender Scans (wenn Sie sie vollständig vermeiden möchten) oder als Prozentsatz der gesamten Scans zu überwachen.
Maßnahme:Überwachen Sie fortlaufend die seq. Anzahl oder Prozentsatz der Scans, Warnung, wenn der Wert einen festgelegten Schwellenwert überschreitet.
Vorgehensweise:
-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
seq_scan,
round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;Indexebene
1. Indexgröße
Indizes können erheblichen Speicherplatz beanspruchen. Jeder Index einer Tabelle kann selbst möglicherweise so viel Platzbedarf auf der Festplatte haben wie die Tabelle selbst. Es ist nützlich, die Gesamtgröße der Indizes in einer Datenbank oder die Indizes wichtiger Tabellen im Auge zu behalten, insbesondere bei Bereitstellungen, bei denen Indizes durch automatische Prozesse erstellt werden können.
Unangemessen große Indizes können auf Blähungen oder einfach auf einen schlecht gestalteten Index zurückzuführen sein. In beiden Fällen kann die Behebung der Ursache (entweder durch Neuaufbau des Index oder durch Refactoring der Abfrage/des Index) zu kürzeren Abfragezeiten führen, daher lohnt es sich, große Indizes zu untersuchen.
Maßnahme:Überwachen Sie die Gesamtgröße interessanter Indizes jede Woche/jeden Monat und untersuchen Sie sie, wenn sie unangemessen groß sind.
Vorgehensweise:
-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
pg_size_pretty(pg_total_relation_size(indexrelid))
FROM pg_stat_user_indexes;2. Indexaufblähung
Indizes können auch aufgebläht werden. Es gibt viel zu viele Faktoren, einschließlich Tableworkload, Indextyp, Postgres-Version und mehr, die darüber entscheiden, wie aufgebläht ein Index wird. 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 des aufgeblähten Indexes in Bytes und Prozent, 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.
3. Cache-Trefferquote
PostgreSQL speichert häufig aufgerufene Bereiche von Indizes (und auch Tabellen) im Arbeitsspeicher. Wenn Sie Ihre Abfragen so eingestellt haben, dass sie die Tabellen außer zum Abrufen von Zeilen nicht berühren, besteht der nächste Schritt darin, eine maximale Cache-Residenz für diese wichtigen Indizes sicherzustellen, die Ihre Abfragen wirklich beschleunigen.
Die Cache-Auslastung eines Index kann anhand der Cache-Trefferquote gemessen werden, die den Prozentsatz der aus dem Cache gelesenen Indexblöcke zur Gesamtzahl der gelesenen Blöcke darstellt.
Maßnahme:Kontinuierliche Überwachung des Prozentsatzes der Cache-Trefferquote, Warnung, wenn der Wert unter einen festgelegten Schwellenwert fällt. Untersuchen Sie niedrige Werte für wichtige Indizes.
Vorgehensweise:
-- returns the cache hit ratio as a percentage, for each index
SELECT schemaname || '.' || indexrelname AS index_name,
round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 /
pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
FROM pg_stat_user_indexes
WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;Systemebene
Abgesehen von den PostgreSQL-Metriken ist es wichtig, einige Metriken der Maschine oder VM zu verfolgen, auf der Sie Ihr Postgres ausführen. Sie können dafür jede gängige Überwachungslösung verwenden oder sie sogar selbst abrufen und verfolgen.
1. Benutzter Arbeitsspeicher
Moderne Linux-Systeme haben eine komplexe Speicherabrechnung. Wir empfehlen, den „belegten Speicher“ zu überwachen, d. h. den verbleibenden Speicher, nachdem der als frei gekennzeichnete Speicher berücksichtigt wurde , als Puffer , als zwischengespeichert , und als Platte . Puffer und Cache geben unter Druck nach, ebenso wie die meisten (normalerweise über 95 %) der Slabs.
Der verbrauchte Speicher muss allerdings über einen entsprechend langen Zeitraum gemessen werden. Wenn Sie Batch-Jobs, Berichte, ETL usw. haben, die am Wochenende ausgeführt werden, beträgt der Zeitraum eine Woche. Die eigentliche Metrik, die Sie überwachen müssen, ist der maximal verwendete Speicher in diesem Zeitraum.
Wenn Ihre Datenbankgröße wächst, neigt dieser Wert normalerweise dazu, sich zu erhöhen. Sie müssen sicherstellen, dass die maximale Speichernutzung innerhalb einer angenehmen Grenze des verfügbaren Speichers liegt, z. B. 60-80 %. Wenn Sie dies vernachlässigen, würden Ihre Analyse-/OLAP-Workloads aufgrund von Speichermangel fehlschlagen.
Maßnahme:Überwachen Sie den maximal verwendeten Speicher über eine Woche/vierzehn Tage, benachrichtigen Sie ihn, wenn er einen festgelegten Schwellenwert überschreitet, und stellen Sie ihn erneut bereit.
Anleitung :
Der verwendete Speicher wird durch MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab angegeben , wo der Mem* Felder stammen aus /proc/meminfo . Weitere Informationen finden Sie in diesem RedHat-Artikel.
2. Lastdurchschnitt
Der einfache Lastdurchschnittswert ist immer noch die einfachste und schnellste Möglichkeit, die Last auf einem Server abzuschätzen. Dies gilt insbesondere für Postgres-Server, da jedes Backend ein separater Betriebssystemprozess ist und mehr von ihnen in einem lauffähigen Zustand den Lastdurchschnittswert erhöhen wird.
Für einen bestimmten Postgres-Server sollte die durchschnittliche Auslastung über einen Geschäftszyklus (z. B. eine Woche, einschließlich Batch-Job-Ausführungen) in einem angemessenen Bereich bleiben.
Maßnahme:Überwachen Sie die durchschnittliche maximale Last über jeden Tag/jede Woche und untersuchen Sie zunehmende Trends.
Anleitung :
Die 1-Minuten-, 5-Minuten- und 15-Minuten-Lastmittelwerte sind die ersten 3 Felder der ersten Zeile in der Datei /proc/loadavg .
3. Freier Speicherplatz
Das letzte Element in unserer Liste ist das offensichtlichste zu überwachende Element:die Menge an freiem Speicherplatz in jedem Dateisystem, das von Ihrem PostgreSQL-Server verwendet wird, einschließlich Tablespaces, WAL-Dateiverzeichnissen, Backup-Verzeichnissen und Serverprotokolldateien. In Fällen, in denen zu viele (100 Millionen) Dateien in einem einzigen Dateisystem erstellt werden, stellen Sie sicher, dass auch die Anzahl der freien Inodes überwacht wird. Fehlende Inodes werden auch als geringer Speicherplatz gemeldet.
Maßnahme:Kontinuierliche Überwachung des freien Speicherplatzes und der Inode-Nutzung auf allen relevanten Dateisystemen, Warnung, wenn Werte unter einen festgelegten Schwellenwert fallen.
Anleitung :
Freier Speicherplatz in einem Dateisystem kann nicht direkt durch Lesen einer beliebigen Datei in /proc abgerufen werden . Sie können stat -f /path/to/mount verwenden oder sogar df den belegten, freien und reservierten Speicherplatz für ein bestimmtes, gemountetes Dateisystem herauszufinden.
Kurzanleitung
Hier ist eine vollständige Liste aller Metriken, die wir bisher in dieser Serie besprochen haben. Denken Sie daran, dass dies nur die minimalen, wichtigsten Metriken sind, die Sie überwachen müssen, um zu erkennen, wenn die Dinge mit Ihrer PostgreSQL-Bereitstellung ins Wanken geraten.
Cluster-Ebene
- Transaktions-ID-Bereich
- Anzahl der Backends
- Inaktive Replikationsslots
- Backends warten auf Sperren
- Back-Ends im Leerlauf in Transaktion
- Replikationsverzögerung für aktive Verbindungen
- Replikationsverzögerung für Replikationsslots
- WAL-Dateianzahl
- Anzahl der archivierungsbereiten WAL-Dateien
Datenbankebene
- Verbundene Clients
- Größe
- Aufgeblähte Tabellen in allen Tabellen
- Indexaufblähung über alle Indizes hinweg
- Lange laufende Transaktionen
- Deadlocks
- Ältester Staubsauger
- Älteste Analyse
Tabellenebene
- Tabellengröße
- Aufblasen der Tabelle
- Sequentielle Scans
Indexebene
- Indexgröße
- Indexaufblähung
- Cache-Trefferquote
Systemebene
- Verwendeter Speicher
- Durchschnittliche Belastung
- Freier Speicherplatz
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.
