Monitoring-Signale: Prometheus, Grafana und InfluxDB

kanman kann Ihr Monitoring lesen, um zu bemerken, wenn sich ein Service nicht mehr normal verhält, die wahrscheinliche Ursache zu finden und im Rahmen seiner Grenzen das Richtige zu tun. Es arbeitet mit:

Prometheus und kompatiblen APIs (Thanos, Grafana Mimir, VictoriaMetrics)
Grafana: Alarmregeln, Dashboards und Metriken über eine seiner Datenquellen
InfluxDB: InfluxQL, Flux oder SQL mit einem Nur-Lese-Token
Checkmk, wie unter Backstage und Checkmk beschrieben

kanman hat kein eigenes Dashboard. Ihr Monitoring bleibt, wo es ist; kanman verlinkt es in seinen Befunden und antwortet, wenn Sie fragen: „Wie läuft payment-api?“.

kanman handelt nie in der Produktion

kanman liest Ihr Monitoring und handelt nur außerhalb der Produktion:

es schreibt einen Befund mit den Belegen, seiner Einschätzung von Ursache und Auswirkung und wie sicher es ist
es legt eine Fix-Story an oder hängt den Befund an die bereits offene
es schlägt einen Revert als Merge Request vor, aber nur für eine Änderung, die kanman selbst gemacht hat
es schlägt eine Story für eine Alarmregel vor, die als Code in Ihrem Repository liegt
es entwirft den Change Request und die Incident-Notiz für Ihren eigenen Change- und Incident-Prozess
es sagt der Person in Rufbereitschaft einmal, was es gefunden hat und was ein Mensch als Nächstes tun würde

Neustarten, Zurückrollen, Skalieren, Alarme bestätigen, Stummschaltungen und Wartungsfenster sind immer die Änderung eines Menschen. kanman kann sie nicht ausführen: Es nutzt von jedem System nur die lesenden Teile, lehnt alles andere ab, bevor eine Anfrage hinausgeht, und sagt das im Incident. Stories und Merge Requests laufen durch die normale Pipeline Ihres Teams, mit Ihren Freigaben und Ihrer Merge-Regel.

1. Lesezugriff vorbereiten

Prometheus: ein Token mit Lesezugriff oder Benutzer und Passwort. Bei Mimir gehört /prometheus zur Adresse.
Grafana: das Token eines Service-Accounts mit der Rolle Viewer und die Datenquelle, die kanman abfragen soll (ihre UID, zum Beispiel Ihr Prometheus).
InfluxDB: ein Nur-Lese-Token und die Datenbank oder der Bucket.

2. Quelle hinzufügen

Öffnen Sie das Team, klicken Sie auf Team, wählen Sie Services und Rufbereitschaft und suchen Sie unter den Services die Karte Katalog und Monitoring.
Klicken Sie auf Quelle hinzufügen und wählen Sie Prometheus, Grafana oder InfluxDB.
Geben Sie einen Namen, die Adresse und das Token ein. kanman speichert das Token verschlüsselt als Workspace-Secret (Workspace-Einstellungen > Secrets).
Wählen Sie unter Wie ich lese entweder Direkt, nur lesend oder Über deinen MCP-Server (siehe unten).
Service-Label: das Label oder der Tag, das in Ihren Metriken den Service benennt, zum Beispiel service oder app. kanman beobachtet die Services des Teams (Team > Services und Rufbereitschaft) mit diesem Label.
Optional: Alarmregeln als Code, das Repository und der Ordner mit Ihren Alarmregeln.
Klicken Sie auf Speichern und lesen. Die Karte zeigt, wie viele Services, Alarme und Abweichungen kanman gefunden hat, und dass die Quelle nur gelesen wird.

Ist die Quelle nur in Ihrem Netz erreichbar, schalten Sie Über unseren Runner lesen ein: Ihr selbst gehosteter Runner liest sie und schickt kanman nur die Ergebnisse. Workspaces, die alles auf ihren Runnern ausführen, lesen immer so.

3. Über Ihren eigenen MCP-Server

Erlaubt Ihr Unternehmen Produktionssignale für eine KI nur über eigene MCP-Server, wählen Sie Über deinen MCP-Server und geben Sie seine Adresse ein. kanman nutzt dann nur die Lese-Tools des Servers (Metriken, Alarme, Dashboards, Checks) mit dem gespeicherten Token. Tools, die etwas ändern (Stummschaltungen, Bestätigungen, Bearbeiten), ruft kanman nie auf. Checkmk lässt sich genauso lesen.

Admins können daraus eine Regel für den ganzen Workspace machen: Schalten Sie auf derselben Seite unter Produktionssignale die Option Nur über freigegebene MCP-Server ein und tragen Sie die freigegebenen Server ein, einen pro Zeile. kanman lehnt dann direkte Verbindungen zum Monitoring ab, und eine Quelle, die der Regel nicht folgt, sagt auf ihrer Karte, warum.

4. Logs und Traces bleiben aus

Metriken, Alarme und Check-Zustände sind immer erlaubt. Logs und Traces können personenbezogene Daten oder Kommunikationsdaten enthalten, deshalb liest kanman sie nicht: Abfragen an eine Log- oder Trace-Datenquelle (etwa Loki oder Elasticsearch) werden abgelehnt, und ein Dashboard-Panel mit Logs wird nur verlinkt, nicht gelesen. Schalten Sie Logs und Traces für eine Quelle nur ein, wenn Sie einen Grund haben, und schreiben Sie ihn auf; kanman hält ihn an der Quelle fest. Jeder Lesezugriff wird von Zugangsdaten bereinigt, bevor kanman ihn speichert oder nutzt.

5. Wie kanman ein Problem findet

kanman reagiert nicht auf Rot. Es lernt, was für jeden Service normal ist:

den üblichen Bereich von Latenz, Fehlern, Traffic und Auslastung für jede Stunde der Woche aus den letzten drei Wochen, sodass eine ruhige Sonntagnacht und ein voller Montagmorgen beide normal sind
dauerhaft offene Probleme: Alarme und Checks, die seit einem Tag oder länger offen sind, gehören zum Normalen und alarmieren nie jemanden

Eine Verschiebung ist eine anhaltende Bewegung aus dem üblichen Bereich in die schädliche Richtung: langsamer, mehr Fehler, mehr Auslastung oder weniger Traffic. Bei der Fehlerquote achtet kanman außerdem darauf, wie schnell das Fehlerbudget verbraucht wird. Eine kurze Spitze, die sich von selbst erholt, ist keine Verschiebung. Neue Alarme laufen ebenfalls durch Ihre Rufbereitschaftsregeln.

6. Was dann passiert

Für jede Verschiebung eröffnet kanman eine Untersuchung pro Service und Ursache (eine zweite Verschiebung derselben Art schließt sich an), und die Rufbereitschaftsregeln des Teams entscheiden über den Incident: Schwellwert, Bereitschaftszeiten, wer benachrichtigt wird und was kanman darf.

Innerhalb von Minuten zeigt der Thread des Incidents, im Chat des Teams und in Ihren Incident-Kanälen:

die Verschiebung („p95-Latenz von Payment API liegt bei 500 ms statt etwa 125 ms seit 13:20“)
die Belege: die Abfragen, den Zeitraum und Links zu Ihren Dashboards und Panels
den nächsten Deploy oder Merge vor der Verschiebung und ob kanman diese Änderung gemacht hat
den Verantwortlichen aus Backstage, die Doku und Runbooks aus dem Team-Kontext
kanmans Einschätzung von Ursache und Auswirkung mit seiner Sicherheit
was kanman im Rahmen seiner Grenzen getan hat, und für die Person in Rufbereitschaft: was ein Mensch als Nächstes tun würde

Steht kanman darf auf Nur beobachten, schreibt kanman nur den Befund, die Entwürfe und die Nachricht an die Rufbereitschaft. Eine Fix-Story kommt wie jede andere Story auf das Board des Teams; eine Alarmregel braucht immer einen Menschen.

Sind die Metriken wieder im üblichen Bereich, wird die Untersuchung geschlossen und der Incident erholt sich.