Den Zustand deiner Systeme kennen: Backstage und Checkmk

Diese Anleitung verbindet zwei Quellen, die kanman über die Systeme deines Teams informieren:

Backstage: dein Softwarekatalog. kanman lernt Komponenten, Systeme, APIs und Ressourcen kennen, wer für sie verantwortlich ist (mit den Personen jeder Gruppe), wovon sie abhängen, wo Dokumentation und Repository liegen und in welcher Lebensphase sie sind.
Checkmk: dein Monitoring. kanman liest den Zustand von Hosts und Services und ihre Probleme, einschließlich Bestätigungen und geplanter Wartungen.

Damit kann kanman:

im Chat „Wie geht es payment-api?“ mit einer kurzen Antwort und einer Karte beantworten: Zustand, aktuelle Probleme, letzte Auslieferungen und gemergte Änderungen, offene Incidents, CI, die Verantwortlichen und Links zu Doku, Backstage, Repository und Checkmk
„Wem gehört payment-api?“ und „Wie geht es unseren Systemen?“ beantworten
aus Checkmk-Problemen Incidents nach den Regeln der Rufbereitschaft deines Teams eröffnen und in jedem neuen Incident die Verantwortlichen aus Backstage nennen

Ein eigenes Dashboard hat kanman dafür nicht: Dein Monitoring bleibt, wo es ist. kanman meldet sich nur, wenn es wegen eines Signals tätig wird (es hat einen Incident eröffnet, eine Fix-Story angelegt oder einen Revert seiner eigenen Änderung vorgeschlagen), und antwortet sonst, wenn du fragst.

den Katalog als Team-Kontext nutzen, sodass Fragen zu einem System seine Beschreibung, Verantwortlichen und Abhängigkeiten finden

Systeme verbinden können Inhaber und Admins des Workspaces; Team-Leads ordnen sie dem Team zu. Alle Mitglieder sehen sie, können sie sofort lesen lassen und kanman nach den Systemen fragen.

1. Token vorbereiten

Backstage: Leg ein Token an, das Backstage für seine Katalog-API akzeptiert, zum Beispiel ein statisches Token unter backend.auth.externalAccess. kanman liest nur den Katalog.

Checkmk: Leg einen Automation-Benutzer an (zum Beispiel automation), der die Hosts und Services des Teams lesen darf, und kopiere sein Automation-Secret.

2. Verbinden

Backstage und Checkmk werden einmal für den Workspace verbunden und dann von jedem Team genutzt, das sie zuordnet.

Ein Inhaber oder Admin öffnet Einstellungen › Verbindungen, sucht Backstage oder Checkmk und verbindet es:
- Backstage: die Adresse, unter der du Backstage öffnest, zum Beispiel https://backstage.example.com, und das Token.
- Checkmk: die Adresse der Site, zum Beispiel https://monitoring.example.com/mysite, den Automationsuser als Nutzer und sein Automationssecret als Secret.
kanman speichert Token oder Secret als Workspace-Secret; du findest es unter Einstellungen › Secrets und kannst es dort später ersetzen.
Klicke auf Verbindung testen: kanman prüft mit einer lesenden Anfrage, dass es den Katalog oder das Monitoring lesen darf.
Öffne im Team Team › Verbindungen. Füge auf der Karte des Systems Alle Alerts hinzu, um alles zu lesen, oder ordne nur zu, was zum Team gehört: bei Backstage seine Owner-Gruppen (zum Beispiel group:default/payments), bei Checkmk Teile von Hostnamen (zum Beispiel pay-), jeweils einem deiner Services.
kanman liest das System sofort und danach nach Zeitplan (alle sechs Stunden bei Backstage, alle zwei Minuten bei Checkmk). Die Karte Katalog und Monitoring zeigt, was es gefunden hat („142 Katalogeinträge · 23 Systeme · 6 Owner“, „38 Hosts · 2 Probleme“) oder warum es nicht lesen konnte; Jetzt synchronisieren liest sofort neu.

Schaltet das Team seine Zuordnungen ab, pausiert es das Lesen; die Verbindung bleibt für die anderen Teams. Quellen, die dein Team vor den Verbindungen angelegt hatte, hat kanman mit Token, Filtern und Gelesenem übernommen.

Systeme in deinem Netz

Ist Backstage oder Checkmk nur in deinem Firmennetz oder hinter einem VPN erreichbar, wähle beim Verbinden über deinen Runner. Dann liest dein selbst betriebener Runner das System, auch unter einer http://-Adresse, und schickt kanman nur, was er gefunden hat; kanmans Cloud verbindet sich nie damit. Der Runner nutzt das gespeicherte Secret oder eine gleichnamige Variable in seiner Umgebung. In einem Workspace, der alles auf seinen Runnern ausführt, wird jedes System so gelesen. Ist kein Runner online, sagt die Karte, dass sie auf einen wartet, und kanman liest das System, sobald wieder ein Runner da ist.

3. Checkmk mit der Rufbereitschaft verbinden

Checkmk-Probleme eröffnen Incidents über die Services des Teams unter Mind > Gedächtnis > Services (siehe Services und Signalquellen). kanman ordnet einen Host oder Service-Check einem Service des Teams über den Namen zu: Der Host payment-api-prod-01 oder der Check HTTP payment-api gehört zum Service payment-api. Eine Backstage-Komponente kann ihre Hosts mit der Annotation checkmk.com/hosts: pay-prod-01, pay-prod-02 genau nennen.

Es gelten die üblichen Regeln der Rufbereitschaft: Schweregrad-Schwelle, Bereitschaftszeiten, wer benachrichtigt wird und was kanman darf (darunter Nur beobachten). Außerdem:

Das erste Lesen einer Checkmk-Site ist eine Ausgangslage: Probleme, die es schon gibt, merkt sich kanman, meldet sie aber nicht. Das Verbinden von Checkmk löst also keine Flut von Incidents aus.
Bestätigte Probleme und Probleme in einer geplanten Wartung eröffnen nie einen Incident.
Zusammenhängende Probleme eines Service landen in einem Incident; pro Lesevorgang meldet kanman höchstens 20 neue Probleme.
Probleme, die seit einem Tag oder länger offen sind, gehören zum Normalen und alarmieren nie jemanden, egal wie viele es sind.
Ein Problem, das wieder OK ist, löst seinen Teil des Incidents auf; wenn nichts mehr feuert, ist der Incident gelöst.
Schweregrade: Host ausgefallen ist kritisch, nicht erreichbar und CRIT sind hoch, WARN ist mittel, UNKNOWN ist niedrig.
Hosts, die zu keinem Service passen, werden festgehalten, eröffnen aber keinen Incident.

Jeder neue Incident nennt die Verantwortlichen des Service aus Backstage mit ihren Personen, damit die Person in Bereitschaft weiß, wen sie dazuholen kann.

kanman liest Checkmk nur: Es bestätigt nie ein Problem und plant nie ein Wartungsfenster. Erlaubt dein Unternehmen Produktionssignale nur über eigene MCP-Server, wähle beim Hinzufügen der Quelle Über deinen MCP-Server. Metriken aus Prometheus, Grafana und InfluxDB funktionieren genauso: siehe Monitoring-Signale.

4. kanman fragen

Frag im Chat des Teams (oder in Persönlich, wo kanman alle deine Teams durchsucht):

„Wie geht es payment-api?“ oder „How is payment-api doing?“
„Wem gehört payment-api?“
„Wie geht es unseren Systemen?“ oder „Was ist kaputt?“

kanman antwortet in wenigen Sätzen und hängt die Karte des Systems an. Es sagt, wann das Monitoring zuletzt gelesen wurde, und rät nie eine Ursache, die die Fakten nicht zeigen. In einem Workspace, der alles auf seinen Runnern laufen lässt, formuliert das Modell deines Runners die Antwort.

Eröffnet kanman einen Incident, trägt seine Nachricht im Chat des Teams Wie geht es dem System?: Ein Tipp fragt kanman nach dem Service und bringt dieselbe Karte. Die Fix-Story, die kanman anlegt, und ein Revert-Vorschlag kommen als Antworten unter diese Nachricht.

Entwicklerinnen und Entwickler bekommen dieselben Fakten in ihrem Coding-Werkzeug über das Werkzeug service_status des kanman MCP.