kanman in Rufbereitschaft nehmen: Services und Signalquellen

Diese Anleitung nimmt kanman für einen Service in Rufbereitschaft: Du beschreibst den Service, verbindest, woher Alarme kommen und wo Fehler gelesen werden können, und legst fest, was kanman tun darf. Wie Incidents funktionieren, erklärt Incidents und Rufbereitschaft.

Services und Quellen anlegen können Inhaber und Admins des Workspaces. Alle Mitglieder sehen sie, können eine Verbindung testen und an Incidents arbeiten.

1. Service anlegen

1. Öffne den Reiter Mind des Teams, klicke auf Gedächtnis neben dem Board-Filter und wähle Services (/<workspace>/teams/<team>/mind/memory/services), oder frag kanman im Chat des Teams: „Zeig mir die Services“.
2. Klicke auf Neuer Service.
3. Gib einen Namen ein, zum Beispiel „Checkout-API“, und optional eine Beschreibung.
4. Hake die Repositorys an, aus denen der Service gebaut wird. Angeboten werden nur Repositorys, an denen das Team arbeiten darf; weitere fügst du unter Team > Repositories hinzu.
5. Trag die Umgebungen ein, zum Beispiel production mit ihrer URL.
6. Klicke auf Speichern. Der Service öffnet sich auf einer eigenen Seite (.../mind/memory/services/<service>).

Alarmquellen unter Team > Verbindungen verbindet deinen Backstage-Katalog und dein Monitoring (Checkmk, Prometheus, Grafana, InfluxDB), damit kanman weiß, wem was gehört und wie es deinen Systemen geht. Siehe Backstage und Checkmk und Monitoring-Signale. Tickets aus ServiceNow prüft kanman wie in ServiceNow beschrieben.

Dieselbe Zeile verbindet SonarQube. Wähle SonarQube, gib die Adresse ein, unter der du es öffnest, und ein User-Token mit dem Recht Browse, und schalte Über unseren Runner lesen ein, wenn SonarQube nur in deinem Netz erreichbar ist. kanman prüft die Verbindung stündlich und zeigt, ob sie funktioniert. Wenn kanman eine Änderung prüft, liest es das Quality Gate und die neuen Issues dieser Änderung selbst: Ein Gate, das bei neuem Code fehlschlägt, ist ein Befund, den kanman behebt, keine Frage an dich. Um das Token zu ersetzen, bearbeitest du die Quelle und gibst das neue ein; zum Entfernen löschst du die Quelle und das Secret unter Einstellungen › Secrets.

2. Festlegen, was kanman tun darf

Auf der Seite des Service unter Rufbereitschaft:

Jede Einstellung wird gespeichert, sobald du sie änderst (daneben erscheint Gespeichert, Rückgängig nimmt sie zurück). Alle Einstellungen beschreibt Rufbereitschaft-Einstellungen.

Incident-Orte in Slack oder Microsoft Teams

kanman postet Incidents an den Orten, an denen dein Team mit kanman spricht. Verbinde Slack oder Microsoft Teams und füge die Kanäle des Teams unter Team > Verbindungen, Chats, hinzu, wie in Slack und Microsoft Teams beschrieben. Hake dann in der Rufbereitschaft unter Incident-Orte die Kanäle an, die Incidents dieses Service erhalten sollen, zum Beispiel einen eigenen Incident-Kanal. Ist nichts angehakt, erhalten alle Kanäle des Teams sie.

Jeder Incident ist ein Thread pro Ort: kanman eröffnet ihn mit Titel, Schweregrad und Service, ergänzt jede Erkenntnis und Aktion als Antwort und postet am Ende die Auflösung. Incident-Posts erscheinen im Chatverlauf des Teams in der App wie jede andere Nachricht von kanman, dort mit jeder Erkenntnis in deiner Sprache.

3. Alarm-, Paging- und Log-Systeme verbinden

Alarm-Tools, Paging, Fehlertracking, Statusseiten und Log-Systeme werden einmal für den Workspace verbunden und dann von jedem Team genutzt, das sie braucht. Jedes Team entscheidet, was es erreicht.

Ein System verbinden (Inhaber und Admins)

1. Öffne Einstellungen › Verbindungen, such das System (zum Beispiel Datadog, PagerDuty oder Sentry) und verbinde es: Gib der Verbindung einen Namen, trag die Adresse ein, wo es eine gibt, die Zugangsdaten und die Einstellungen, nach denen die Karte fragt (zum Beispiel die Datadog-Site, die Sentry-Organisation oder die PagerDuty-Region). kanman speichert die Zugangsdaten als Workspace-Secret; du findest sie unter Einstellungen › Secrets.
2. Wähle, von wo kanman das System erreicht: aus kanmans Cloud für Systeme im Internet oder über deinen Runner für Systeme in deinem Netz (zum Beispiel ein Checkmk, Elastic oder Prometheus, das dein Unternehmen selbst betreibt). Über den Runner verbindet sich kanmans Cloud nie mit dem System, sondern dein selbst betriebener Runner; in deinem Netz darf die Adresse auch http:// sein.
3. Für Systeme, die Alarme schicken, trägst du ein Signatur-Secret für Webhooks ein: einen langen Zufallswert, den du auch im Tool einträgst, oder das Signatur-Secret, das das Tool selbst erzeugt (PagerDuty, Sentry). Die Verbindungskarte zeigt danach die Adresse unter Webhooks an, mit einer Schaltfläche zum Kopieren.
4. Klicke auf Verbindung testen. kanman prüft mit lesenden Anfragen, was die Zugangsdaten dürfen, und zeigt es pro Bereich (Alarme, Logs, Rufbereitschaft, …).

Festlegen, was das Team erreicht

Öffne das Team, klicke auf Team und wähle Verbindungen. Die Karte Verbindungen oben listet jedes verbundene System des Workspaces; öffne eines. Für jedes gilt:

• Was zu diesem Team gehört: Füge hinzu, was vom System zum Team gehört, und richte es auf Das ganze Team oder einen deiner Services. Alle Alerts übernimmt alles, was das System schickt. Oder ordne zu, wie das System einen Service nennt, zum Beispiel den Datadog-Service checkout, das Sentry-Projekt checkout-api, die Loki-Abfrage {app="checkout"}, die Log-Gruppe /ecs/checkout oder die Checkmk-Hosts pay-prod-. Alarme öffnen Incidents nach den Rufbereitschafts-Einstellungen ihres Services; für das ganze Team wählt kanman den Service anhand des Servicenamens im Alarm. Untersucht kanman einen Incident eines Services, liest es genau die Logs, Traces und Fehler, die ihm zugeordnet sind.
• Was kanman dort tun darf: eine Zeile pro Aktion, jeweils Aus, Erst fragen oder Automatisch, innerhalb der Grenze, die ein Inhaber oder Admin für den Workspace gesetzt hat.

Team-Leads ändern Zuordnungen und Modi; alle anderen sehen sie. Quellen, die dein Team früher angelegt hatte, hat kanman mit ihren URLs und Secrets übernommen: Sie erscheinen als Frühere Webhook-URL, und Alarme an eine alte URL kommen weiter an.

Was kanman in verbundenen Systemen tun darf

Bei Erst fragen zeigt kanman auf der Incident-Seite, was es tun würde, mit Freigeben und Ablehnen; die Zeitleiste des Incidents sagt, wann es auf dich wartet und was passiert ist. Ein Service auf Nur beobachten bekommt nichts davon. Jede Aktion, auch eine abgelehnte oder fehlgeschlagene, steht in der Aktivität des Teams.

Die Tools einrichten

Die URL hat diese Form:

https://api.kanman.ai/functions/v1/extension-webhook/<connection>

„Das Secret“ ist im Folgenden das Signatur-Secret für Webhooks der Verbindung.

Prometheus Alertmanager: Leg einen Receiver an und leite deine Alarme dorthin.

receivers:
  - name: kanman
    webhook_configs:
      - url: https://api.kanman.ai/functions/v1/extension-webhook/<connection>
        send_resolved: true
        http_config:
          authorization:
            type: Bearer
            credentials: <secret>

kanman liest severity und service (oder job, app) aus den Labels sowie summary und description aus den Annotations. Damit kanman Alarme stummschalten kann, trag die Adresse des Alertmanagers in der Verbindung ein.

Grafana-Alerting: Leg einen Contact Point vom Typ Webhook mit der URL an und trag das Secret als HMAC-Signatur-Secret ein (oder als Bearer-Zugangsdaten). Nutze den Contact Point in einer Notification Policy.

Datadog: Leg unter Integrations › Webhooks einen Webhook kanman mit der URL, dem Header {"Authorization": "Bearer <secret>"} und dieser Payload an und erwähne @webhook-kanman in den Monitoren, die kanman erreichen sollen:

{"id":"$ID","alert_id":"$ALERT_ID","aggregate":"$AGGREG_KEY","title":"$EVENT_TITLE","transition":"$ALERT_TRANSITION","priority":"$ALERT_PRIORITY","alert_type":"$ALERT_TYPE","body":"$EVENT_MSG","link":"$LINK","tags":"$TAGS","date":"$DATE"}

Für Logs und APM-Traces sind die Zugangsdaten der Verbindung API-Key und Application-Key als <API-Key>:<Application-Key>.

New Relic: Leg eine Webhook-Destination mit der URL und dem Secret als Bearer-Token an und füge sie einem Workflow mit der Standard-Payload hinzu. Für Logs trägst du die Konto-ID in der Verbindung ein.

PagerDuty: Leg unter Integrations › Generic Webhooks (v3) ein Abo mit der URL und den Events incident.triggered, incident.resolved, incident.reopened, incident.escalated und incident.priority_updated an. PagerDuty zeigt ein eigenes Signatur-Secret: Trag es als Signatur-Secret für Webhooks der Verbindung ein. Zum Bestätigen, Auflösen und Alarmieren braucht die Verbindung einen REST-API-Key, die E-Mail des PagerDuty-Nutzers, als der kanman handelt, und zum Alarmieren den Service, über den kanman alarmiert.

Opsgenie: Leg eine Webhook-Integration mit der URL und dem Header Authorization: Bearer <secret> an. Zum Bestätigen, Schließen und Alarmieren braucht die Verbindung einen API-Key, die Region und zum Alarmieren das Responder-Team.

Sentry: Leg eine interne Integration mit der URL als Webhook-URL an, schalte Alert Rule Action und die Issue-Events ein und trag ihr Client Secret als Signatur-Secret für Webhooks der Verbindung ein. Füge „Send a notification via kanman“ den Alert-Regeln hinzu, die kanman erreichen sollen. Ein neues Issue öffnet einen Incident, ein wiederkehrendes öffnet ihn erneut, das Auflösen des Issues löst ihn auf.

Amazon CloudWatch: Leg auf dem SNS-Topic deiner Alarme ein HTTPS-Abo mit der URL plus ?key=<secret> an. kanman bestätigt das Abo selbst und prüft die AWS-Signatur jeder Nachricht; trag die Topic-ARN in der Verbindung ein, um nur dieses Topic anzunehmen. Kennzeichne den Schweregrad in der Alarm-Beschreibung, zum Beispiel [critical] Checkout 5xx.

Azure Monitor: Füge in der Aktionsgruppe eine Webhook-Aktion mit der URL plus ?key=<secret> hinzu und schalte das allgemeine Alarmschema ein.

Atlassian Statuspage: Leg einen Webhook-Abonnenten mit der URL plus ?key=<secret> an. Komponentenausfälle und Incidents erreichen kanman.

Logs, Fehler und Traces

Log-, Trace- und Fehler-Systeme schicken nichts: kanman liest sie, während es einen Incident untersucht, für das Zeitfenster um den ersten Alarm, über die Zuordnungen des Services. Verbinde sie unter Einstellungen › Verbindungen:

kanman behält nur die Fehlerzeilen, die es in der Zeitleiste des Incidents nennt. Auf Nachfrage liest kanman diese Systeme auch für dich, zum Beispiel „Was sagt Sentry zu Issue 4504?“ oder „Wer hat bei PagerDuty Rufbereitschaft?“.

Eigene Quellen des Teams

Auf der Service-Seite fügt Quelle hinzufügen hinzu, was zum Team selbst gehört:

• Uptime-Check: kanman ruft eine URL nach Zeitplan auf. Einstellungen: URL, Methode, Intervall (60 Sekunden oder mehr), Timeout, erwartete Statuscodes (zum Beispiel 200 oder 2xx), Text, den die Antwort enthalten muss, Request-Body, wie viele Fehlschläge in Folge einen Incident öffnen (Standard 2), der Schweregrad und Request-Header für geschützte Endpunkte (ihre Werte werden verschlüsselt gespeichert). kanman prüft nur öffentliche Adressen. Der erste erfolgreiche Check nach einem Fehler löst den Incident auf. Aus mehreren Regionen prüfen: Wähle bis zu fünf Regionen; ein Check gilt nur als fehlgeschlagen, wenn die meisten fehlschlagen, sodass ein Netzproblem in einer Region niemanden alarmiert. Regionen, die fehlschlagen müssen ändert diese Zahl.
• Anderes Tool: Alarme im allgemeinen Format von kanman, signiert mit dem Secret der Quelle, beschrieben unter Rufbereitschafts-Einstellungen.
• Kubernetes-Logs: Namespace, Label-Selektor und Container; dein selbst betriebener Runner liest sie in deinem Netz.

Verbindung testen an einer Quelle führt einen Check einmal aus, liest Kubernetes-Logs oder zeigt, ob Alarme angekommen sind; es öffnet nie einen Incident.

4. Ausprobieren

Sende einen Testalarm aus deinem Tool, oder lass einen Uptime-Check auf eine Seite zeigen, die einen Fehler liefert. Innerhalb einer Minute erscheint der Incident in deiner Unterhaltung mit kanman, bei den Incidents des Teams (“1 Incident offen” im Team-Status) und in deinem Kanal, und kanman beginnt zu posten, was es findet.