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.

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.

Die Liste ist gebaut wie die der Sessions: Reiter für Alle, Läuft, Zuletzt fehlgeschlagen und Pausiert, dann eine Zeile je Zeitplan mit Gruppe, Name und Aufgabe, wo er läuft mit seinen Rechten in Worten, und rechts seinem Takt in Worten („So um 04:00“) über den Cron-Feldern, jedes beschriftet und die gesetzten hervorgehoben, mit dem nächsten Lauf. Nach dem nächsten Lauf sortiert, steht die Liste unter Überschriften: zuerst, was mehrmals am Tag läuft, dann jeder Tag mit seinem Datum, pausierte Zeitpläne zuletzt. Das Zeichen vorn sagt, wie der letzte Lauf ausging. Jeder Kopf sortiert; das Menü sortiert auch nach Cron-Ausdruck und Rechten. Mit den Kästchen führen Sie mehrere Zeitpläne auf einmal aus, pausieren oder aktivieren sie. Ein Klick auf die Zeile öffnet die Seite des Zeitplans: Aufgabe, wann, wo und mit welchen Rechten, die letzten Läufe mit ihren Sessions, ein laufender Lauf mit seinen Schritten, und die Knöpfe Jetzt ausführen, Pausieren, Bearbeiten, Entfernen und, während er läuft, Anhalten.

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.

Die ganze Nacht mit Bildern, als Kochrezept: 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.

Die Seite ist aufgebaut wie die Liste der Sessions: links eine Zeile je Befund mit seiner Schwere, dem Server, dem Befund, dem Zeitplan, der ihn sah, und wann er zuerst auftrat; rechts der gewählte Befund mit Woher (Zeitplan, Lauf, Server), Warum er hier steht (neu, schlimmer als zuvor, wieder da, nachdem ihn jemand geschlossen hatte, oder auf Wunsch wieder erinnert), Was die Prüfung sah und ihrem Vorschlag. Mit den Kästchen schließen Sie mehrere auf einmal.

Rollouts: dasselbe auf vielen Servern

Neue Session, „Dasselbe auf vielen“: Aufgabe einmal schreiben, Server wählen, Stufe wählen. Die Stufe gilt für jede Session des Rollouts; auf „Ändert allein“ wartet keine davon auf eine Freigabe. Höchstens 50 Server.

Die Server stehen in einer Liste wie unter Server, mit ihrer Last von jetzt und dem Tag der letzten Session. Ein Klick auf eine Zeile wählt den Server. Die Suche nimmt Namen, reguläre Ausdrücke und #tag; „Alle Treffer dazu“ oder das Kästchen in der Leiste wählt alles, was passt. Die Leiste zählt die gewählten Server, „Auswahl aufheben“ wählt alle wieder ab. Mit „ganz“ im Spaltenkopf stehen die Server mit ganzem Namen statt mit dem ersten Teil da.

„Wie laufen sie?“ hat drei Antworten:

Unter „Wann?“ startet ein Rollout jetzt oder zu einer Uhrzeit, wie eine einzelne Session. Bis dahin steht er mit seinem ersten Server in der Liste der Sessions; wer ihn stoppt, sagt ihn ab.

Nach der Freigabe von „Erst einer, dann alle“ laufen auf den anderen Servern 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.

Die Seite des Rollouts zeigt seine Sessions mit denselben Zeilen wie die Liste der Sessions: Aufgabe, Server und letzte Änderung, davor ein Zeichen für den Zustand. Eine Zeile öffnet die Session, ein Spaltenkopf ordnet die Liste. Darunter stehen nummeriert die Server, die noch warten, in der Reihenfolge, in der sie drankommen.

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://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://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://heinzel-pro.de/api/v1/beispiel/sessions/0199e2c4-…

# Den Änderungsnachweis als Markdown
$ curl -H "Authorization: Bearer hzp_…" \
  https://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.