PostgreSQL Monitoring: Performance, Replikation und Queries
Überwachen Sie Verbindungen, Cache Hit Ratio, Locks, Vacuum und Replication Lag jeder Postgres-Instanz und sehen Sie, welcher Service und welche Query die Last erzeugen.
Warum PostgreSQL mit Obseria überwachen
Von der Query zum Aufrufer
Datenbank-Spans aus der OpenTelemetry-Instrumentierung zeigen, welcher Endpunkt ein langsames Statement ausführt. Sie beheben den Codepfad, nicht nur den Index.
Verlässliche Replikation
WAL Lag und Replikationsverzögerung pro Replika, mit Alerts, bevor Read Replicas veraltete Daten liefern oder ein Failover Schreibvorgänge verliert.
Selbst betrieben und managed
Dieselben Ansichten für PostgreSQL auf VMs, in Kubernetes, auf Amazon RDS und Aurora, Azure Database und Cloud SQL.
PostgreSQL-Komponenten, die Obseria überwacht
- Datenbanken. Größe, Commits, Rollbacks, Block-Reads, Deadlocks und Zeilenoperationen pro Datenbank aus pg_stat_database.
- Tabellen und Indizes. Tabellen- und Indexgröße, Index Scans, Sequential Scans und Vacuum-Läufe pro Tabelle.
- Verbindungen. Backends pro Datenbank im Vergleich zu max_connections, damit ein erschöpfter Pool früh sichtbar wird.
- Replikation und WAL. Replikationsverzögerung in Bytes, WAL Lag und WAL-Alter für jeden Standby.
- Background Writer und Checkpoints. Anzahl der Checkpoints, geschriebene Buffer und Checkpoint-Dauer aus pg_stat_bgwriter.
- Logs und Queries. PostgreSQL-Logs inklusive langsamer Statements über den filelog-Receiver sowie clientseitige Datenbank-Spans.
Die PostgreSQL-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Verbindungen und Last
Zeigt, wie viele Nutzer und Anwendungen verbunden sind und wie nah die Datenbank daran ist, neue Verbindungen abzulehnen.
Tempo und Transaktionen
Zeigt, wie viel Arbeit erfolgreich abgeschlossen oder abgebrochen wird und wie oft Daten direkt aus dem schnellen Speicher kommen.
Replikation und Sicherheit
Macht sichtbar, ob Sicherungskopien Ihrer Daten aktuell sind, damit bei einem Ausfall keine jüngsten Änderungen verloren gehen.
Pflege und Wachstum
Hebt Blockaden, regelmäßige Aufräumarbeiten und das Wachstum der Datenbank hervor, damit Sie Speicher planen und Verzögerungen vermeiden.
Alle 10 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
postgresql.backends | 1 | Offene Verbindungen pro Datenbank; im Vergleich zu max_connections zeigt sich Pool-Erschöpfung. |
postgresql.connection.max | {connections} | Konfiguriertes max_connections, die Obergrenze für Backends. |
postgresql.commits | 1 | Committete Transaktionen, das grundlegende Durchsatzsignal einer Datenbank. |
postgresql.rollbacks | 1 | Zurückgerollte Transaktionen; ein steigender Anteil deutet auf Anwendungsfehler oder Konflikte. |
postgresql.blks_hit | {blks_hit} | In Shared Buffers gefundene Blöcke; zusammen mit Block-Reads ergibt sich die Cache Hit Ratio. |
postgresql.deadlocks | {deadlock} | Erkannte Deadlocks pro Datenbank; jeder stetige Anstieg verdient eine Analyse. |
postgresql.replication.data_delay | By | Bytes an WAL, die eine Replika noch nicht angewendet hat. |
postgresql.wal.lag | s | Zeit zwischen dem Schreiben des WAL auf dem Primary und dem Flush oder Replay auf dem Standby. |
postgresql.table.vacuum.count | {vacuum} | Vacuum-Läufe pro Tabelle; nie gevacuumte Tabellen sammeln Bloat an. |
postgresql.db_size | By | Belegter Speicher pro Datenbank, für Kapazitätsplanung und Wachstums-Alerts. |
PostgreSQL-Monitoring in wenigen Minuten einrichten
- Schritt 1
Monitoring-User anlegen
Legen Sie eine Read-only-Rolle an und weisen Sie ihr pg_monitor zu. So liest sie Statistik-Views, ohne Zugriff auf Ihre Daten zu haben.
- Schritt 2
postgresql-Receiver konfigurieren
Ergänzen Sie den Receiver im OpenTelemetry Collector oder Obseria Agent mit Endpunkt, Zugangsdaten aus Umgebungsvariablen und den zu überwachenden Datenbanken.
- Schritt 3
Traces und Logs ergänzen
Instrumentieren Sie die aufrufenden Services mit OpenTelemetry und senden Sie die PostgreSQL-Logs, damit langsame Queries mit Requests und Logzeilen verknüpft sind.
receivers:
postgresql:
endpoint: db-primary:5432
transport: tcp
username: otel_monitor
password: ${env:POSTGRESQL_PASSWORD}
databases: [orders, billing]
collection_interval: 30s
tls:
insecure: false
ca_file: /etc/otel/pg-ca.crt
metrics:
postgresql.deadlocks:
enabled: true
postgresql.blks_hit:
enabled: true
exporters:
otlphttp:
endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
headers:
Authorization: "Bearer ${env:OBSERIA_TOKEN}"
service:
pipelines:
metrics:
receivers: [postgresql]
exporters: [otlphttp]
Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- PostgreSQL-Übersicht: Verbindungen, TPS, Cache Hit Ratio
- Replication Lag pro Standby
- Tabellen- und Indexgröße, Scans und Vacuum
- Alert: Backends über 80 % von max_connections
- Alert: steigende Replikationsverzögerung oder Deadlocks
PostgreSQL-Monitoring: Darauf kommt es an
Warum PostgreSQL Monitoring wichtig ist
PostgreSQL ist für viele Anwendungen das führende System für Bestellungen, Konten und Bestände. Wird die Datenbank langsam, werden alle abhängigen Services mit ihr langsam, und das Symptom zeigt sich meist weit entfernt als Timeout in einer API oder als fehlschlagender Hintergrundjob. PostgreSQL Monitoring muss drei Fragen schnell beantworten: Ist die Datenbank selbst gesund, steht sie unter ungewöhnlicher Last, und welcher Workload verursacht diese Last?
Obseria erfasst Postgres-Metriken mit dem postgresql-Receiver des OpenTelemetry Collectors, der die eingebauten Statistik-Views wie pg_stat_database, pg_stat_bgwriter und pg_stat_replication liest. Zusammen mit den Datenbank-Spans Ihrer Anwendungen hat jede Metrik einen Aufrufer.
Die PostgreSQL-Metriken, auf die es ankommt
Verbindungen
Jede Verbindung ist ein eigener Backend-Prozess mit eigenem Speicher. postgresql.backends im Vergleich zu postgresql.connection.max zeigt, wie nah Sie daran sind, neue Clients abzuweisen. Viele inaktive Verbindungen deuten meist auf einen falsch konfigurierten Pool, viele aktive auf echte Last oder Blockierungen.
Durchsatz und Fehler
postgresql.commits und postgresql.rollbacks liefern Transaktionen pro Sekunde und den Anteil fehlgeschlagener Transaktionen. Plötzliche Rollback-Spitzen folgen oft auf ein Deployment, das Constraint-Verletzungen oder Serialisierungsfehler eingeführt hat.
Cache-Effizienz
Die Cache Hit Ratio ist blks_hit / (blks_hit + blks_read). Bei OLTP-Workloads liegt sie typischerweise sehr hoch; sinkt sie, passt das Working Set nicht mehr in shared_buffers, und Queries gehen auf die Platte.
Replikation und WAL
postgresql.replication.data_delay und postgresql.wal.lag zeigen, wie weit jeder Standby zurückliegt. Hoher Lag bedeutet veraltete Lesezugriffe auf Replikas und ein größeres Risiko, bei einem Failover Schreibvorgänge zu verlieren.
Vacuum und Bloat
MVCC hinterlässt tote Tupel, die Autovacuum aufräumen muss. postgresql.table.vacuum.count zusammen mit dem Größentrend pro Tabelle zeigt Tabellen, bei denen Autovacuum nicht hinterherkommt.
Typische Probleme und wie Sie sie erkennen
- Erschöpfte Verbindungen: Die Backends nähern sich max_connections, Clients scheitern mit "too many clients". Alarmieren Sie bei 80 % und prüfen Sie die Pool-Einstellungen der aufrufenden Services.
- Lock-Konflikte und Deadlocks: Lang laufende Transaktionen blockieren andere. Aktivieren Sie
postgresql.deadlocksundpostgresql.database.locksund setzen Sielog_lock_waits = on. - Langsame Queries: Ein fehlender Index wird zu Sequential Scans. Setzen Sie
log_min_duration_statement, aktivieren Sie die Extensionpg_stat_statementsund nutzen Sie Datenbank-Spans, um zu sehen, welcher Endpunkt das Statement absetzt. - Replication Lag: Schreibspitzen oder eine ausgelastete Replika-Platte. Korrelieren Sie Lag mit Commit-Rate und I/O der Replika.
- Table Bloat und Transaction-ID-Wraparound: Selten gevacuumte Tabellen wachsen und erzwingen im schlimmsten Fall ein Notfall-Vacuum. Beobachten Sie Vacuum-Läufe und Größe pro Tabelle.
Best Practices für PostgreSQL Monitoring
- Nutzen Sie für die Metrikerfassung eine eigene Rolle mit
pg_monitorstatt eines Superusers. - Überwachen Sie Primary und jede Replika getrennt und versehen Sie sie mit ihrer Rolle als Tag.
- Alarmieren Sie zuerst auf Symptome (Verbindungssättigung, Replication Lag, Fehlerrate), dann auf Ursachen.
- Halten Sie Query-Texte in Spans bereinigt; die meisten OpenTelemetry-Instrumentierungen ersetzen Literale standardmäßig durch Platzhalter, und die Obseria Pipeline maskiert verbleibende Werte.
- Verfolgen Sie Datenbankgröße und Wachstum, um Speicher zu planen, bevor Platten volllaufen.
So unterstützt Obseria Ihr PostgreSQL Monitoring
Obseria führt Postgres-Metriken, Logs und die Datenbank-Spans Ihrer Services in einem Datenmodell in Obseria Lake zusammen. TopoGraph zeigt, welche Services von welcher Datenbank abhängen. Ein Alert auf Replication Lag oder Verbindungssättigung nennt so sofort die betroffenen Anwendungen. Obseria Intelligence korreliert eine Verlangsamung mit Deployments, Query-Mustern und Host-Metriken wie Plattenlatenz und zeigt die wahrscheinliche Ursache mit einer Beweiskette. Für Managed Services wie Amazon RDS, Azure Database for PostgreSQL oder Cloud SQL ergänzen die agentenlosen Cloud-Integrationen die Metriken des Anbieters, ganz ohne Agent auf dem Datenbank-Host.
Dashboards, Alerts und SLOs sind enthalten. Sie fragen alles mit OQL, PromQL oder SQL ab, zum Beispiel um die p95-Latenz der Datenbank-Spans pro Statement vor und nach einem Release zu vergleichen.
Verwandte Integrationen
Passende Funktionen
Datenbank-Monitoring
Finden Sie die langsame Query hinter dem langsamen Endpunkt. Obseria verknüpft Datenbankmetriken, Query-Performance und Logs mit den Traces und Services, die sie aufrufen.
Mehr erfahrenDistributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenAnomalie-Erkennung
Obseria Intelligence lernt den normalen Rhythmus jedes Service, meldet echte Abweichungen statt Schwellenwert-Rauschen und fasst zusammenhängende Anomalien zu einem Problem mit wahrscheinlicher Ursache zusammen.
Mehr erfahrenMehr erfahren
Die vier Golden Signals: Latenz, Traffic, Fehler und Sättigung
Die vier Golden Signals erklärt: Latenz, Traffic, Fehler und Sättigung, der Bezug zu RED- und USE-Methode und die Messung mit OpenTelemetry.
Was ist eine Root-Cause-Analyse (RCA)?
Was ist eine Root-Cause-Analyse? Der RCA-Prozess für Software-Incidents, 5 Whys, Fishbone und Fehlerbaum, ein Praxisbeispiel und RCA mit KI.
Häufige Fragen zum PostgreSQL-Monitoring
Der OpenTelemetry-postgresql-Receiver liest Standard-Statistik-Views, die in allen aktuell gepflegten PostgreSQL-Versionen verfügbar sind. Managed-Angebote wie Amazon RDS, Aurora PostgreSQL, Azure Database for PostgreSQL und Cloud SQL funktionieren ebenso.
Eine Read-only-Rolle mit der eingebauten Rolle pg_monitor genügt. Sie kann Statistik-Views lesen, aber nicht Ihre Tabellendaten.
Kombinieren Sie drei Quellen: Datenbank-Spans aus der OpenTelemetry-Instrumentierung Ihrer Services, PostgreSQL-Logs mit log_min_duration_statement und die Extension pg_stat_statements für aggregierte Statistiken.
Ja. Der Receiver meldet postgresql.replication.data_delay in Bytes und postgresql.wal.lag in Sekunden pro Standby, und auf beide können Sie alarmieren.
Die meisten OpenTelemetry-Datenbank-Instrumentierungen bereinigen Literale standardmäßig. Die Obseria Pipeline kann sensible Werte zusätzlich beim Ingest maskieren, bevor etwas gespeichert wird.
Starten Sie heute mit dem PostgreSQL-Monitoring
Binden Sie PostgreSQL in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.