Service ▸ Datenbank

Überblick — was der Bildschirm leistet

Service ▸ Datenbank (/service/database) ist ein Live-Monitoring-Bildschirm, der sich direkt mit den registrierten Datenbank-Collectors (access=database) verbindet, um Lastmetriken zu sammeln und die Schemastruktur zu analysieren. Jede Datenbank wird als eine Karte dargestellt, und jede Karte zeigt auf einen Blick zwei Lastachsen.

Das Datenbank-Monitoring ist um zwei Lastachsen herum aufgebaut:

Darüber hinaus bietet der Bildschirm eine Schemaanalyse (Gesamtgröße · größte Datenbanken · größte Tabellen · Engine-Verteilung), Effizienzwerte (Cache-Trefferquote des Buffer Pools · Indexnutzung) sowie einen Block zur InnoDB-Speicherverwaltung (Flush der Dirty Pages · Checkpoint).

Dieser Bildschirm installiert keinen Agenten auf der Ziel-Datenbank. Die InfraGuard-Anwendung verbindet sich lediglich mit den hinterlegten Zugangsdaten zur entfernten MySQL/MariaDB und setzt Abfragen mit SHOW GLOBAL STATUS / information_schema ab.

Wann Sie ihn verwenden

• Eine Datenbank ist plötzlich langsam geworden — sofort erkennen, ob die Verbindungen gesättigt sind, die Nebenläufigkeit hochgeschnellt ist oder die Slow Queries zugenommen haben.
• Vor und nach dem Tuning des Verbindungspools — die Sättigung von threads_connected / max_connections über die Zeit beobachten.
• Kapazitätsplanung — sehen, welche Schemas bzw. Tabellen den meisten Speicherplatz verbrauchen und wie die Engine-Verteilung aussieht.
• Diagnose des InnoDB-Flush-Drucks — ob die Dirty Pages unterhalb des Schwellenwerts gesund zirkulieren und wie weit das Checkpoint-Alter gegenüber der Redo-Kapazität vorgelaufen ist.
• Prüfung der Cache- und Indexeffizienz — Trefferquote des Buffer Pools und Indexnutzung als Tuning-Beleg lesen.

Aufbau

KPIs am oberen Rand

Kartenkopf

• Host-Bezeichnung (Collector host_alias → config.host → env-Host aus cred_ref, in dieser Reihenfolge).
• Treiber (mysql/mariadb), Datenbankname, Laufzeit, Status-Badge.

① Nebenläufigkeitslast

• Ring-Anzeige der Verbindungssättigung = threads_connected / max_connections.
• Running (threads_running) — Threads, die tatsächlich CPU verbrauchen.
• Waiting (Rückstau) (waiting) — Abfragen, deren Bearbeitungszeit den Schwellenwert (standardmäßig 2 s) überschreitet. Je nach PROCESS-Recht zählt dies serverweit oder nur die eigene Verbindung (der Geltungsbereich wird auf der Karte angezeigt).

② Durchsatz und Ineffizienz

• QPS-Sparkline = Δquestions / Δt (letzte 60 erfolgreiche Messungen).
• Slow-Query-Rate = Δslow_queries / Δt sowie Slow-Query-Summe (slow_queries).

Kartenfuß — Effizienz · Sperren

Jede Metrikbezeichnung (cache · index · lock · checkpoint) trägt ein Erklär-Popover, das Ursachen und Gegenmaßnahmen beschreibt (z. B. innodb_buffer_pool_size erhöhen, Covering-Indizes verwenden, Gap Locks vermeiden).

Schemaanalyse (einklappbar)

Standardmäßig eingeklappt; mit [Aufklappen] öffnen. Aggregiert aus information_schema.tables, zeigt sie Gesamtgröße · Anzahl der Tabellen · Anzahl der Schemas · die 8 größten Schemas nach Größe · die 14 größten Tabellen nach Größe · Engine-Verteilung.

Die Schemaanalyse ist auf dem Server von Natur aus eine langsame Abfrage (gemessen ca. 3,5 s) und wird deshalb mit einem 30-minütigen Langzeit-Cache umgangen. Der Scheduler (infr:collect-db) wärmt den Cache vor, sodass Web-Anfragen ihn immer treffen. Ist der Cache leer, bleibt der Abschnitt kurz verborgen und erscheint beim nächsten Polling.

InnoDB-Speicherverwaltung (Flush der Dirty Pages)

• Zeitreihe der Dirty Pages plus eine Overlay-Linie für den „passenden Wert“ (Schwellenwert) — MAX (innodb_max_dirty_pages_pct) und LWM (innodb_max_dirty_pages_pct_lwm), umgerechnet in absolute Seitenzahlen (keine willkürlichen Konstanten, sondern der Punkt, an dem InnoDB tatsächlich aggressiv zu flushen beginnt).
• Checkpoint-Alter (Log sequence number − Last checkpoint at) als Prozentsatz der Redo-Kapazität.
• Größe des Buffer Pools und dessen Verhältnis zum Server-RAM (das über den Alias verknüpfte mem_mb der OS-Instanz).

Anordnung der Karten

Das Kartenraster unterstützt Neuanordnung per Ziehen (SortableJS · Reihenfolge in localStorage gespeichert) mit Row-Span-Masonry. Der Bildschirm aktualisiert sich per 30-Sekunden-Polling.

Vorgehen

1. Registrieren Sie zunächst unter Verwaltung ▸ Collectors einen Collector mit access=database. Geben Sie host/port/database/username samt Passwort ein (auf dem Collector Crypt-verschlüsselt gespeichert), oder setzen Sie cred_ref = env:PREFIX, um einen vorhandenen Zugangsdatensatz aus .env wiederzuverwenden.
2. Öffnen Sie /service/database; die registrierten Datenbanken werden als Karten aufgelistet. Beim Aufruf wird, falls die letzte Messung älter als 60 Sekunden ist, sofort eine einmalige Messung (ensureFresh) durchgeführt.
3. Erkennen Sie die problematische Datenbank am Status-Badge im Kopf und grenzen Sie die Ursache dann über die beiden Lastachsen (Nebenläufigkeit / Durchsatz) ein.
4. Klappen Sie die Schemaanalyse auf, um die größten Schemas und Tabellen zu prüfen (das Masonry-Layout ordnet sich bei Höhenänderung automatisch neu an).
5. Ziehen Sie Karten, um die für Sie wichtigen Datenbanken nach oben zu holen (die Reihenfolge wird im Browser gespeichert).

Zugangsdaten über cred_ref wiederverwenden

Mit cred_ref = env:PREFIX werden die folgenden Schlüssel aus .env gelesen, sodass kein Geheimnis in der Datenbank gespeichert wird:

Zum Beispiel: env:STATS_DB → Server blue, env:STATS_GLORY_DB → Server glory.

So sehen Sie serverweit wartende Abfragen

Um waiting serverweit zu aggregieren, benötigt das Monitoring-Konto das Recht PROCESS; andernfalls werden nur seine eigenen Verbindungen gezählt. Ein Monitoring-Konto mit minimalen Rechten:

CREATE USER 'infra_monitor'@'%' IDENTIFIED BY 'YOUR_DB_PASSWORD';
GRANT PROCESS, SELECT ON *.* TO 'infra_monitor'@'%';
FLUSH PRIVILEGES;

Die Entscheidung über den Geltungsbereich (ob PROCESS vorliegt) ist pro Konto fest und wird daher 1 Stunde lang zwischengespeichert. Wenn Sie das Recht später vergeben, wirkt es innerhalb einer Stunde (für sofortige Wirkung den Cache leeren).

Datenquellen

Ursprungsabfragen (auf der entfernten Datenbank ausgeführt)

Speichertabelle

Die gemessenen Daten werden in die Zeitreihe infr_db_metric geschrieben (Migration 000681). Auch die kumulativen Zähler (questions/slow_queries/bytes_*) werden gespeichert, damit die nächste Messung QPS · Slow-Query-Rate · Effizienzwerte per Delta berechnen kann.

infr_db_metric
  collector_id  host  sampled_at  uptime_sec
  threads_connected/running/cached  max_connections  conn_pct
  waiting  waiting_scope
  questions  slow_queries  qps  slow_qps
  bytes_received/sent  recv_bps/sent_bps  innodb_row_lock_waits
  ok  message  raw(json: efficiency + InnoDB memory-management derivations)

Keine Verbindungslecks (die Lehre aus [1040]). Jede Messung baut eine Laufzeitverbindung auf und gibt sie im finally sofort mit DB::purge frei. Ein PDO-Timeout (standardmäßig 5 s) verhindert, dass Web-Anfragen und der Scheduler an einer langsamen Gegenstelle hängen bleiben. Bricht diese Disziplin, ist max_connections der gemeinsam genutzten MySQL erschöpft und selbst die Produktion ist betroffen.

Erfassungsplan · Gating

Die Zeitreihe wird vom Artisan-Befehl infr:collect-db gefüllt. Er läuft einmal und beendet sich (kein Daemon); der Scheduler ruft ihn jede Minute auf.

# Sofort eine einzelne Messung für einen Collector vornehmen (Gate umgehen)
php artisan infr:collect-db --key=db@blue --force

Die Betriebsrichtlinie (Verwaltung ▸ Betriebsrichtlinie · OpsPolicy) steuert die geplanten Läufe:

Schwellenwerte für degraded/down

DbCollectorService::statusOf entscheidet den Status über OpsPolicy::dbThresholds().

Liegt irgendein Grund vor → degraded; liegt keiner vor → up.

Zugriff

• Dieser Bildschirm ist eine schreibgeschützte Konsole innerhalb der Gruppe infr.auth — minimale Leseebene demo=1.
• Auf dieser Seite gibt es keine Schreib-Endpunkte. Registrieren bzw. bearbeiten Sie die Zugangsdaten der Ziel-Datenbanken unter Verwaltung ▸ Collectors (admin=10, Gate level≥5).
• Schwellenwerte und Erfassungsmodus ändern Sie unter Verwaltung ▸ Betriebsrichtlinie (admin).

Fehlersuche und FAQ

Eine Karte zeigt „down“

• no_credentials — host oder username in der config sind leer, oder die env-Schlüssel für cred_ref=env:PREFIX fehlen.
• stale — die letzte Messung ist älter als 5 Minuten. Prüfen Sie, ob der Scheduler (infr:collect-db) läuft und, im economy-Modus, ob ein Konsolenbenutzer anwesend ist.
• Andere Meldung — die Ursache des Verbindungsfehlers (Authentifizierung abgelehnt, Host nicht erreichbar, Timeout) wird wörtlich angezeigt. Diagnostizieren Sie mit php artisan infr:collect-db --key=<key> --force.

QPS / Slow-Query-Rate / Effizienzwerte zeigen „—“

Abgeleitete Werte werden als Delta gegenüber der vorherigen erfolgreichen Messung berechnet. Bei der ersten Messung, nach einem Neustart der Datenbank (uptime verringert → Zähler zurückgesetzt) oder wenn ein Zähler zurückspringt, ist der Wert nicht vertrauenswürdig und bleibt null (—). Ab der zweiten Messung erscheint er normal.

Wartende Abfragen zeigen „nur eigene Verbindung“

Dem Monitoring-Konto fehlt das globale Recht PROCESS, daher sind in information_schema.processlist nur seine eigenen Verbindungen sichtbar. Vergeben Sie PROCESS mit dem SQL unter So sehen Sie serverweit wartende Abfragen (Wirkung innerhalb einer Stunde, sobald der Cache des Geltungsbereichs abläuft).

Der Abschnitt Speicherverwaltung / Checkpoint ist leer

• Die Speicherverwaltung benötigt innodb_buffer_pool_pages_total (bei älteren Messungen ausgeblendet).
• Das Checkpoint-Alter wird aus SHOW ENGINE INNODB STATUS gelesen (→ benötigt PROCESS). Ohne das Recht werden die Checkpoint-Linie und ihre Beschriftung sauber weggelassen.

Die Schemaanalyse blinkt kurz leer und erscheint dann

analysisCached ist eine reine Cache-Abfrage. Beim ersten Aufruf ist der Cache leer und der Abschnitt verborgen; nachdem der Scheduler ihn vorgewärmt hat, erscheint er beim nächsten 30-Sekunden-Polling. Fehlschläge werden nur 30 s zwischengespeichert (Erfolge 30 Minuten), damit ein vorübergehender Fehler nicht lange festgehalten wird.

Verwandt

• Schulung zu DB-Last und Tuning — Hintergrund zu den Popovers lock · cache · index · checkpoint.
• Collectors — Registrierung von access=database-Collectors, Geheimnisse, cred_ref.
• Betriebsrichtlinie — Erfassungsmodus · Intervall · Degrade-Schwellenwerte.
• Sitzungen (Redis) — der Schwesterbildschirm, der dieselbe Methodik auf Redis anwendet.
• Service-Übersicht — wo die DB-Karten auf dem Live-Service-Board zusammengefasst werden.
• DB-Collector-Pipeline — Erfassungsbefehl und Disziplin gegen Verbindungslecks.