Das wird eine längere Angelegenheit -, aber keine Sorge, es gibt ein TLDR vorab ;) GUI for check_httpv2 ist eine lokale Anwendung zum Überwachen von Webseiten auf Status, Antwortzeiten, Versionen, Zertifikate, Texte und mehr. Die App unterstützt Profile, hat einen Scheduler und speichert historische Daten als CSV, kompatibel mit Grafana. Und logisch: Open Source.
TLDR
TLDR noch zu lang? Ein Video folgt direkt im Anschluss - oder einfach direkt zu GitHub.
Was macht das überhaupt? Mit GUI for check_httpv2 lässt sich prüfen, ob Webseiten und sonstige HTTP-Dienste online sind, welche Version sie nutzen, ob Zertifikate gültig sind, wie schnell sie antworten, ob Weiterleitungen funktionieren, bestimmte Texte vorkommen und so weiter.
Für wen/was ist das gedacht? GUI for check_httpv2 eignet sich, um eine überschaubare Anzahl von URLs zu monitoren. Ein, zwei Dutzend funktionieren optimal, bei spätestens 50 dürfte es etwas unübersichtlich werden. Und ganz ehrlich: In der Größenordnung würde ich dann doch über ein ganzes Checkmk nachdenken - ist auch Open Source! Aber wenn Ihr einfach 20 Webseiten für Kunden, den Verein, Schule oder Freunde betreibt, könnte GUI for check_httpv2 eine gute Lösung sein.
Was ist das? Unsere GUI for check_httpv2 ist eine kleine Eigenentwicklung, im Wesentlichen eine grafische Oberfläche für check_httpv2 mit ein paar Extras. check_httpv2 selbst stammt von der Checkmk GmbH und ist ein inoffizieller Nachfolger von check_http, dem Standard zum Überwachen von Webseiten seit 20 Jahren.
Was kann das? Unsere GUI ist Feature complete, sprich alle Funktionen von check_httpv2 können über die grafische Oberfläche genutzt werden - welche genau das sind, später. Darüber hinaus gibt es noch die Möglichkeit Profile für Webseiten-Checks anzulegen und diese per Scheduler automatisch laufen zu lassen. Die Ergebnisse können dann in Grafana visualisiert werden.
Wo gibt's das?
Zunächst mal nur hier im Artikel, die Downloads sind unten. Künftig wird das Tool dann auch auf Github zu finden sein, Aktualisierung an dieser Stelle folgt. Okay, es gibt direkt alles auf GitHub.
Wie ist das umgesetzt? Ziemlich simpel: Eine kleine Python-App, die im Wesentlichen Profile und Scheduler steuert sowie den lokalen Webserver für die GUI betreibt - GUI for check_httpv2 läuft im Browser. Dazu kommen eine HTML- und eine CSS-Datei für das Design und letztlich eine Javascript-Datei mit der eigentlichen Funktion. Die Entwicklung war eine Zusammenarbeit von ChatGPT und mir: Funktionen, Konzept, Design etc. stammen von mir, ChatGPT hat die Syntax übernommen. Und keine Sorge: Die eigentliche Funktionalität steckt ja in check_httpv2, und das stammt von echten Entwicklern ;)
Wie funktioniert das? Es genügen die Angabe einer URL und ein Klick auf Run Check, um die URL prüfen zu lassen. Ihr bekommt dann eine Zusammenfassung mit HTTP-Status, Antwortzeit und einigen weiteren Daten sowie den generierten Kommandozeilenbefehl und dessen rohe Ausgabe. Und natürlich: Einen Status. Solche Checks lassen sich dann auch planen und letztlich in Grafana abbilden.
Das Projekt
Die Idee war naheliegend: Checkmk hat check_httpv2 als Nachfolger des betagten Standard-Monitoring-Tools check_http entwickelt, das aus der Nagios-Welt stammt und seit gut 20 Jahren das vielleicht meistgenutzte Tool zum Prüfen von HTTP-Status ist.
Das neue check_httpv2 läuft als Standalone-Programm im Terminal, vor allem aber innerhalb von Checkmk. Wenn man nur ein paar Websiten monitoren möchte, ist ein ganzes Checkmk vielleicht etwas zu viel des Guten - die Lernkurve ist schon steil und lang. Im Terminal wiederum ist check_httpv2 zwar relativ einfach zu nutzen, aber es sind doch ziemlich viele Optionen und ohne weitere Skripterei lassen sich nur Ad-hoc-Checks durchführen, kontinuierliches Monitoring nicht. Und darum geht es ja letztlich: URLs dauerhaft überwachen, um zum Beispiel festzustellen, ob der Webhoster die versprochene Verfügbarkeit einhält.
Nachdem ich einiges über das check_httpv2 geschrieben hatte, kam dann der Wunsch auf, es auch eigenständig via GUI für kleinere Monitoring-Projekte nutzen zu können.
Meine Wunschliste war von Anfang an relativ klar:
- Browser-basierte GUI
- Alle check_httpv2-Features abgebildet
- Speichern von Check-Konfigurationen in Profilen
- Automatische Checks in Intervallen
- Abbildung in Grafana
- Technik: Python, Javascript, HTML, CSS
Das ist alles kein Hexenwerk, aber jede Menge Fleißarbeit und nur möglich dank KI. Ich habe zwar immer wieder mal kleinere Tools gebaut, auf Tutonaut zum Beispiel allerlei AutoHotkey-Kram, aber hier war der Aufwand doch ungleich höher - letztendlich sind es 2.305 Zeilen Code geworden. Für einen Entwickler kein großes Thema, für einen einzelnen freien Journalisten für einen unbezahlten Artikel absolut nicht zu leisten ohne KI.
Limits: Alle check_httpv2-Features lassen sich einfach und problemlos über die GUI nutzen. Scheduler und Profilmanager als zusätzliche Funktionen stammen allerdings von mir selbst und sind sicherlich nicht perfekt umgesetzt. Zumindest der Profilmanager ist nicht zu 100 Prozent intuitiv.
Alltagsbetrieb: Am Ende des Tages ist das Ding dazu gedacht ein paar Profile aufzusetzen, den Scheduler zu starten und sich danach nur noch die hübschen Ergebnisse in Grafana anzuschauen - Set-up and forget funktioniert ziemlich gut.
Basis: check_httpv2
Kein Grund alles doppelt zu schreiben: Für IP-Insider.de habe ich bereits einen umfangreichen Artikel zu check_httpv2 geschrieben, der mehr zu den Hintergründen verrät, wie das Ding inner- und außerhalb von Checkmk funktioniert und wie man es kompiliert (Binaries stellt Checkmk nämlich nicht zur Verfügung - unsere GUI liefert sie mit!). Daher hier vornehmlich eine Liste mit Features:
- HTTP-Status-Check
- Antwortzeit
- Seitengröße
- HTTP-Methoden (GET, POST etc.)
- HTTP-Version
- Weiterleitungen verfolgen
- Umgang mit Reverse-Proxies
- Authentifizierung via Login/Token
- Header-Vorgaben
- Proxy-Support
- Grundlegende Checks für Zertifikate
- Suche nach Strings oder regulären Ausdrücken
- Inklusive check_httpv2-Binaries für Windows 10/11 und (mindestens) Ubuntu 24.04
Ein Aufruf könnte etwa so aussehen:
check-http.exe' --url https://www.tutonaut.de --timeout 10 --user-agent check_httpv2_agent --body-string tutonaut --status-code 200 --status-code 300 --status-code 301 --response-time-levels 0.2,0.3
Hier werden zu erwartende Status-Codes (200, 300, 301) angegeben, dazu ein erwarteter String (tutonaut) sowie Level für die Antwortzeit. Die Logik: Ein nicht gefundenes "tutonaut" und ein überschrittener unterer Antwortzeit-Level von "0,2 Sekunden" führen zu einem Status Warning. Dauert die Antwort länger als 0,3 Sekunden oder wird keiner der gewünschten Status-Codes gefunden, geht der Status auf Critical.
GUI-Umsetzung
Die GUI ist ziemlich simpel, hier genügen einige wenige Worte. Wenn Ihr alle Optionen sehen wollt, vergesst nicht Show advanced options anzuklicken!
Startseite: Hier mal im Überblick - oben die Optionen und Bedienelemente, dann der Check-Status, dann eine Zusammenfassung, dann die rohe Ausgabe.
Im Basic-Reiter müsst Ihr eine URL angeben, alles andere ist optional. Über Run Check wird der Check ausgeführt und Ihr seht sofort einen finalen Status - hier im Bild OK (exit0) weil alles supi ist :)
Unter Summary folgen dann einige der gelieferten Daten - sofern konfiguriert!
Unter Raw Output folgt dann das ausgeführte Kommando samt Ausgabe. Das schafft Transparenz und kann bei etwaigen Fehlern helfen.
Einen Hinweis ist noch die HTTP-Methode wert: Wenn hier POST, PUT oder PATCH gewählt wird, erscheint ein zusätzlicher Reiter Content. Eigentlich erwartet check_httpv2 an dieser Stelle URL-kodierte Inhalte, es lässt sich aber auch JSON-Content verwenden - einfach ein Häkchen bei Convert JSON setzen.
Profilmanager
Der Profilmanager ist (noch) etwas unrund würde ich sagen, aber sei's drum. Die Nutzung ist simpel:
- Optionen setzen
- "Save Profile" zum Speichern
- Optionen ändern
- "Update Profile" zum Aktualisieren des aktuellen Profils
- Profil laden über Dropdown-Menü
Zudem gibt es den expliziten Manager über Manage Profiles:
Hier werden alle Profile aufgelistet, sie können geladen, gelöscht und (gemäß der aktuell gesetzten Optionen) aktualisiert werden. Dazu gibt es rechts eine kleine Vorschau. Ausschließlich hier könnt Ihr zudem **CSV retention (days) setzen: Darüber bestimmt Ihr, wie lange Daten von geplant ablaufenden Checks in der zentralen CSV-Datei gespeichert werden - standardmäßig für immer. Mehr dazu im Scheduler-Kapitel.
Warum wird die Retention-Zeit hier und nicht im Scheduler gesetzt? Weil der Scheduler möglichst einfach sein sollte, das CSV-Backend sicherlich nicht jeder nutzen wird und der Profilmanager eventuell später noch weiter ausgebaut wird.
Zunächst ein Blick in die Datei profiles.json, die die eigentlichen Profile enthält - hier ein konkretes, gekürztes Profil:
"Tutonaut_basic": {
"auth_pw_plain": "",
"auth_user": "",
"body": "",
"body_regex": "",
"body_string": "tutonaut",
"content_type": "",
"csv_retention_days": 3,
...
"response_time_levels": "0.2,0.3",
"server": "",
"status_code": "200,300,301",
"timeout": "10",
"tls_version": "",
"token_header": "",
"token_key_plain": "",
"url": "https://www.tutonaut.de",
"user_agent": "check_httpv2_agent",
"verbose_level": "0"
Es werden also schlicht die konfigurierten Optionen im JSON-Format hinterlegt.
Scheduler
Der Scheduler ist nur dafür da, um die automatischen Abläufe von Profilen zu starten und zu stoppen und die Status zu sehen.
Es gibt zwei Möglichkeiten, den Scheduler zu nutzen: Wenn aktiv und das zugehörige Profil geladen ist, aktualisiert sich auch die Startseite mit Status und Zusammenfassung bei jedem neuen Durchlauf. So würdet Ihr dann sofort sehen, wenn sich der Status ändert, die Seite zum Beispiel plötzlich Down ist.
Vor allem aber ist der Scheduler dafür gedacht, die Daten der Checks in einer zentralen CSV-Datei results.csv zu speichern; und zwar so, dass Grafana damit zurecht kommt.
Beispielrechnung zum Datenvolumen: Angenommen Ihr überwacht 10 Webseiten alle 10 Minuten, dann habt Ihr nach einem Jahr 525.600 Einträge in der CSV-Datei - das ist noch okay, in Excel & Co. aber schon langsam. Excel und auch LibreOffice Calc unterstützen maximal knapp über 1 Million Zeilen pro Tabelle, sprich nach 2 Jahren wäre das Monitoring tot. Man kann also schon eine ganze Menge Daten speichern. Wenn Ihr tatsächlich mehrere Dutzend Webseiten monitoren und das auch noch im Minutentakt tun wollt und historische Daten aus mehreren Monaten benötigt ... dann solltet Ihr wohl lieber Checkmk nutzen. Üblicher: 20 Webseiten, 2 Checks pro Stunde, historische Daten aus 3 Monaten - das macht gerade mal 86.400 Zeilen, ein Klacks für eine CSV-Datei.
Datenformat/Grafana-Anbindung
Das Datenformat CSV ist wunderbar simpel, kann fast überall verwendet werden und ist für Mensch und Maschine gleichermaßen lesbar.
Hier die insgesamt 43 Spalten in Form der Überschriften:
timestamp,profile,status,exit_code,response_time,url,method,timeout,interval,http_version,server,user_agent,disable_cert,tls_version,min_tls_version,onredirect,max_redirs,force_ip_version,ignore_proxy_env,proxy_url,proxy_user,auth_user,token_header,content_type,headers,header_strings,header_regexes,header_regexes_invert,body_string,body_regex,body_regex_invert,status_code,response_time_levels,document_age_levels,certificate_levels,page_size_option,without_body,debug_headers,debug_content,verbose_level,page_age,page_size_bytes,certificate_days_valid
Und hier ein konkreter Datensatz:
2026-03-04T04:20:51.627989Z,Tutonaut_basic,OK,0,0.1274284,https://www.tutonaut.de,,10,30,,,check_httpv2_agent,False,,,,,,False,,,,,,,,,False,tutonaut,,False,"200,300,301","0.2,0.3",,,,False,False,False,0,,422341,
Einen ausführlichen Artikel zur Anbindung von Google-Sheets-Tabellen an Grafana haben wir hier. Daher hier nur in aller Kürze ein Blick auf die Grafana-Konfiguration für ein Profil. Gewünschte Visualisierung: Status über Zeit.
Erstmal der Reiter Queries:
Datenquelle: Grafana Infinity Datasource ist die Quelle der Wahl für JSON, CSV, XML, GraphQL und HTML-Endpunkte. Die Grundkonfiguration wie hier im Bild:
- Typ: CSV
- Parser: Backend
- Source: URL
- Format: Table
- Method: GET
- URL: http://LOKALER-HOST:5000/results.CSV
Unter Parsing options & Result fields müssen die gewünschten Spalten gewählt werden:
- timestamp as TIME format as TIME (als TIME, damit die X-Achse die Zeit abbildet)
- profile as profile format as string
- status as Status format as String
Unter Computed columns, Filter, Group by muss noch ein Filter ausgewählt werden:
- Filter: profile == "Tutonaut_basic"
Das sorgt dafür, dass aus der CSV-Datei nur die Daten dieses einen Profils gelesen werden.
Nun zum Reiter Transformations:
Hier braucht es die Transformation Organize fields by name. Hier muss der Profilname auf unsichtbar gesetzt werden - letztlich werden ja nur Status über die Zeitleiste benötigt.
Die fertige Visualisierung zeigt dann die jeweiligen Status über den zeitlichen Verlauf an. Wie hier im Bild unten zu sehen: Natürlich können auch andere Daten wie die Antwortzeit in Panels und die wiederum in gemeinsame Dashboards gepackt werden.
Hintergrund: Technik
An dieser Stelle ließe sich massig Kleinkram unterbringen, aber im Grunde ist die ganze App ziemlich simpel, daher nur ein Punkte, die ich interessant finde.
Binaries: Im bin-Verzeichnis liegen check_httpv2-Binaries für Windows (check-http.exe) und Ubuntu 24.04 (check-http).
Abhängigkeiten: Es wird letztlich nur der Entwicklungs-Webserver Flask benötigt, der Rest wird über Standard-Python-Bibliotheken erledigt. Dennoch liegt eine pip-freeze-Datei bei, die aber nur zeigt, was Flask selbst installiert hat:
blinker==1.9.0
click==8.3.0
colorama==0.4.6
Flask==3.1.2
itsdangerous==2.2.0
Jinja2==3.1.6
MarkupSafe==3.0.3
Werkzeug==3.1.3
Frontend <-> Backend: Das Frontend besteht aus den Dateien index.html, style.css und script.js und kümmert sich um Darstellung, Formularfelder, Navigation, Browser-seitige Speicherung (via localStorage) und sendet natürlich API-Anfragen (via fetch) ans Backend. Das Backend besteht aus der Datei app.py, die den Server betreibt, Daten liest/schreibt/verwaltet, das Frontend zu Aktualisierungen antreibt und natürlich für check_httpv2 betreibt.
Lokaler Betrieb: Flask ist ein Entwicklungsserver, aber für den Betrieb innerhalb des eigenen Netzwerks oder gar nur lokal auf dem Desktop genügt Flask. Die Konfiguration erlaubt derzeit den Zugriff im gesamten Netzwerk. Verantwortlich ist dafür die letzte Zeile in der app.py:
app.run(host="0.0.0.0", port=5000, debug=True)
Diese host-Angabe erlaubt den LAN-weiten Zugriff, eine konkrete IP würde entsprechend beschränken.
Download & Installation
Das Tool findet Ihr auf der GitHub-Seite. Ihr könnt es entweder mit Git klonen oder als ZIP herunterladen (über den grünen Button "<> Code").
Installation:
- Python installieren
- ZIP entpacken/Repo klonen
- Verzeichnis im Terminal betreten
Ubuntu:
python3 -m venv .venv
source .venv/bin/activate
pip install flask
python3 app.py
Windows:
python -m venv .venv
.venv\Scripts\activate
pip install flask
python app.py
Und dann jeweils localhost:5000 im Browser öffnen.
Aussicht
GUI for check_httpv2 war ein ziemlich spontanes Projekt und für meinen Bedarf funktioniert es einwandfrei. Es wird vielleicht irgendwann noch mal Updates geben - letztlich hängt es aber auch von Eurem Feedback ab. Was unter anderem interessant zu wissen wäre:
- Was genau wollt Ihr monitoren?
- Kommt Ihr mit der Bedienung zurecht?
- Wie sehr nervt Euch der Profilmanager? ;)
- Liebäugelt Ihr mit mehr (etwa Checkmk) oder weniger (etwa check_httpv2 plus Mini-Shellskript)?
- Monitort Ihr schon irgendwas - und wenn ja, womit?
Eines ist jedenfalls klar: Viel mehr Funktionalität wird GUI for check_httpv2 nicht bekommen. Denn so komplex Checkmk auch ist, wenn es nur darum geht, HTTP-Endpunkte mit check_httpv2 zu monitoren, ist das nicht allzu kompliziert. Allerdings weiß ich auch, dass da 9 Jahre Erfahrung aus mir sprechen ... Ein paar Tage würden Einsteiger (mit Monitoring-Erfahrung) wohl benötigen, um alles zu begreifen. Die kleine GUI sollte binnen einer Stunde keinerlei Geheimnisse mehr haben.
So, und nun: Happy Monitoring!
