Ein besserer check_http – technische Hintergründe

Der bei Monitoring-Plugins.org gepflegte check_http ist einer der wichtigsten aktiven Checks bei Monitoring-Systemen, die ihre Wurzeln in Nagios haben. Neben Checkmk sind das Icinga, Naemon und Zabbix. Lesen Sie in diesem ersten Teil die technischen Hintergründe für die Entscheidung, eine Neuimplementierung zu beginnen und erfahren Sie alles Wissenswerte zur Installation unter anderen Monitoring-Systemen als Checkmk sowie zur Nutzung auf der Kommandozeile.

Dieser Blog-Artikel basiert auf einem 30-minütigen Talk auf der OSMC. Ein zweiter Teil wird demnächst die Konfiguration per GUI in Checkmk und Anregungen für die effizienteste Migration bestehender Regeln für check_http aufzeigen.

Der bisherige check_http ist über 20 Jahre alt. Ihm ist deutlich anzumerken, dass über die Zeit wechselnde Entwickler Unterstützung für SSL, Proxies und andere Features nachgerüstet haben. Daraus resultiert unter anderem, dass der Check bei manchen Aufrufen einige Kommandozeilenparameter nicht auswertet und andere bevorzugt (die Prüfung auf Zertifikatslaufzeit und Status Code ist beispielsweise in einem Aufruf nicht möglich).

In Checkmk bilden wir derartige Einschränkungen in der GUI ab, so wissen unsere Nutzer sofort, dass für die beiden erwähnten Checks zwei Regeln und damit zwei Aufrufe des Checks nötig sind. Einiges an Arbeit hätte die Verbesserung der Login-Optionen und die Überarbeitung des Verhaltens bei Verwendung von SSL erfordert.

Insbesondere der letzte Punkt ist vielen Checkmk-Nutzern sehr wichtig: Sie erwarten, dass der Check sich wie ein Browser verhält. Dies beinhaltet beispielsweise, dass er den Zustand nach CRIT wechselt, wenn kein SSL-gesicherter Aufruf im Browser mehr möglich ist.

Bei der Frage, ob wir am bestehenden Check arbeiten oder eine Neuimplementierung starten, mussten wir auch Kompatibilität berücksichtigen. Da dies bei einem aktiven Check, der über 20 Jahre im Einsatz ist, zu einem großen Teil auch Bug-Kompatibilität bedeutet, entschieden wir uns für eine Neuimplementierung. Weitere hierfür sprechende Faktoren waren, dass eine Vielzahl von Pull-Requests eine hohe Belastung der Maintainer bedeutet hätten und dass eventuell hinzugekommene Abhängigkeiten der Portabilität der Monitoring-Plugins abträglich geworden wären. So entschieden wir uns für eine im Haus durchgeführte Neuimplementierung.

Als Nächstes stand die Wahl der Programmiersprache an, in der wir den neuen aktiven Check schreiben wollten. C/C++, Python und Rust sind die Sprachen, welche wir bei Checkmk primär nutzen, derzeit mit der Tendenz, C/C++ etwas weniger einzusetzen und Rust verstärkt bei Performance-kritischen Komponenten zu nutzen. C/C++ hätte zwar den Vorteil geboten, wieder in der Sammlung der Monitoring-Plugins aufgenommen zu werden, es ist jedoch schwerer zu pflegen als die beiden Alternativen.

Python hat innerhalb von Checkmk die größte Programmiererschaft, allerdings hätte eine Implementierung als Spezialagent die Kompatibilität zu anderen Monitoringsystemen gebrochen. Ausschlaggebend war, dass die derzeitige Art, sowohl aktive Checks als auch Spezialagenten aufzurufen – nämlich über einen erzeugten und beendeten Prozess pro Call – auf der Performance-Seite mit Python nicht konkurrenzfähig genug war.

Das Rennen machte schließlich Rust: ähnlich performant wie C/C++, aber besser zu warten – und im Unternehmen bereits mit dem Agent Controller erprobt. Damit sprach alles für die moderne, kompilierte Sprache.

Wenn Sie ein Monitoring-System nutzen, das check_httpv2 nicht oder noch nicht mitbringt, können Sie ihn einfach nachrüsten. In Rust geschriebene Programme sind dank der schnell installierten Toolchain in wenigen Minuten kompiliert. Die unter GPLv2 verfügbaren Quelltexte sind im Checkmk-Github-Repository enthalten, unser Beispiel zeigt die Installation unter Debian und Ubuntu.

Zunächst stellen Sie das Vorhandensein einiger Abhängigkeiten sicher:

apt install git curl
apt install build-essential libssl-dev pkg-config

Es folgt die Installation und das Verfügbarmachen der Rust-Toolchain in der aktuellen Shell-Umgebung:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
. “$HOME/.cargo/env”

An die Quellcodes kommen Sie nur heran, indem Sie das komplette Checkmk-Repository lokal klonen. Dies dauert einige Minuten – genug Zeit, Wasser für ein heißes Getränk anzusetzen:

Wir empfehlen, den aktuellen stabilen Zweig zu verwenden, als dieser Blog-Artikel entstand, war dies 2.3.0:

git checkout 2.3.0

Es folgt das Bauen und damit der Konsum des soeben zubereiteten Heißgetränkes:

cd checkmk/packages/check-http/
cargo build --release

Das frisch kompilierte Binary können Sie direkt aus dem Build-Verzeichnis heraus ausführen:

ls -lah target/release/
time ./target/release/check_http --url https://docs.checkmk.com/
echo $?

War der Test erfolgreich, installieren Sie den neuen Check in ein passendes Verzeichnis, beispielsweise /usr/local/bin oder das Installationsverzeichnis der Monitoring-Plugins – wir empfehlen check_httpv2 als Name:

install -m 0755 ./target/release/check_http /usr/local/bin/check_httpv2

Der größte Vorteil gegenüber dem bekannten check_http ist, dass Sie mit ihm in weit mehr Fällen verschiedene Parameter von Serverkonfiguration, Zertifikatsstatus und Last prüfen können. Hier zum Beispiel neben einer Antwortzeit von maximal 0,2s (WARN) bis 0,5s (CRIT) auch der Response Code 200, die Verfügbarkeit von TLS 1.3 und eine Zertifikatslaufzeit von mindestens 7 resp. 15 Tagen:

check_httpv2 \
    --timeout 2 \
    --response-time-levels 0.2,1.0 \
    --min-tls-version tls13 \
    --certificate-levels 15,7 \
    --status-code 200 \
    --url https://docs.checkmk.com/

Alle Kommandozeilenparameter erhalten Sie mit dem Parameter --help. Alternativ können Sie eine Testinstallation mit Checkmk aufsetzen (das ist in fünf Minuten erledigt), dort check_httpv2 konfigurieren und die erzeugte Kommandozeile aus den Service-Details auslesen:

1. In der Setup-Suche navigieren Sie zu „Check HTTP web service“.
2. Legen Sie eine Regel an, mit der Sie die gewünschten Einstellungen für einen erreichbaren Endpunkt anlegen.
3. In den Service-Details des Checks finden Sie die Kommandozeilenparameter.

Neben check_httpv2 haben wir check_cert entwickelt. Auch dieser aktive Check ist in Rust geschrieben. Nutzen Sie ihn nicht nur zur Prüfung von Zertifikaten auf Laufzeit, sondern auch für viele andere Aspekte wie Schlüssellänge oder Herausgeber, auch wenn kein HTTPS-Endpunkt die zu prüfenden Zertifikate bereitstellt.

Die Quellcodes finden Sie in checkmk/packages/check-cert. Das Kompilieren und die Ermittlung der Aufrufe sind analog zu check_httpv2. Aufgrund des Fokus auf die Prüfung von Zertifikaten werden detailliertere Methoden eher hier als in check_httpv2 Eingang finden.