Mobile-Menu

Workshop: Monitoring mit Checkmk – Teil 3 Monitoring von Webseiten, Mailkonten und Applikationen

Von Mirco Lang 5 min Lesedauer

Anbieter zum Thema

Checkmk GmbH

Das Monitoring der eigenen Infrastruktur ist eine Sache – aber wie sieht es etwa mit der Unternehmenswebseite bei einem Service-Anbieter aus? Auch solche „aktiven“ Checks lassen sich mit Checkmk umsetzen. Wir zeigen, wie.

Im dritten Teil unseres Checkmk-Monitoring-Workshops geht es um das Monitoring von Netzwerkdiensten, die nicht in der eigenen Infrastruktur laufen – also bspw. um die Überwachung einer Unternehmenswebsite beim Provider/Hoster.(Bild: Lang - Checkmk)
Im dritten Teil unseres Checkmk-Monitoring-Workshops geht es um das Monitoring von Netzwerkdiensten, die nicht in der eigenen Infrastruktur laufen – also bspw. um die Überwachung einer Unternehmenswebsite beim Provider/Hoster.
(Bild: Lang - Checkmk)

Im zweiten Teil der Serie ging es vor allem um Checks innerhalb der eigenen Infrastruktur. Entweder lieferte der auf einem überwachten Server oder einer Workstation installierte Checkmk-Agent die Daten. Oder ein so genannter Spezialagent hat APIs, zum Beispiel des hauseigenen Kubernetes-Clusters abgefragt.

Aber wie sieht es mit Netzwerkdiensten aus? Nicht nur laufen bspw. viele Unternehmenswebseiten gänzlich außerhalb der eigenen IT, es ist auch wünschenswert, derlei Dinge „von außen“ zu monitoren – quasi aus Sicht eines echten Nutzers. Und hier kommen die „Active Checks“ von Checkmk zum Einsatz: Letztlich sind dies, wie die Spezialagenten auch, Programme, die auf dem Checkmk-Server laufen und dann aktiv eine Verbindung zu solchen Diensten aufbauen – sei es nun zu einer Webseite, einem Mail-Konto, einer SMB-Freigabe oder sonst einem Web-Service.

Bildergalerie
Bildergalerie mit 6 Bildern

Mit dem HTTP-Check lässt sich allerdings nicht nur monitoren, ob die Seite aktuell online ist!

Konfiguration eines HTTP-Checks

Bevor es an die Website geht, eine kurze Vorüberlegung: Normalerweise monitort Checkmk Hosts und zugehörige Services. Nun läuft die genannte Beispiel-Webseite aber eben nicht auf einem eigenen Server, der als Host aufgenommen werden könnte, sondern beim Service-Anbieter. Da es in Checkmk aber keine „losen“ Services ohne Host gibt, muss auch solch ein Webseiten-Check zu einem Host gehören.

Natürlich, der Localhost/Checkmk-Server könnte dafür genutzt werden. Besser: Man legt einen expliziten, nicht existenten Host an, der explizit für derlei Tests gedacht ist. Natürlich muss der Host selbst von jeglichen Benachrichtigungen ausgenommen werden, schließlich wird sein eigener Status immer DOWN sein.

Die Regel zum Monitoren von Webseiten nennt sich „Check HTTP web service“. Ein typischer Testfall:

  • Eine Webseite soll auf Verfügbarkeit und Performance geprüft werden.
  • Es wird eine Anmeldung durchgeführt und verifiziert.
  • Die Gültigkeit des HTTPS-Zertifikats wird geprüft.

Nehmen wir mal ein konkretes Beispiel: Als Test-Seite zum Überwachen bietet sich die Seite Authentication Test an, genauer gesagt https://authenticationtest.com/HTTPAuth/ – hier findet eine Anmeldung über HTTP Basic Authentication statt, die auch der HTTP-Check beherrscht.

Nach der Anmeldung vermeldet die Seite „Success“ – und nach genau diesem Wort soll der Check ebenfalls suchen, um die erfolgreiche Anmeldung zu bestätigen.

Und letztlich soll sichergestellt sein, dass das Zertifikat der Seite noch mindestens 50 Tage gültig ist und andernfalls auf den Status WARN gewechselt wird.

Für einen funktionierenden Check benötigt Checkmk lediglich einen Titel und die URL, die weitere Konfiguration ist optional (siehe Abbildung 2).

Für unser Beispiel muss zunächst die Anmeldung durchgeführt werden. Über die Option „Connection buildup/Authentication“ werden dafür schlicht die Anmeldedaten übergeben, standardmäßig also Nutzername und Passwort, alternativ wäre auch eine Authentifizierung über Token möglich (siehe Abbildung 3).

Um die Anmeldung zu verifizieren, soll der Check nach dem Wort „Success“ suchen: Diese Möglichkeit bietet die Option „Search for strings“, die hier schlicht nach einem regulären Ausdruck im Body des HTML-Dokuments fahndet. Gibt es zu der Regex keinen Treffer, geht der Zustand des Checks auf WARN (siehe Abbildung 4).

Für den Zertifikatscheck werden schlicht Schwellwerte (Levels) für die Status WARN und CRIT eingegeben, wie so oft in Checkmk – hier sind es 50 und 20 Tage (siehe Abbildung 5).

Der HTTP-Check bietet noch weitere Optionen, beispielsweise können bestimmte Response-Zeiten oder HTTP-Statusmeldungen erwartet werden, der Check kann wahlweise nur die Header oder den das gesamte Dokument abwarten, es können Daten über PUT-Requests versendet werden und so weiter.

Der HTTP-Check im Monitoring

Sobald die Konfiguration übernommen wurde, landet die Auswertung im Monitoring – und der Status wechselt zu WARN (siehe Abbildung 6).

Die Details in Abbildung 6 verraten: Die Website ist erreichbar, der Status OK, die Authentifizierung hat funktioniert, „Success“ wurde gefunden – aber das Server-Zertifikat ist nur noch 34 Tage lang gültig, daher der WARN-Status. Und abseits aller Konfiguration werden auch Leistungsdaten in Form von Diagrammen gerendert: die Antwortzeit sowie die Zeiten, bis die Header beziehungsweise der Body übertragen wurden.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Netzwerktechnik, IP-Kommunikation und UCC

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Das Monitoren eines HTTP-Diensts steht hier stellvertretend für andere Protokolle, beispielsweise SMB, LDAP, SMTP, TCP, IMAP oder FTP – auch wenn nicht alle zugehörigen Checks dermaßen umfangreich ausfallen.

Spannende Mail-Erweiterung

Einen sehr interessanten zusätzlichen Aspekt liefert der Check zu Mail-Konten: Auch dort gibt es die Möglichkeit, nach bestimmten Begriffen zu suchen. Und Mails, die diese Begriffe beinhalten, können wiederum an Checkmks „Event Console“ weitergeleitet werden.

Events in Checkmk können hier aber nur ganz kurz angerissen werden: Normalerweise geht es in Checkmk um Status, die in mehr oder weniger fixen Abständen geprüft werden. Bei Events geht es hingegen um Ereignisse, beispielsweise Fehlermeldungen, wie sie in Log-Dateien auftauchen – die nicht zwangsläufig dazu führen müssen, dass die zugehörige Anwendung nicht mehr läuft.

Und auch Mails mit einem bestimmten Stichwort können als solch ein Event behandelt und dann ins Monitoring geholt werden. Das heißt ganz praktisch: Man könnte zum Beispiel ein Mail-Konto einrichten, auf dem Mailing-Listen von Security-Projekten eingehen, diese auf bestimmte Produkte monitoren und sich dann entsprechend benachrichtigen lassen. Und: in der Event Console wird nicht in Intervallen, sondern in Echtzeit gearbeitet

(Weit) Darüber hinaus

Alles, was Sie bis hierhin über Checkmks Funktionen und Arbeitsweise gelesen haben, betrifft relativ klassisches Monitoring und ist auch mit der Open-Source-Version umsetzbar. Ein relativ neues Feature, das selbst in den kommerziellen Versionen zusätzlich erworben werden muss, sollten Sie sich zum Abschluss aber kurz anschauen – weil es die Möglichkeiten klassischen Monitorings überschreitet.

Die Rede ist vom Synthetic Monitoring, ein Thema, zu dem es bei Dev-Insider einen Gast-Artikel von Simon Meggle gibt, der für die entsprechende Umsetzung bei Checkmk verantwortlich ist. In Checkmk ist mit Synthetic Monitoring konkret das Plugin „Robotmk“ gemeint, das sich aus dem im Checkmk-Kontext üblichen Suffix „mk“ und „Robot“ zusammensetzt, womit Bezug auf das Robot Framework genommen wird. Robot Framework hat nichts mit Monitoring zu tun, sondern ist ein Framework zum Testen von Software, allem voran Webanwendungen – aus Sicht eines (synthetischen) Nutzers.

Via Robot Framework ließe sich also nicht nur wie oben beschrieben testen, ob eine Seite technisch grundsätzlich funktioniert, sondern ob die Nutzererfahrung funktioniert – also zum Beispiel ein kompletter Einkaufsvorgang samt Checkout.

Via Robotmk lassen sich Robot-Framework-Tests über Checkmk triggern. Die Robot-Framework-eigenen Berichte zu den Tests landen in der Checkmk-Weboberfläche. Zudem wertet Checkmk selbst aus, ob die Tests (unabhängig von deren Ergebnissen) korrekt durchgelaufen sind und mit welcher Performance. Kurz gesagt: Mit dieser Erweiterung kann Checkmk (indirekt) komplette User-Journeys monitoren.

Und diese Erwähnung bietet gleich in zweierlei Hinsicht einen ordentlichen Schlusspunkt. Erstens zeigt sie beispielhaft, dass die Nicht-Open-Source-Funktionen bei Checkmk oft nur für Großunternehmen wirklich relevant sind. Zweitens zeigt es die Relevanz der Community: Das erste Robotmk ist unabhängig von der Checkmk GmbH entstanden und wurde erst später samt Entwickler „eingekauft“.

Fazit

Abschließend bleibt zu sagen, dass Checkmk einen gewaltigen Funktionsumfang hat und eine ebenso gewaltige Lernkurve benötigt! Intuitiv lässt sich relativ wenig anstellen, einige Konzepte müssen zunächst wirklich verstanden werden – insbesondere die Funktionsweise der Agenten und die Regel-basierte Konfiguration. Auch bei den Erklärungen in dieser kleinen Serie ging es nicht ohne Vereinfachungen, die vielen Ausnahmen, Optionen und Alternativen sprengen ansonsten jeden Rahmen. Einmal verinnerlicht, lässt sich dafür sehr detailliert monitoren.

(ID:50196969)

Weiterführende Inhalte