Observability

NodePilot stellt Metriken, Traces und eine Observability-API bereit. OpenTelemetry ist standardmäßig deaktiviert und muss explizit konfiguriert werden.

Live-Ops: kurze Ausführungen untersuchen

Über den Ausführungsbalken zoomt das Mausrad die Zeitachse um den Mauszeiger. So werden kurze Läufe breiter und leichter anklickbar; zusätzlich tolerieren schmale Balken Klicks unmittelbar daneben. Über der Workflow-Liste scrollt das Mausrad weiterhin vertikal.

Der Zoom reicht bis zu einem Fünf-Sekunden-Ausschnitt innerhalb des geladenen 30- oder 60-Minuten-Fensters. Der gewählte Ausschnitt bleibt zeitlich stehen. Zur Live-Ansicht setzt ihn zurück; auch ein Wechsel des Zeitfensters setzt den Zoom zurück.

Mehrere Zeilen desselben Workflows sind wiederverwendete Parallelspuren. Eine leere Stelle ist kein Fehlerstatus. Gemeinsam genutzte Child-Workflows erscheinen eigenständig mit der Anzahl sichtbarer Aufrufer; nur eindeutig einem Aufrufer zugehörige Gruppen werden darunter eingerückt. Die ID neben dem Namen bezeichnet den aktiven beziehungsweise zuletzt gestarteten Lauf auf der Spur. Jeder Balken öffnet seine eigene Ausführung.

OpenTelemetry (opt-in)

OpenTelemetry ist opt-in. Setup in NodePilot.Telemetry — Constants, Options, PrometheusClient.

Prometheus-Scrape

OpenTelemetry:Exporters:PrometheusScrapeAllowAnonymous (default false) — /metrics ist nicht anonym erreichbar. Auf true setzen, wenn der Scraper ohne Auth zugreifen soll (Relaxation, bewusst setzen).

Hostname-Redaktion

OpenTelemetry:RedactHostnames (default true) hält den Hostnamen aus der Telemetrie: service.instance.id ist eine prozessstabile Zufalls-Id statt hostname:pid, das Resource-Attribut host.name entfällt, und die Serilog-Bridge unterdrückt das Feld. Wer Host-Attribution in Tempo/Grafana braucht, setzt den Wert bewusst auf false — nach einem Upgrade verschwindet die Zuordnung sonst ohne weiteren Hinweis.

Observability-API

CLI: np observability summary|query|query-range.

SIEM-Logging

Für strukturierte Log-Aufnahme in Elastic, Sentinel oder Splunk ist Logging:Format=ecs-json zu setzen. Details: SIEM-Logging.

Support-Diagnostics

Für Betriebs- und Ticketdiagnose stehen GET /api/diagnostics/support-log|support-log/download|support-events|support-events/export|app-log|app-log/download für Admins bereit. Details: Logging. Welche Logdateien es gibt, wo sie liegen und welche bei welchem Störungsbild weiterhilft: Logs & Diagnose.

Metrics (Auszug)

• nodepilot.database.requests_rejected — Requests, die der offene Datenbank-Breaker sofort mit 503 beendet.
• nodepilot.database.outages — bestätigte Ausfall-Episoden.
• nodepilot.database.probe_cleanup_timeouts — abgebrochene Cleanup-Schritte der Recovery-Sonde.
• nodepilot.scheduler.triggers.admission_deferred — Trigger-Fires, deren Zulassung zurückgestellt wurde, weil die Datenbank nicht verfügbar war; die Quelle behält das Signal und versucht es nach der Erholung erneut.
• nodepilot.audit_archive.hash_drift — Audit-Archive-Drift.
• nodepilot_credential_crypto_calls{operation,result} — encrypt/decrypt × success/failure.
• nodepilot_credential_crypto_legacy_reads — Decrypts aus Legacy-Provider (Migration-Window).

Für Monitoring gilt: /healthz/ready ist das Traffic-Gate und liefert bei Armed oder Unavailable 503. /healthz/database antwortet immer 200 und berichtet ok, armed oder unavailable inklusive grober Ursache. Pro Erholung entsteht genau ein Audit-Eintrag DATABASE_RECOVERED; ein Trip-Audit ist während des Ausfalls nicht zuverlässig schreibbar.