Zeitpläne, Befunde und Rollouts

Ein Zeitplan lässt Heinzel zu festen Zeiten nach Ihren Servern sehen, ohne dass jemand dabei ist. Was es findet und nicht allein beheben darf, wird ein Befund. Und eine Aufgabe, die auf vielen Servern dasselbe tun soll, ist ein Rollout: erst einer, dann alle.

Einen Zeitplan anlegen

Die Aufgabe des Beispiels:

Eingabe: Spiele auf allen Servern die anstehenden Sicherheitsupdates ein und prüfe danach, ob alle Dienste laufen. Was das Journal eines Servers ausnimmt, lass stehen und melde es. Kein Neustart.

Wer Stufe, Aufgabe oder Modell ändert, wird Besitzer des Zeitplans; er läuft im Namen dieser Person und so weit, wie eine Session von ihr allein gehen dürfte. Ein Zeitplan gehört einer Gruppe, einer Person oder allen; die Personen dieser Gruppe ändern, pausieren und starten ihn. „Jetzt ausführen“ in der Liste startet ihn sofort.

Was in der Nacht passiert

Ein Lauf ist eine unbeaufsichtigte Session je Server, und sie kann niemanden fragen. Lesebefehle laufen. Änderungen laufen, wo der Zeitplan auf rwx steht und Mandant, Besitzer und Server es erlauben. Alles andere wird übersprungen, im Bericht unter „Braucht einen Operator“ genannt und eine Woche auf der Seite Freigaben aufbewahrt, wo jemand es in eine eigene Session übernimmt. Eine Servergruppe kann ein Wartungsfenster tragen (Wochentage, von, bis); außerhalb liest ein Lauf nur.

Am Morgen eine Mail, als Text und als HTML: zuerst die Hosts, die jemanden brauchen, dann eine Zeile je Host, bei dem alles in Ordnung ist.

Das ganze Beispiel mit Bildern aus der Nacht: Sicherheitsupdates jede Nacht.

Befunde

Was ein Lauf als Problem gefunden hat, steht unter Befunde: ein Eintrag je Server und Problem. In der nächsten Nacht wieder gesehen, bleibt es ein Eintrag mit Zähler; sieht ein späterer Lauf desselben Zeitplans es nicht mehr, schließt es sich von selbst. Einen Befund übernehmen Sie, schließen ihn von Hand oder starten daraus eine Session: Die vorgeschlagene Aufgabe steht schon im Formular, lesen Sie sie, bevor Sie starten.

Rollouts: dasselbe auf vielen Servern

Neue Session, „Auf allen parallel dasselbe“: Server anhaken, von Hand oder nach Tag, Aufgabe einmal schreiben. Der Rollout läuft zuerst auf dem ersten Server als gewöhnliche Session mit jeder Freigabe, die sie braucht. Ist sie durch, liest jemand, der freigeben darf, diese Session und sagt Go. Dann läuft die Aufgabe auf den anderen, vier gleichzeitig.

Auf den anderen Servern laufen ohne Rückfrage nur die Befehle, die auf dem ersten ein Mensch freigegeben hat und die dort gelungen sind, keiner davon unumkehrbar, als derselbe Text und in derselben Reihenfolge, jeder erst, wenn der davor gelungen ist. Alles andere fragt wie immer. Jeder Server behält seine eigene Session, sein Protokoll und seinen Stopp-Knopf.

Alarme aus dem Monitoring

Lassen Sie Ihr Monitoring einen Alarm an Heinzel Pro schicken, und Heinzel sieht sofort nach: Unter Einstellungen, Anbindungen erzeugen Sie ein Token; das Monitoring sendet es als Bearer-Token an /api/alerts/<mandant>. Der Webhook von Alertmanager wird angenommen, wie er ist; jedes andere System sendet JSON mit host, title und text.

$ curl -X POST https://app.heinzel-pro.de/api/alerts/beispiel \
  -H "Authorization: Bearer $HEINZEL_ALERT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"host": "web03.example.com",
       "title": "Platte /var zu 92 % voll",
       "text": "Schwelle 90 % seit 10 Minuten überschritten"}'

Ist der Host einer Ihrer Server, startet dort eine Session, die nur liest und Ursache und Lösungsvorschlag berichtet; die Antwort auf den Aufruf enthält die Adresse der Session. Derselbe Alarm findet innerhalb einer Stunde seine Session wieder, und höchstens zwanzig Sessions starten pro Stunde. Umgekehrt markiert Heinzel Pro Änderungen im Monitoring: Mit einem Endpunkt, der Annotationen annimmt wie Grafana, erscheint jeder ausgeführte Befehl in den Graphen.

Was Sie benachrichtigt

Unter Einstellungen, Alarme: Mailadressen und ein Webhook (Slack, Teams, Mattermost, generisches JSON), und je Ereignis ein Haken: Freigabe nötig, Befehl fehlgeschlagen oder abgelehnt, Host-Key geändert, geplanter Lauf beendet, wiederholt fehlgeschlagene Anmeldungen, Benutzer angelegt, eine zu lange wartende Freigabe, ein Modell, das der Anbieter abschaltet, und eine Wochenmail mit dem, was liegen geblieben ist. Ereignisse, die ein Upgrade mitbringt, sind aus, bis Sie sie einschalten.

Die API

Eine Pipeline, die Heinzel ein Deployment prüfen lässt, ein Skript, das Server anlegt, ein Bericht, der jeden Morgen abgeholt wird: Unter Verwaltung, API-Tokens erzeugt ein Administrator ein Token mit den Bereichen read, sessions und servers. Es handelt im Namen der Person, die es erzeugt hat, und darf nie mehr als sie. Und es gibt nie einen Befehl frei: Es sieht, was wartet, und kann ablehnen; eine Freigabe ist ein Mensch im Browser.

# Eine Session starten
$ curl -X POST https://app.heinzel-pro.de/api/v1/beispiel/sessions \
  -H "Authorization: Bearer hzp_…" \
  -H "Content-Type: application/json" \
  -d '{"server": "web03.example.com",
       "task": "Prüfe, warum nginx seit dem Deploy um 14:02 502 liefert"}'

# Ihren Zustand und die letzte Antwort lesen
$ curl -H "Authorization: Bearer hzp_…" \
  https://app.heinzel-pro.de/api/v1/beispiel/sessions/0199e2c4-…

# Den Änderungsnachweis als Markdown
$ curl -H "Authorization: Bearer hzp_…" \
  https://app.heinzel-pro.de/api/v1/beispiel/sessions/0199e2c4-…/record

Ein unbekannter Mandant und ein falsches Token bekommen beide 401 mit demselben Inhalt; ein Aufruf außerhalb des Bereichs 403; einer, der so nicht geht (eine Session, die beschäftigt ist), 409. 120 Aufrufe pro Minute und Adresse sind die Vorgabe. Das Skript heinzel aus dem Repository ist eine Hülle um diese Aufrufe für die Shell.