Datenbanken

Überblick

Die Datenbank-Monitors verbinden sich mit Ihrem PostgreSQL-, MySQL/MariaDB- oder MongoDB-Server so, wie Ihre Anwendung es tut, führen eine Abfrage aus und prüfen das Ergebnis. Anders als eine TCP-Prüfung auf Port 5432 belegt das, dass der Server Verbindungen annimmt, Sie anmeldet und tatsächlich antwortet — und es erfasst bei jeder Prüfung die Verbindungs- plus Abfragelatenz.

Drei Monitor-Typen, ein Verhalten:

Typ	Akzeptierte Schemata	Standardport	Standardabfrage
PostgreSQL	postgres://, postgresql://	5432	SELECT 1
MySQL	mysql://, mariadb://	3306	SELECT 1
MongoDB	mongodb://, mongodb+srv://	27017	{ "ping": 1 }

MariaDB spricht das MySQL-Protokoll — verwenden Sie den Typ MySQL.

Wie es funktioniert

1. Der Agent öffnet eine Verbindung zum Server (mit TLS, wenn die URL es verlangt) und meldet sich mit Benutzer und Passwort des Monitors an.
2. Er führt die konfigurierte Abfrage aus — oder die Standardabfrage des Typs.
3. Das Ergebnis wird mit der optionalen Ergebnisprüfung verglichen. Abgelehnte Verbindung, fehlgeschlagene Anmeldung, Abfragefehler oder Zeitüberschreitung zählen allesamt als fehlgeschlagene Prüfung; ein Ergebnis außerhalb des erwarteten Werts ebenfalls.

Die Latenz umfasst Verbindung plus Abfrage — eine langsamer werdende Datenbank zeichnet sich also als Trend im Diagramm des Monitors ab, lange bevor sie aufhört zu antworten.

Einstellungen

Einstellung	Beschreibung	Standard
Verbindungs-URL	postgres://host:5432/dbname?sslmode=require, mongodb://host1,host2/admin?replicaSet=rs0&tls=true	—
Datenbankbenutzer	Anmeldung, die für die Prüfung verwendet wird	—
Datenbankpasswort	Verschlüsselt gespeichert	—
Testabfrage	SQL-Anweisung oder ein MongoDB-Befehlsdokument als JSON	SELECT 1 / { "ping": 1 }
Ergebnisprüfung	Operator + erwarteter Wert, angewendet auf das Abfrageergebnis (optional)	keine
TLS-Prüfung überspringen	Ein selbst signiertes Zertifikat akzeptieren	aus
Intervall	Prüffrequenz	tarifabhängig
Zeitbudget	Festes Prüfbudget, Verbindung + Abfrage (nicht konfigurierbar)	5 s

Wohin die Zugangsdaten wandern

Fügen Sie die Verbindungs-URL genau so ein, wie Ihr Anbieter sie liefert, samt Zugangsdaten. Alles vor dem @ wandert in die Felder Benutzer und Passwort, und die URL wird ohne diesen Teil gespeichert:

Sie fügen ein   mongodb://monitoring:s3cret@node1.example.net,node2.example.net/admin?replicaSet=rs0&tls=true
gespeicherte URL mongodb://node1.example.net,node2.example.net/admin?replicaSet=rs0&tls=true
Benutzer        monitoring        (verschlüsselt)
Passwort        s3cret            (verschlüsselt)

Die URL ist das, was Monitor-Liste, Alarmmeldungen, öffentliche Statusseiten, Audit-Log und DSGVO-Export zeigen. Benutzer und Passwort sind im Ruhezustand verschlüsselt, in API und allen Exporten als *** maskiert und aus Fehlermeldungen entfernt. Das gilt für jeden Monitor-Typ — ein HTTP-Ziel https://benutzer:passwort@host wird genauso aufgeteilt.

Verwenden Sie einen nur lesenden Datenbankbenutzer, eigens fürs Monitoring angelegt. Die Abfrage läuft mit dessen Rechten, nichts anderes begrenzt sie.

TLS

Die URL entscheidet, ob TLS verwendet wird, je nach Konvention der jeweiligen Engine:

• PostgreSQL — ?sslmode=require (oder verify-ca, verify-full)
• MySQL / MariaDB — ?ssl-mode=REQUIRED (oder tls=true)
• MongoDB — ?tls=true; mongodb+srv://-URLs verwenden immer TLS

Das Zertifikat des Servers wird gegen die öffentlichen Wurzelzertifikate geprüft. Für ein selbst signiertes Zertifikat aktivieren Sie am Monitor TLS-Zertifikatsprüfung überspringen.

Ergebnisprüfung

Das Abfrageergebnis wird auf einen Wert reduziert:

• SQL — die erste Spalte der ersten Zeile. SELECT count(*) FROM jobs WHERE status = 'stuck' liefert eine Zahl; SELECT pg_is_in_recovery() liefert t/f.
• MongoDB — das Antwortdokument des Befehls. Wählen Sie ein Feld über einen Punktpfad (ok, members.0.stateStr, repl.setName); lassen Sie den Pfad leer, um die ganze Antwort zu vergleichen.

Wählen Sie dann einen Operator (==, !=, contains, >, <, >=, <=) und den erwarteten Wert. Numerische Operatoren vergleichen Zahlen, die übrigen Text.

Beispiele:

Engine	Abfrage	Prüfung	Bedeutung
PostgreSQL	SELECT count(*) FROM jobs WHERE status='stuck'	< 10	Die Job-Warteschlange staut sich nicht
PostgreSQL	SELECT extract(epoch from now() - pg_last_xact_replay_timestamp())	< 30	Replikationsverzögerung unter 30 s
MySQL	SHOW STATUS LIKE 'Threads_connected'	(erste Spalte ist der Name — Unterabfrage verwenden)	—
MySQL	SELECT count(*) FROM information_schema.processlist	< 200	Verbindungszahl unter 200
MongoDB	{ "replSetGetStatus": 1 }	members.0.stateStr == PRIMARY	Knoten 0 ist der Primary
MongoDB	{ "serverStatus": 1 }	connections.current < 500	Verbindungszahl unter 500

Ohne Ergebnisprüfung besteht die Prüfung darin, sich erfolgreich zu verbinden und die Abfrage auszuführen.

Private Datenbanken

Eine Datenbank, die aus dem Internet nicht erreichbar ist — und das sollten die meisten nicht sein —, wird von einem Private Agent aus überwacht, der in Ihrem Netz läuft. Die Prüfung ist identisch; nur der ausführende Agent ändert sich. Öffentliche Regionen weisen Ziele ab, die auf private Adressen auflösen.

Messwerte

Verbindungs- plus Abfragezeit wird bei jeder Prüfung erfasst und speist dieselben Latenzdiagramme, Perzentile und Alarme wie ein HTTP-Monitor.