Das kleinste Uptime-Monitoring-Skript der Welt

Wir haben ja bereits einmal ausführlich erklärt, wie klassisches Uptime-Monitoring aussieht. In diesem Artikel wollen wir uns, eher aus Spaß, am kleinstem Monitoring-Skript der Welt probieren. Wir haben es auf drei Zeilen gebracht. Trotzdem beinhaltet es eine Analyse des HTTP-Status-Codes, reagiert auf kaputte SSH-Zertifikate und sendet Alarmierungen per E-Mail, wenn es nötig ist.

Das Skript

#!/bin/bash
if [ `curl -I "$1" | grep 'HTTP/2 200' | wc -l` != 1 ]; then
    mail -s "Alert: problems curling $1" $2 < /dev/null
fi

Der Aufruf ist dann wie folgt:

./up.sh https://www.koality.io alarm@koality.io

Das war es auch schon. Prinzipiell passieren hier ein paar Dinge auf einmal:

• Wir machen einen curl Request auf den ersten Parameter, der auf der Kommandozeile übergeben wurde. Hier ist es wichtig, den Parameter -I mitzugeben, da uns

lediglich die Header und da im Speziellen der Status-Code interessieren.

• Danach kommt grep zum Einsatz. Wir prüfen, ob in dem Output des curl-Aufrufs ein HTTP/2 200 vorkommt.
• Der wc -l Aufruf zählt lediglich, wie häufig das HTTP/2 200 vorkommt. Sobald es nicht vorkommt, tritt der Alarmfall ein. Das Gute ist, wenn die URL

überhaupt nicht erreichbar ist, wirft curl einen Fehler aus und des Status wird ebenfalls nicht gefunden. Glück im Unglück also.

• Letzter Schritt: wir senden auf der Kommandozeile eine E-Mail mit mail an die E-Mail-Adresse, die wir als zweiten Parameter definiert haben.

Ganz einfach.

Was fehlt?

Es ist fast immer so: Der Einstieg in ein bestimmtes Thema ist einfach und vielleicht sogar mit drei Zeilen Code erreichbar. Wenn man sich aber ernsthaft damit beschäftigt, fallen einem sehr viele Details ein, die der einfache Ansatz noch nicht lösen kann.

• kontinuierliches Testen - Wir wollen natürlich alle Teste kontinuierlich ausführen. Am besten alle fünf Minuten. Automatisiert.
• verteilte Tests - Wenn unser kleines Skript den Server nicht erreichen kann, dann steht die Chance 50:50, dass der Fehler bei einem selbst liegt. Also

müsste man den gleichen Test noch mal aus einem anderen Rechenzentrum ausführen, um sicher zu gehen, dass der Fehler auf der Seite der zu untersuchenden Webseite liegt.

• andere Status-Codes - Unser Skript kann momentan nur auf den Status 200 prüfen. Es kann aber sehr sinnvoll sein auch andere Status-Codes zu überprüfen.

So könnte man zum Beispiel wichtige Weiterleitungen (301) oder nicht öffentliche Seiten (403) mit in die Überwachung nehmen.

• Kanäle - E-Mail ist so 90er Jahre. Wäre doch schön, die Nachrichten auch per Slack, Microsoft Teams oder anderen Kanälen zu bekommen.
• Fehlermeldungen - Bisher ist der Body der E-Mail noch leer. Das müsste man noch ändern und auch ein paar Details mit unterbringen, die wir jetzt

noch nicht sammeln.

• Status-Wechsel - Das Skript sendet jedes Mal, wenn eine Webseite nicht erreichbar ist, eine Fehlermeldung per E-Mail. Richtiger wäre es, wenn man nur

bei einem Status-Wechsel informiert wird.

• Hosting - Das Ganze kann nicht lokal laufen, da es ja rund um die Uhr im Einsatz ist. Des Weiteren kann es auch nicht im gleichen Rechenzentrum laufen,

wie die eigenen Systeme. Im Falle eines Ausfalls würden nämliche beide Systeme nicht erreichbar sein und keine Alarm-Meldungen würden die Verantwortlichen erreichen.

Wenn man all diese Punkte umsetzt, hat man sicherlich eine Menge über das Überwachen von Webseiten gelernt und kennt viele Fallstricke. Es kann aber einfacher sein, sich diesen Service einzukaufen, denn dann hat man all dies sofort out-of-the-box und kann sich um seine eigenliche Aufgabe kümmern: dem Entwickeln von Webseiten.