Geekzeug

Checkmk: Event Console + Logwatch = Newsticker im Dashboard ;)

Bastelspaß mit Lerneffekt - so funktionieren mk_logwatch und die Event Console

Was passiert, wenn man Kind gebliebenen Techies eine anpassbare Software wie Checkmk an die Hand gibt? Na klar, Blödsinn, Chaos, Spielerei! Vielleicht braucht Ihr keinen Newsticker fürs Dashboard, aber über die Bastelei seht Ihr auch ganz praktisch, wie Logfile-Monitoring funktioniert und warum man Log-Inhalte manchmal als Events behandeln sollte.

Übersicht

Mit ein wenig Bastelei lassen sich Schlagzeilen von beliebigen Webseiten in einem Checkmk-Dashboard anzeigen, gefiltert nach Stichworten, optional mit unterschiedlichen Status gekennzeichnet. Das ist zum einen eine nette Spielerei, die sich wunderbar als Grundlage für eigene Experimente eignet. Zum anderen ist es auch ein sanfter Einstieg in die Log-Überwachung und den Einsatz von Events im ansonsten auf Zuständen basierten Monitoring mit Checkmk.

Was es mit Agenten, Plugins, Regeln und so weiter auf sich hat, solltet Ihr bereits wissen, ansonsten könnte der Artikel etwas zu schnell sein. Kompliziert wird es aber nicht und im Zweifel sollten die Links ins Handbuch weiterhelfen.

Das Ziel des ganzen Theaters wird am besten durch einen Screenshot deutlich:

log-dashlet im dashboard.
So soll's am Ende aussehen

In diesem Fall handelt es sich um Schlagzeilen von ARD und Tutonaut, gefiltert und eingestuft nach Themen wie Linux, Putin, Euro und so weiter.

Das Prozedere ist im Grunde ganz einfach: Über das Checkmk-Plugin mk_logwatch wird eine - vermeintliche - Log-Datei überwacht, die Schlagzeilen aus RSS-Feeds enthält. Gespeist wird sie durch ein simples Skript, das ein paar RSS-Feeds abgrast und Meldungen auf ihre Titel reduziert. Das Plugin ist dazu gedacht, Textdateien zeilenweise zu verarbeiten - ob es sich dabei um Log-Einträge oder irgendetwas anderes handelt ist ihm freilich egal.

Damit gibt es in Checkmk dann einen Check für diese Log-Datei (oder auch mehrere Dateien gleichzeitig), der zum Beispiel auf CRIT geht, wenn ein bestimmtes Schlagwort auftaucht. Und auch den Log selbst kann man sich anschauen. Der Log selbst ist aber leider keine View/Ansicht im Sinne von Checkmk und lässt sich daher nicht weiter gestalten und hübsch in Dashboards einfügen.

Da kommt die Event Console ins Spiel: Alle einzelnen Einträge der Log-Datei werden an die EC weitergeleitet, wo sie in einer hübschen, anpassbaren Ansicht präsentiert werden. Ein weiterer Vorteil: Man kann die Einträge/Schlagzeilen einzeln verarbeiten. Und ganz wichtig: Die Schlagzeilen tauchen einzeln als Event auf, nicht pauschal zusammengefasst in einer Service-Detail-Beschreibung.

Sobald die Meldungen dann korrekt in der EC landen, kann die Ansicht angepasst und über das Dashlet Custom URL in Dashboards einbauen.

Warnung-chen: Natürlich ist das Ganze nur eine Spielerei und längst nicht perfekt, etwa weil die Schlagzeilen nicht anklickbar sind. Aber man könnte natürlich auf ähnliche Weise alle möglichen Textdateien überwachen, die wiederum aus allen möglichen Quellen gespeist werden können. Eigentlich kennt Ihr die Antwort auf die Frage Warum?

1. Fake-Log-Datei erstellen

Die Datei meinlog.log soll schlicht Schlagzeilen beinhalten:

Schlagzeile 1
Schlagzeile 2
Hallo Welt
Foobar
Schlagzeile 5

Für die Füllung werden RSS-Feeds abgerufen und von Ballast wie Formatierungen, Zusammenfassung und so weiter befreit. Wie das mit curl und sed geht, habe ich nun schon oft genug beschrieben, für dieses Projekt habe ich mir einen passenden Einzeiler von GitHub besorgt:

curl -w "\n" --silent "$RSS_URL" | grep -E '(title>)' | tail -n +4 | sed -e 's/^[ \t]*//' | sed -e 's/<title>//' -e 's/<\/title>//' 

Das Original hat noch die Beschreibung besorgt, das habe ich rausgeworfen. Zudem habe ich -w "\n" angehängt: Standardmäßig gibt curl am Ende der Ausgabe keinen Zeilenumbruch aus. Checkmk geht aber davon aus, dass Log-Zeilen mit Umbrüchen enden. Ohne diesen Zusatz würde die letzte Zeile eines Logs immer übersehen!

Nun braucht es zwei Dateien für die URLs und ein Skript. Hier die Datei urls:

https://www.tutonaut.de/feed/
https://www.tagesschau.de/infoservices/alle-meldungen-100~rss2.xml

Und hier das zugehörige Skript urls_logmaker.sh:

#!/bin/sh

while read RSS_URL; do
        curl --silent "$RSS_URL" | grep -E '(title>)' | tail -n +4 | sed -e 's/^[ \t]*//' | sed -e 's/</title><title>//' -e 's/<\/title>//' >> $2
done < $1

Der Aufruf:

./urls_logmaker.sh urls meinlog.log

Es werden also die Quelle der RSS-URLs und die Ausgabedatei angegeben. So könnte man dann auch mehrere Themenbereich oder Seiten loggen. Das Ergebnis sieht dann ungefähr so aus:

...
Linux-Terminal-Basics 13: Spaß haben
WhatsApp: Chats sperren und mit Biometrie schützen
Dateien im Browser verschlüsseln: Schnell, einfach und kostenlos
Test: UGreen HiTune T3
ChatGPT per OpenAI-API flexibler und günstiger nutzen
Linux-Terminal-Basics 12: Schleifen mit for, while, until
Linux-Terminal-Basics 11: Hilfe aufrufen
Linux-Terminal-Basics 10: Programme (zwangs)beenden
...

In meinem Fall liegt die Datei auf einem Windows-Host, unter Linux funktioniert das aber analog. In beiden Fällen sollte es natürlich regelmäßig automatisch aufgerufen werden.

2a. Log-Analyse: Agenten-Plugin-Regel

mk_logwatch ist ein Agenten-Plugin, also muss dieses nicht nur konfiguriert, sondern auch verteilt werden - wie das geht, steht ausführlich im Handbuch.

Sucht im Setup-Menü einfach nach Logfile und wählt Agent rules/Text logfiles (Linux, Solaris, Window). Hier braucht es im Grunde nur zwei Angaben: Aktiviert Configure a logfile section und gebt bei Patterns for logfiles ... Pfade zu den Log-Dateien an, seien es einzelne Dateien oder Verzeichnisse mit *-Zusatz.

log-patterns in mk_logwatch.
Agent-Plugin-Regel mit Pfaden zu Logs

Weiter unten bei Regular expressions for message classification werden nun Filter angelegt - optional! Man könnte hier auch alle Log-Zeilen an den Checkmk-Server weiterleiten und nur dort filtern. Dann sind neue Filter einfacher zu realisieren, aber warum unnütze Daten verschicken? Tendenziell ändert sich das ja nicht alle Nase lang.

filtereing in logwatch.
WAS soll an Checkmk geliefert werden und WIE soll es eingestuft werden?

Zeilen, die die vorgegebenen Begriffe enthalten, werden dann vom Agenten übermittelt und mit einer Info angereichert, welchen Status sie haben sollen.

Ihr könnt hier noch allerlei andere Operationen anleiern, aber als Minimallösung soll das hier reichen. Bei Bedarf könnt Ihr das Plugin natürlich wie gewohnt auf einen bestimmten Host beschränken, was hier sicherlich sinnvoll ist.

Nun muss das Plugin auf dem Host installiert werden, in den kommerziellen Editionen über die Agentenbäckerei und in der Open-Source-Edition händisch - wie, zeigt das Handbuch ausführlich. Führt anschließend wie üblich ein Service Discovery für den Host durch und fügt den neuen Log-Service hinzu.

2b. Log-Analyse: Service-Regel

Nun folgt noch die Service-Regel für mk_logwatch, im Setup-Menü unter Service monitoring rules/Logfile patterns. Ihr könnt die Regel komplett leer lassen oder wahlweise erneut filtern und einstufen:

re-classifying i n cmk.
Service-monitoring-Regel: Optionale Umklassifizierung

Nachdem Ihr die Änderungen angewandt und den Check neu ausgeführt habt, sollte dieser - je nach Konfiguration natürlich - als CRIT angezeigt werden.

log-service in cmk.
Der Log-Service ist CRIT, weil einige der Suchbegriffe vorkommen

Und über Open log gibt es dann den ganzen Log (hier im Bild in einer Variante mit Nicht-Treffern):

log in checkmk.
Ein roher Log

Ihr seht schon: Es gibt hier einen Service mit vielen Meldungen. Zudem ist diese Ansicht kaum anpassbar - also ein weiterer Schritt.

3. Event Console

Um die Event Console nutzen zu können, müsst Ihr die Checkmk-Instanz zunächst stoppen und die Konfiguration aufrufen:

sudo omd stop mysite
sudo omd config mysite

Aktiviert dann im Bereich Addons den Punkt MKEVENTD und startet die Instanz wieder.

checkmk config für ec.
Aktivieren der Event Console

In Checkmk muss nun die Weiterleitung an die Event Console eingerichtet werden. Die Regel: Service monitoring rules/Logwatch Event Console forwarding. Auch hier muss nicht zwangsweise etwas konfiguriert werden, hier bietet sich aber die Beschränkung auf bestimmte Log-Dateien an - falls es mal mehr werden. Konfiguration fertig, Änderungen aktivieren.

forwarding nach mk_logwatch.
Einträge von mk_logwatch an die EC weiterleiten

Kurze Zeit später füllen sich die Events und landen standardmäßig so in Checkmk:

logauszug in cmk.
Die Standardansicht von Events

4. Hübsch machen fürs Dashboard

Die Ansicht enthält für Log-Dateien sinnvolle Spalten wie eine Nummerierung oder das Vorkommen. Für den Ticker können sie aber weg. Also erstellt über Display/Clone builtin view eine Kopie der Ansicht und werft dort alle Spalten raus, die Ihr nicht braucht:

view-konfiguration in checkmk.
Die Ansicht braucht nur zwei Spalten

Hier bleiben also nur der Status und der eigentliche Text. Und das führt zu folgender Ansicht:

modifizierte ansicht mit log.
Die Spalten sind jetzt okay, der Kopf muss noch weg

Der Kopfbereich stört natürlich, der lässt sich aber über die Display Options entfernen. Einfach &display_options=t an die URL hängen:

http://192.168.178.68/mysite_22/check_mk/view.py?view_name=ec_events_rss&display_options=t

Und mit genau dieser URL geht es nun an die letzte Station, das Dashboard. Öffnet oder erstellt ein Dashboard und fügt über Add/Custom URL ein Dashlet zum Einbetten einer Webseite hinzu - die einzige Konfiguration: die URL:

dashlet-konfiguration.
Das Custom-URL-Dashlet

Und da wären wir am Ende wieder am Anfang:

log-dashlet im dashboard.
Die entschlackte Ansicht als Dashlet auf einem leeren Dashboard

Meine Empfehlung ab hier: Versteht das Ganze wie ein Lego-Modell, baut alles wieder auseinander und bastelt dann an eigenen Kreationen - flexibel genug ist der Werkzeugkasten jedenfalls.

Mehr zu Checkmk - oder etwas völlig anderes.

Mirco Lang

Freier Journalist, Exil-Sauerländer, (ziemlich alter) Skateboarder, Dipl.-Inf.-Wirt, Einzelhandelskaufmann, Open-Source-Nerd, Checkmk-Handbuchschreiber. Ex-Saturn'ler, Ex-Data-Becker'ler, Ex-BSI'ler. Computer-Erstkontakt: ca. 1982 - der C64 des großen Bruders eines Freunds. Wenn Ihr hier mehr über Open Source, Linux und Bastelkram lesen und Tutonaut unterstützen möchtet: Über Kaffeesponsoring via Paypal.freue ich mich immer. Schon mal im Voraus: Danke! Nicht verpassen: cli.help und VoltAmpereWatt.de. Neu: Mastodon

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Schaltfläche "Zurück zum Anfang"