Datenbank-Monitoring von der Query bis zum Service

Was ist Datenbank-Monitoring?

Datenbank-Monitoring ist die kontinuierliche Überwachung von Zustand, Performance und Ressourcennutzung Ihrer Datenbanken, vom Server bis hinunter zur einzelnen Query. Es umfasst relationale Datenbanken wie PostgreSQL, MySQL und SQL Server, NoSQL-Systeme wie MongoDB und Redis sowie gemanagte Cloud-Datenbanken. Gutes Datenbank-Monitoring zeigt nicht nur, ob eine Datenbank erreichbar ist, sondern welche Queries langsam sind, warum sie langsam sind und welcher Teil Ihrer Anwendung davon betroffen ist.

Datenbanken stehen im Zentrum fast jedes Systems. Nahezu jeder Nutzer-Request endet in mindestens einer Query, und ein einziges ineffizientes Statement kann ein ganzes Produkt ausbremsen. Damit ist die Datenbank einer der wertvollsten Orte für Observability und zugleich eine der häufigsten Ursachen für Incidents.

Warum Datenbank-Monitoring wichtig ist

Datenbankprobleme kündigen sich selten eindeutig an. Ein fehlender Index nach einer Schemaänderung, ein Ausführungsplan, der mit wachsender Datenmenge kippt, ein Connection Pool, der unter Last leerläuft, oder eine lang laufende Transaktion, die Locks hält: All das zeigt sich zunächst nur als allgemeine Anwendungslatenz. Anwendungsteams sehen langsame Endpunkte, Datenbankadministratoren sehen ausgelastete Server, aber niemand sieht den Zusammenhang.

Datenbank-Monitoring schließt diese Lücke. Werden Query-Daten mit Application Traces verknüpft, erkennen Entwickler genau, welcher Codepfad eine problematische Query auslöst, und Datenbankspezialisten sehen, welcher Service und welches Release sie eingeführt hat. Zudem unterstützt es die Kapazitätsplanung: Speicherwachstum, Verbindungstrends und Replikationsverzögerung zeigen frühzeitig, wann Sie skalieren müssen, bevor Nutzer es bemerken.

Wichtige Datenbank-Metriken

Die Golden Signals gelten auch für Datenbanken: Durchsatz, Fehler, Latenz und Sättigung. In der Praxis sind diese Metriken besonders aussagekräftig:

• Query-Durchsatz und Latenz: Queries pro Sekunde und Latenz-Perzentile, insgesamt und pro normalisiertem Statement.
• Langsame Queries: Statements oberhalb eines Laufzeit-Schwellwerts, mit Ausführungsanzahl und gelesenen Zeilen.
• Verbindungen: aktive und wartende Verbindungen im Verhältnis zu konfigurierten Limits und Pool-Größen.
• Locks und Deadlocks: blockierte Sessions, Lock-Wartezeit und Anzahl der Deadlocks.
• Cache-Effizienz: Buffer- oder Cache-Trefferquote, bei Redis zusätzlich Hit Rate und Evictions.
• Replikation: Verzögerung zwischen Primary und Replicas, die Lesekonsistenz und sichere Failover beeinflusst.
• Ressourcen: CPU, Speicher, Disk-I/O, IOPS und Speicherverbrauch.

So funktioniert Datenbank-Monitoring mit Obseria

Obseria erfasst Datenbank-Telemetrie aus drei Blickwinkeln. Der Obseria Agent und die Receiver des OpenTelemetry Collectors lesen Engine-Metriken und Query-Statistiken aus selbst betriebenen Datenbanken, auch wenn diese in Kubernetes laufen. Gemanagte Datenbanken auf AWS, Azure und Google Cloud werden agentenlos über Cloud-APIs überwacht. Und die OpenTelemetry-Instrumentierung Ihrer Anwendungen erfasst jeden Datenbankaufruf als Span, mit Statement, Laufzeit und Zieldatenbank als Attributen.

Erst die Zusammenführung macht den Unterschied. Obseria TopoGraph zeigt, welche Services von welchen Datenbanken abhängen. Wird ein Endpunkt langsam, gelangen Sie vom Trace zum langsamen Span, zur normalisierten Query und zur Datenbankinstanz mit ihren Lock- und I/O-Metriken, ohne das Werkzeug zu wechseln. Obseria Intelligence nutzt diesen Kontext, um Incidents zu erklären, etwa indem es eine Latenzspitze mit einem Deployment verknüpft, das ein neues Query-Muster eingeführt hat. Continuous Profiling mit unter 1 % Overhead ergänzt Details auf Codeebene in der Anwendung.

Alle Daten sind in Obseria Lake mit OQL, PromQL oder SQL abfragbar:

fetch spans
| filter db.system == "postgresql"
| summarize count(), p95(duration), by:{db.statement, service.name}

Obseria Pipeline kann Literalwerte im Query-Text bereits beim Ingest maskieren, damit sensible Daten aus Statements nicht in Ihrer Telemetrie landen.

Best Practices für Datenbank-Monitoring

1. Queries normalisieren. Gruppieren Sie Statements nach Struktur statt nach konkreten Werten, um echte Hotspots zu erkennen.
2. Mit Deployments korrelieren. Viele Query-Regressionen folgen auf ein Release oder eine Schemamigration.
3. Früh auf Sättigung alarmieren. Verbindungslimits, Speicherplatz und Replikationsverzögerung verdienen Warnungen, lange bevor sie ausgeschöpft sind.
4. Sensible Daten schützen. Maskieren Sie Parameter in Statements und beschränken Sie den Zugriff auf Query-Texte.
5. Perzentile betrachten. Durchschnittswerte verbergen genau die langsamen Ausreißer, die Nutzer tatsächlich spüren.
6. Wachstum im Blick behalten. Verfolgen Sie Tabellen- und Indexgrößen über Monate, denn Ausführungspläne ändern sich oft erst, wenn Datenmengen bestimmte Schwellen überschreiten.