Den Zustand Ihrer Systeme kennen: Backstage und Checkmk

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

Backstage: Ihr 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: Ihr 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 Ihres Teams eröffnen und in jedem neuen Incident die Verantwortlichen aus Backstage nennen

Ein eigenes Dashboard hat kanman dafür nicht: Ihr 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 Sie fragen.

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: Legen Sie 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: Legen Sie einen Automation-Benutzer an (zum Beispiel automation), der die Hosts und Services des Teams lesen darf, und kopieren Sie 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 Sie Backstage öffnen, 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; Sie finden es unter Einstellungen › Secrets und können es dort später ersetzen.
Klicken Sie auf Verbindung testen: kanman prüft mit einer lesenden Anfrage, dass es den Katalog oder das Monitoring lesen darf.
Öffnen Sie im Team Team › Verbindungen. Fügen Sie auf der Karte des Systems Alle Alerts hinzu, um alles zu lesen, oder ordnen Sie 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 Ihrer 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 Ihr Team vor den Verbindungen angelegt hatte, hat kanman mit Token, Filtern und Gelesenem übernommen.

Systeme in Ihrem Netz

Ist Backstage oder Checkmk nur in Ihrem Firmennetz oder hinter einem VPN erreichbar, wählen Sie beim Verbinden über Ihren Runner. Dann liest Ihr 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 Team > Services und Rufbereitschaft (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 Ihr Unternehmen Produktionssignale nur über eigene MCP-Server, wählen Sie beim Hinzufügen der Quelle Über deinen MCP-Server. Metriken aus Prometheus, Grafana und InfluxDB funktionieren genauso: siehe Monitoring-Signale.

4. kanman fragen

Fragen Sie im Chat des Teams (oder in Allgemein, wo kanman alle Ihre 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 Ihres 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-Agenten über das Werkzeug service_status des kanman MCP.