Workshop: Monitoring mit Checkmk – Teil 11 Webseiten mit check_httpv2 überwachen – auch ohne Checkmk!

Die Überwachung von Webseiten gehört zu den wichtigsten Aufgaben im Monitoring – und Checkmk hat dafür ein neues Tool entwickelt. Besonders interessant: check_httpv2 macht auch im Standalone-Betrieb eine sehr gute Figur.

Check_http ist ein absoluter Klassiker. Das kleine Open-Source-Tool ist seit den 90ern der Standard zum Überwachen von Webseiten, vor allem unter Nagios. Aber eben auch in kompatiblen Systemen oder im Solo-Betrieb auf der Kommandozeile für Ad-hoc-Anfragen oder kleinere Skripte. Heute gibt es sogar zwei leicht unterschiedliche Versionen von Monitoring-Plugins.org und Nagios-Plugins.org.

Allerdings ist das Werkzeug ein wenig in die Jahre gekommen. Teils werden mehrere Aufrufe für die Abfrage mehrerer Daten einer einzelnen Seite benötigt, teils bleiben Funktionen arg oberflächlich, komplexe Verbindungsaufbauten können Schwierigkeiten verursachen und so weiter. Mit check_httpv2 gibt es seit Release von Checkmk 2.4 im Frühjahr 2025 nun einen – inoffiziellen – Nachfolger.

Und das Tool könnte durchaus noch ein gewisses Eigenleben entwickeln, denn es läuft auch außerhalb von Checkmk, sei es solo im Terminal oder als Ersatz für check_http in Nagios-kompatiblen Monitoring-Systemen. Zudem hat check_httpv2 noch ein Geschwisterchen bekommen: check_cert. Der neue HTTP-Check kann Zertifikate schon besser auswerten als der Klassiker, aber mit check_cert gibt es nun auch noch eine Spezialisten – den wir Ihnen in der nächsten Folge vorstellen.

Am Ende interessiert natürlich vor allem das Ergebnis. Check_httpv2 liefert eine Auswertung über die Erreichbarkeit eines Endpunkts, Basisdaten wie die HTTP-Version oder den User-Agenten sowie Metriken wie Antwortzeit und -größe – natürlich hübsch aufbereitet als Grafen (siehe Abbildung 1).

Features von check_httpv2

In Checkmk liegt der HTTP-Check unter „Setup/Services/HTTP, TCP, email, .../Check HTTP web service“. Es handelt sich dabei um einen aktiven Check, sprich er wird direkt vom Checkmk-Server aus ausgeführt, hier sind – natürlich – keine Agenten mit im Spiel.

Zunächst mal die wichtigsten Features im Überblick:

• Antwort-Zeit und -Größe

• Zeit für HTTP-Header und -Inhalt

• Monitoring mehrerer Endpunkte

• Prüfung auf bestimmte Strings auf Webseiten

• Authentifizierung (Token/Nutzer)

• Festlegung auf HTTP- und TLS-Versionen

• Handling von Weiterleitungen

• Komplexe Verbindungsaufbauten

• Berücksichtigung von Reverse-Proxys wie Load-Balancern

• Grundlegende Zertifikatsprüfung (Laufzeit)

Grundsätzlich spielt es keine Rolle, ob check_httpv2 nun in Checkmk oder solo läuft. Allerdings bringt der Betrieb in Checkmk ein paar Vorteile mit sich: Zum einen ist die Konfiguration in der Weboberfläche deutlich intuitiver und mit ausführlicher Hilfe versehen. Zum anderen können bei der Konfiguration Makros verwendet werden, was bei der Überwachung von Hunderten Hosts sehr hilfreich sein kann.

Vor allem aber können über eine Regel direkt mehrere Endpunkte konfiguriert werden, die eine gemeinsame Konfiguration nutzen, die aber für jeden Endpunkt manuell überschrieben werden können. Ein Blick in die Praxis wird das verdeutlichen.

Die HTTP-Check-Regel

In der einfachsten Form genügt es, in der Regel eine URL für den zu überwachenden Endpunkt einzugeben, also beispielsweise „https://www.ip-insider.de“ (siehe Abbildung 2). Das führt dann im Monitoring zu einer simplen Auswertung mit Service-Status (also Erreichbarkeit) und HTTP-Details (siehe Abbildung 3).

Spannender wird es mit zusätzlichen Einstellungen. Der umfangreichste Punkt ist hier „Connection buildup“ (siehe Abbildung 4). Die meisten Optionen dürften selbsterklärend sein, also zum Beispiel die vorausgesetzte HTTP- oder TLS-Version, erwartete Status-Codes, die Verwendung eines Proxys oder die Beschränkung auf IPv4 oder IPv6.

Aber für was könnte etwa „Connect to specific host“ gut sein? (Eigene) Proxys haben ihre eigene Option, mit „specific host“ sind vor allem Endpunkte hinter Reverse-Proxys gemeint.
Folgender Fall: Sie betreiben zwei redundante Webserver mit einer Seite hinter einem Load-Balancer. Als Endpunkt würde natürlich der Name der Webseite eingetragen, etwa „example.com“. Wenn dann ein Check ein Problem meldet, liegt es dann am Load-Balancer oder an einem der beiden Webserver?

Genau für solche Fälle können Sie zu einem Endpunkt noch einen spezifischen Server angeben, so dass check_httpv2 eine entsprechende Auswertung fabrizieren kann.

Auch hinter der Option „HTTP method“ versteckt sich einiges an Potenzial: Statt einfach nur eine simple GET-Anfrage zu stellen, lässt sich hier die PUT-Methode aktivieren und mit passendem Content versehen. Letztlich soll der Check schließlich nicht nur eine Seite anpingen, sondern sich weitgehend wie ein Webseiten-Besucher verhalten.

Dem zollt auch die Option „Search for strings“ Rechnung. Was etwa, wenn der Webserver zwar läuft und der Check entsprechend OK meldet, das Content-Management-System aber versagt und keine Inhalte anzeigt? Mit der String-Suche ließe sich zum Beispiel nach einem Wort wie „IP-Insider“ suchen, um sicherzustellen, dass auch wirklich die Webseite angezeigt wird (siehe Abbildung 5).

Host-Verwaltung

In Checkmk gibt es mehrere Möglichkeiten, Hosts und Endpunkte zu organisieren. Eine Möglichkeit: Sie legen einen (Pseudo-) Host an, dem alle HTTP-Checks zugeordnet werden – über die Bedingung „Explicit hosts“ in der HTTP-Regel. Insbesondere, wenn es sich um eine überschaubar große Anzahl an Endpunkten handelt, bietet sich dieser Weg an.

Die Alternative ist etwas eleganter: Sie können statt einer Endpunkt-URL auch das Makro für Host-Namen ($HOSTNAME$) angeben und die Regel per Bedingung an einen bestimmten Ordner binden. Sobald dann in dem Ordner ein Host wie zum Beispiel „https://www.ip-insider.de“ angelegt wird, greift die Regel und der Name des Hosts wird als Endpunkt-URL verwendet. Soll ein weiterer Endpunkt überwacht werden, muss immer nur ein Host in dem Ordner angelegt werden.

Und natürlich: Sie können beide Varianten nach belieben kombinieren – in großen, komplexen Umgebungen wird das auch die Regel sein.

check_httpv2 kompilieren

Da check_httpv2 ein Teil von Checkmk ist, gibt es das Tool nicht separat als Binary – Sie müssen selbst kompilieren. Erfreulicherweise funktioniert das ausnahmsweise problemfrei, Rusts Paketmanager Cargo leistet hier gute Arbeit. Hier das Snippet zum Bau des Tools:

Im Ordner „release“ finden Sie dann die fertige Binary namens „check-http“; der Ordner wird durch die Cargo-Konfiguration bestimmt (die workspace-Variable in Cargo.toml).

Nun, zumindest sollte das klappen, wenn das Build-System aktuell ist. Da aber zum Beispiel Ubuntu mit älteren Cargo-Versionen ausgeliefert wird … Kompilieren funktioniert eben doch nicht immer problemfrei – also zwei Tipps zum Troubleshooting:

Hier ist es auf einigen Systemen zu einer Fehlermeldung bezüglich der Datei „Cargo.lock“ gekommen. Die Lock-Datei kümmert sich um Versionen von Abhängigkeiten, liegt in der Version 4 vor und verlangt ein aktuelles Cargo. Quick-and-Dirty-Lösung: In der Datei die Version auf 3 ändern.

Besser: Installation mit Hilfe des Rust-Toolchain-Managers rustup:

Das ist im Grunde dasselbe Skript wie oben, nur dass Cargo hier via rustup in aktuellster Version installiert und als Standard gesetzt wird – vielleicht etwas unschön, dass nicht alles wie gewohnt mittels System-Paketmanager verwaltet wird.

Checks auf der Kommandozeile

Damit bekommen Sie eine Binary namens „check-http“, deren einfachster Aufruf so aussieht:

Ein komplexerer Aufruf mit einigen der oben erwähnten Optionen könnte diese Form haben:

Und die zugehörige Ausgabe:

Diese Ausgabe lässt sich nun für eigene Skripte oder den Einsatz in anderen Monitoring-Systemen nutzen.

Zusammengefasst: check_httpv2 ermöglicht das Monitoring von Webseiten unter Berücksichtigung komplexer Verbindungen und der wichtigsten Metriken – innerhalb und außerhalb von Checkmk. Innerhalb von Checkmk gibt es zusätzlich einige Verwaltungsoptionen für größere Mengen an Hosts/Endpunkten.

Was die Zertifikate angeht: Hier beschränkt sich check_httpv2 tatsächlich auf die reine Gültigkeitsdauer, also den simpelsten Check überhaupt. Alles weitere überlässt das Tool check_cert, das wir Ihnen in der nächsten Folge vorstellen.

Workshop: Monitoring mit Checkmk – Teil 1

Wie funktioniert das Monitoring mit Checkmk?

Workshop: Monitoring mit Checkmk – Teil 2

Monitoring von Servern und Workstations

Workshop: Monitoring mit Checkmk – Teil 3

Monitoring von Webseiten, Mailkonten und Applikationen

Workshop: Monitoring mit Checkmk – Teil 4

Wie sieht eine gute Strukturierung in Checkmk aus?

Workshop: Monitoring mit Checkmk – Teil 5

Die wichtigsten Schritte zur Backup-Überwachung mit Checkmk

Workshop: Monitoring mit Checkmk – Teil 6

Wie funktioniert das Überwachen von Schnittstellen und Ports mit Checkmk?

Workshop: Monitoring mit Checkmk – Teil 7

Dashboards aus Daten: So wird das Checkmk-Inventar sichtbar

Workshop: Monitoring mit Checkmk – Teil 8

Checkmk aktualisieren – vorsichtig!

Workshop: Monitoring mit Checkmk – Teil 9

Checkmk: Android-Geräte überwachen – oder nicht?

Workshop: Monitoring mit Checkmk – Teil 10

So monitoren Sie Proxmox VE mit Checkmk

Workshop: Monitoring mit Checkmk – Teil 12

Zertifikate mit check_cert überwachen – auch ohne Checkmk!

Workshop: Monitoring mit Checkmk – Teil 13

Checkmk anpassen: Ansichten nach Belieben gestalten

(ID:50586544)