AiHummer
Deutsch▾
AnmeldenKonto
v1.2.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Operationen/Beobachtbarkeit

Beobachtbarkeit

v1.2.x · aktualisiert 2026-07-07

AiHummer Beobachtbarkeit hat zwei Flächen: das Tor dient als Prometheus GET /metrics Endpunkt, den Sie für die Grundlagen abkratzen können, und er kann optional Telemetrie über OTLP senden an einen OpenTelemetry-Endpunkt, den Sie konfigurieren. Abrufen /metrics Für die Basisüberwachung; für Traces und umfangreiche Metriken richten Sie AiHummer auf Ihren OTLP-Collector und visualisieren die Daten mit den mitgelieferten Grafana-Dashboards.

[!NOTE] pprof (/debug/pprof) ist nicht bloßgestellt.

Der Prometheus /metrics Endpunkt

GET /metrics liefert Prometheus-Text-Format-Metriken ohne zusätzliche Einrichtung. Es werden nur nicht sensible Messwerte exponiert – Build-Informationen, Prozesslaufzeit und -betrieb, Zustand des DB-Verbindungs-Pools und ein Bereitschafts-Messwert; keine Mandantendaten, keine Geheimnisse, keine pro-Anfrage-Labels. Für Traces und umfangreiche Metriken verwenden Sie das OTLP-Push.

OTLP push

Setzen Sie eine einzelne Variable, um die Telemetrie einzuschalten:

# gateway.env — export telemetry to your OTLP collector
AIHUMMER_OTEL_ENDPOINT=http://otel-collector:4317

Mit AIHUMMER_OTEL_ENDPOINT Wenn eingerichtet, sendet das Gateway Telemetriedaten an diesen Collector. Von dort aus leiten Sie sie an Ihr Backend (Tempo, ein Metrik-Speicher, Logs) und in Grafana weiter.

Umgang mit Panics und Fehlern

Fehlerberichte werden niemals nach außen gesendet: das Gateway enthält keinen externen Fehler-Tracker-Client und keine externe DSN — Daten über Ihre Fehler verlassen niemals Ihren Perimeter.

Die Widerstandsfähigkeit gegen Panics ist dennoch vollständig:

  • ein Panic in einem HTTP-Handler wird zu einer gewöhnlichen Fehlerantwort (ein 500 mit einem AIH-…-Umschlag) — der Prozess stirbt nicht und bedient die übrigen Anfragen weiter;
  • ein Panic in einer Hintergrund-Goroutine wird ebenfalls abgefangen und legt das Gateway nicht lahm.

Beide Fälle landen im strukturierten Protokoll — lesen Sie sie auf der Seite Protokolle (unten) oder über journalctl.

Live-Protokolle in der Admin-Oberfläche

Die Admin-Oberflächen Protokolle Seite ist ein Live-Log des Gateway-Journals: Neue Zeilen werden automatisch alle paar Sekunden eingezogen, mit automatischem Scrollen, während Sie am unteren Ende sind. Die Symbolleiste hat eine Linienverfahren und ein Pegelfilter (alle / Fehler / Warnungen / Informationen / Debug). Mehrere andere Seiten (Dashboard, Sitzungen, Kanäle) werden ebenfalls automatisch aktualisiert, und lange Listen (Audit, Änderungen, Benachrichtigungen und so weiter) werden Seite für Seite mit einem „Mehr anzeigen“-Button geladen.

Vollständige Protokolle jedes Dienstes leben noch in systemd — aihummer logs [unit] oder journalctl -u aihummer-gateway.

Grafana-Dashboards

Fertige Grafana-Dashboards werden mit der Version ausgeliefert. Importieren Sie sie in Ihre Grafana-Instanz, um die betrieblichen Ansichten zu erhalten, ohne Panels von Grund auf neu zu erstellen.

Was man anschauen sollte

Dies sind die Signale, die Ihnen zeigen, dass das System gesund ist und die Vorgänge fließen:

Signal Warum es wichtig ist
Drehverzögerung End-to-End-Reaktionsfähigkeit der Agentenwechsel
Fehlerquote Fehlschlagende Drehungen / Anfragen – das erste Anzeichen von Problemen
Lieferdispositionen Ob Antworten tatsächlich die Kanäle erreichen
Ausstehende Lieferungen Rückstand an nicht zugestellten Antworten; anhaltendes Wachstum bedeutet, dass die Zustellung stecken geblieben ist

Ein anhaltender Anstieg von ausstehende oder wiederholt fehlgeschlagene Lieferungen ist die klarste Frühwarnung dafür, dass die Lieferung sich zurückstaut – beobachten Sie sie während Rollouts und Vorfällen.

Systemendpunkte

Neben OTLP stellt das Gateway kleine HTTP-Endpunkte bereit, die für Sonden, Uhren und Client-Diagnosen nützlich sind:

Methode Endpunkt Zweck
GET /metrics Prometheus-Metriken (Build, Laufzeit, DB-Pool, Bereitschaft)
GET /healthz Live-Status + Version
GET /readyz Bereitschaft (prüft Postgres; 503 bei Ausfall)
GET /v1/ping Leichtgewichtige Erreichbarkeitsprüfung
GET /v1/time Serverzeit
POST /v1/client-log Clientseitige Protokollereignisse erfassen

Die Gesundheits- und Bereitschaftsprüfungen werden ausführlich behandelt unter systemd & Gesundheitsprüfungen.

Wohin als Nächstes