1. Warum überhaupt eigene Checks erstellen?
Checkmk überwacht durch die große Anzahl an mitgelieferten Check-Plugins bereits sehr viele relevante Daten. Dennoch ist jede IT-Umgebung einzigartig, so dass sich oft sehr individuelle Anforderungen ergeben. Mit den lokalen Checks (local checks) sind Sie in der Lage, durch kleine Erweiterungen des Agenten auf dem Ziel-Host schnell und einfach eigene Services zu erstellen.
Diese lokalen Plugins unterscheiden sich dabei in einem wesentlichen Punkt von anderen Checks: Die Berechnung des Status erfolgt direkt auf dem Host, auf dem die Daten auch abgerufen werden.
Dadurch entfällt die Erstellung von Checks in Python und Sie sind bei der Wahl der Skriptsprache völlig frei. Zudem geben lokale Checks den Admins von Servern weit reichende Freiheiten. Monitoring-Admins müssen nur noch die Entscheidung treffen, ob sie neue lokale Checks als Service aufnehmen.
 |
Sie können den Mechanismus von lokalen Checks mit allen von Checkmk unterstützten Methoden des Transports von Agentendaten kombinieren: Datenquellen, Spezialagenten, Piggyback und Spool-Dateien. Die Daten aus allen Quellen werden zusammengeführt, aber bei (versehentlicher) doppelter Vergabe des Servicenamens kommt es zu Konflikten. Achten Sie daher auf möglichst eindeutige Servicenamen. |
2. Einen einfachen lokalen Check schreiben
2.1. Skript erstellen
Sie können einen lokalen Check in jeder beliebigen Programmiersprache schreiben, die der Ziel-Host unterstützt. Das Skript muss so konstruiert sein, dass es pro Check eine Statuszeile ausgibt, die aus vier Teilen besteht. Hier ist ein Beispiel:
0 "My service" myvalue=73 My output text which may contain spacesDie vier Teile sind durch Leerzeichen getrennt und haben folgende Bedeutung:
| Beispielwert | Bedeutung | Beschreibung |
|---|---|---|
|
Status |
Der Zustand des Services wird als Ziffer angegeben: |
|
Service-Name |
Der Name des Services, wie er in Checkmk angezeigt wird, in der Ausgabe des Checks in doppelten Anführungszeichen. |
|
Wert und Metriken |
Metrikwerte zu den Daten. Sie finden im Kapitel zu den Metriken näheres zum Aufbau. Alternativ können Sie ein Minuszeichen setzen, wenn der Check keine Metriken ausgibt. |
|
Statusdetail |
Details zum Status, wie sie in Checkmk angezeigt werden. Dieser Teil kann auch Leerzeichen enthalten. |
Zwischen den vier Teilen dieser Ausgabe muss immer genau ein Leerzeichen (ASCII 0x20) stehen.
Innerhalb der Statusdetails können beliebige Leerzeichen in beliebiger Reihenfolge verwendet werden.
 |
Abweichungen von der soeben beschriebenen Spezifikation können funktionieren, müssen es aber nicht. Künftige Versionen von Checkmk werden dieses Ausgabeformat möglicherweise erzwingen und abweichende lokale Checks ignorieren. |
Wenn Sie wegen einer möglichen Ausgabe unsicher sind, können Sie diese einfach testen, indem Sie ein kleines Skript mit dem Kommando echo schreiben.
Fügen Sie in das echo-Kommando Ihre Ausgabe ein, die Sie testen möchten.
Unser Beispiel verwendet außen die doppelten Anführungszeichen, da innerhalb stehende Variablen (Umgebungsvariablen und im Skript gesetzte) ausgewertet werden.
Das hat zur Folge, dass Sie die Anführungszeichen für den Service-Namen mit \ maskieren müssen, damit diese Zeichen nicht von der Shell als Ende und Anfang eines Strings interpretiert (und damit aus der Ausgabe entfernt) werden:
#!/bin/bash
echo "0 \"My 1st service\" - This static service is always OK"Für Windows-Hosts sieht so ein Testskript sehr ähnlich aus:
@echo off
echo 0 "My 1st service" - This static service is always OKBeide Skripte führen in der Ausgabe zum selben Ergebnis:
0 "My 1st service" - This static service is always OKFür Checkmk ist nur diese Ausgabe relevant, nicht wie Sie diese Ausgabe erzeugt haben.
Sie können übrigens beliebig viele Ausgaben in einem Skript erzeugen. Für jede ausgegebene Zeile wird dann ein eigener Service in Checkmk erstellt. Daher sind in der Ausgabe auch keine Zeilenumbruchzeichen erlaubt – es sei denn, sie sind maskiert, zum Beispiel für eine mehrzeilige Ausgabe in Checkmk.
Wie Sie prüfen, ob das lokale Skript vom Agenten richtig aufgerufen wird, sehen Sie in der Fehleranalyse.
|
Wenn der Nagios-Kern verwendet wird (immer in der Checkmk Raw) sind folgende Sonderzeichen im Service-Namen nicht erlaubt:
|
2.2. Skript verteilen
Nachdem das Skript geschrieben ist, können Sie es an die entsprechenden Hosts verteilen. Der Pfad unterscheidet sich je nach Betriebssystem. Eine Liste der Pfade finden Sie in Dateien und Verzeichnisse weiter unten.
Vergessen Sie nicht, das Skript auf Unix-artigen Systemen ausführbar zu machen. Der Pfad in dem Beispiel bezieht sich auf Linux (Agentenpaket mit Standardeinstellungen):
root@linux# chmod +x /usr/lib/check_mk_agent/local/mylocalcheckWenn Sie die Agentenbäckerei nutzen, können Sie das Skript auch regelbasiert verteilen. Mehr zur Regelerstellung erfahren Sie im Kapitel Verteilung über die Agentenbäckerei.
2.3. Den Service ins Monitoring aufnehmen
Bei jedem Aufruf des Checkmk-Agenten wird auch der im Skript enthaltene lokale Check ausgeführt und an die Ausgabe des Agenten angehängt. Die Service-Erkennung funktioniert also wie bei anderen Services auch automatisch:
Nachdem Sie den Service ins Monitoring übernommen und die Änderungen aktiviert haben, ist die Einrichtung eines selbst erstellten Services mit Hilfe eines lokalen Checks bereits abgeschlossen. Falls es bei der Service-Erkennung zu Problemen kommen sollte, kann Ihnen die Fehleranalyse weiterhelfen.
3. Metriken
3.1. Metriken festlegen
Sie können in einem lokalen Check auch Metriken festlegen. Die kürzest mögliche Syntax für Metrikdaten ist:
metricname=valuewobei value der aktuelle Wert ist.
Die vollständige Syntax für Metrikdaten lautet:
metricname=value;warn;crit;min;maxHier legen warn und crit die (oberen) Schwellwerte fest.
Damit diese Schwellwerte auch im Graphen dargestellt werden, muss dynamische Auswertung aktiviert sein (Status P).
Die Berechnung des Zustands erfolgt dann durch Checkmk.
Die zuletzt angegebenen Parameter für min und max fixieren den Wertebereich.
Ein vollständiges Beispiel kann demnach so aussehen:
count=73;80;90;0;100Die Werte werden mit Semikolon getrennt.
Wird ein Wert nicht benötigt, so bleibt das Feld leer bzw. wird am Ende weggelassen, wie im Folgenden für warn, crit und max:
count=42;;;0 |
In den kommerziellen Editionen
können die Werte für |
3.2. Namen und Einheiten von Metriken
Metrikdefinitionen für lokale Checks unterscheiden sich nicht von den Metrikdefinitionen bei anderen Arten von Checks. Letztlich haben Sie drei Möglichkeiten, Metriken mit Einheiten und gut verständlichen Namen zu versehen:
Sie greifen auf vorhandene Metrikdefinitionen zu, die für den benötigten Zweck "passen"
Sie erstellen eigene Metriken ad-hoc und eindeutig – dies ist oft ausreichend für reine Zähler
Sie erstellen eigene Metriken und hinterlegen eine Metrikdefinition – so erhalten Sie die höchste Flexibilität
Vorhandene Metrikdefinitionen zuweisen
Der einfachste Weg zu passenden Einheiten, einer automatisch angepassten Legende und oft einem Perf-O-Meter besteht in der Verwendung vorhandener Metrikdefinitionen.
In diesem Artikel verwenden einige Beispiele die Bezeichner humidity oder temp.
Für beide existieren vordefinierte Metrikdefinitionen, welche die Metrik mit den korrekten Einheiten versehen.
In beiden Fällen stellt die Metrikdefinition ein Perf-O-Meter bereit und die Legenden der Graphen zeigen dann Grad Celsius und relative Luftfeuchte in Prozent.
Die wichtigsten mitgelieferten Metrikdefinitionen können Sie in ~/lib/python3/cmk/plugins/collection/graphing (GitHub) nachschlagen, weitere unter ~/lib/python3/cmk/plugins/*/graphing (GitHub) und die verwendeten Einheiten in ~/lib/python3/cmk/gui/plugins/metrics/unit.py (GitHub).
Die Suche nach exakt passenden Metrikdefinitionen lohnt oft, da Checkmk für zusammengehörige Metriken auch kombinierte Graphen bereitstellt.
Metriken ad-hoc definieren
In den ersten Beispielen dieses Artikels haben wir Metriknamen wie myvalue, count oder metricname verwendet.
Ohne passende Metrikdefinition werden diese in der Legende des Graphen mit einem großen Anfangsbuchstaben versehen und Unterstriche werden durch Leerzeichen ersetzt.
Aus outgoing_queue_size wird also das gut lesbare Outgoing queue size.
Da ein reiner Zähler keine Einheit benötigt, erfüllt hier bereits der sinnvoll gewählte Identifikator ohne zusätzliche Metrikdefinition den Zweck.
Werden Einheiten benötigt, müssen Sie diese gegebenenfalls mit in den Namen packen.
Problematisch wird es, wenn der Versuch, eine Metrik ad-hoc zu definieren versehentlich den im letzten Abschnitt erklärten Effekt hat und eine vorhandene Metrikdefinition zuweist.
Maximale Verwirrung kann vor allem dann auftreten, wenn Einheiten nicht zusammenpassen, beispielsweise eine mitgelieferte Metrik eine prozentuale Skala mit Fließkommazahlen zwischen 0 und 100 % verwendet, der Wertebereich Ihres lokalen Checks aber eine nach oben offene Anzahl als Festkommazahl liefert.
Oder Sie haben eine Warteschlange für gegenwärtige Anfragen (Current requests queue), welche Sie einfach current nennen wollen – das Ergebnis wäre die Zuweisung der Metrikdefinition für Stromstärke.
Hier wäre also current_requests_queue eine viel bessere Wahl.
Ganz sicher gehen Sie mit einem zusätzlichen Präfix – etwa: mycompany_current_requests_queue.
Metrikdefinitionen selbst schreiben
Metrikdefinitionen für lokale Checks unterscheiden sich nicht von den Metrikdefinitionen bei anderen Arten von Checks. Falls Sie Graphen mit Legende und Perf-O-Meter benötigen – und dafür eigene Metrikdefinitionen erforderlich sind –, lesen Sie den Metriken betreffenden Abschnitt im Artikel zur Programmierung agentenbasierter Check-Plugins.
3.3. Mehrere Metriken
Sie können auch mehrere Metriken ausgeben lassen.
Diese werden dann durch das "Pipe"-Zeichen | getrennt, zum Beispiel so:
count1=42|count2=23Achtung: Auf Windows-Hosts müssen Sie diesen Pipes im Skript noch einen Zirkumflex (^) voranstellen, damit diese Pipes auch in der Ausgabe ankommen.
@echo off
echo 0 "My 2nd service" count1=42^|count2=23 A service with 2 graphsEine komplette Ausgabe mit zwei Metriken sieht dann etwa so aus:
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
0 "My 2nd service" count1=42|count2=23 A service with 2 graphsNachdem Sie auch den neuen Service ins Monitoring aufgenommen haben, sehen Sie in der Service-Liste im Feld Summary den Text zum Statusdetail. Nach Anklicken des Services wird die Seite mit den Service-Details gezeigt. Die Metriken zeigt das Feld Details, und darunter sehen Sie die von Checkmk automatisch erzeugten Service-Graphen:
|
Dieses Beispiel nutzt Auswertung auf dem Host ( |
3.4. Status dynamisch berechnen lassen
In den vorherigen Kapiteln haben Sie erfahren, wie Sie Werte für Metriken übergeben und damit Graphen erzeugen können. Der nächste naheliegende Schritt ist es nun, zusätzlich übergebene Schwellwerte für eine dynamische Berechnung des Service-Zustands zu nutzen. Checkmk bietet genau diese Möglichkeit, um die Aufbereitung der erhaltenen Daten konsistent mit vielen über Plugins berechneten Zuständen zu machen.
Wenn Sie im ersten Feld der Ausgabe, das den Status bestimmt, statt einer Ziffer den Buchstaben P übergeben, wird der Service-Zustand anhand der übergebenen Schwellwerte berechnet.
Zusätzlich zum Ist-Wert werden dann auch die übergebenen Schwellwerte als gelbe und rote Linie im Graphen angezeigt.
|
Die dynamische Berechnung bedeutet nicht, dass Schwellwerte mit in Checkmk gesetzten Monitoring-Regeln angepasst werden können. Es werden immer die im lokalen Check mitgelieferten Schwellwerte zur Berechnung herangezogen. |
Eine Ausgabe würde dann so aussehen:
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
P "My 1st dynamic service" count=40;30;50 Result is computed from two threshold values
P "My 2nd dynamic service" - Result is computed with no values… und die Anzeige in einer Service-Ansicht so:
Die Anzeige unterscheidet sich in zwei Punkten von derjenigen, die bisher zu sehen war:
Für Services im Zustand WARN oder CRIT zeigt die Summary des Services alle wichtigen Informationen der Metriken (Name, Wert, Schwellwerte). So können Sie immer nachvollziehen, wie dieser Zustand aus einem Wert berechnet wurde. Für alle anderen Zustände werden die Metrikinformationen nur im Feld Details angezeigt.
Wenn keine Metriken übergeben werden, ist der Service-Zustand immer OK.
Wechsel zwischen dynamischer und statischer Zustandsermittlung
Es kann legitim sein, in dem Skript, das den lokalen Check bereitstellt, zwischen dynamischer und statischer Zustandsermittlung zu wechseln.
Nehmen wir als Beispiel ein Backup-Skript, welches eine Spool-Datei im Format eines lokalen Checks schreibt.
Dieses Skript sollte P für die Zustandsermittlung nach Backup-Dauer schreiben:
P "Backup stuff" duration=2342;1800;3600 Successfully created the backup. Good luck restoring.Schlägt das Backup aber nach kurzer Zeit fehl, wird der Status durch den Rückgabestatus des Backup-Skriptes und nicht durch Schwellwerte bestimmt. In diesem Fall muss es den Status setzen.
2 "Backup stuff" duration=123;1800;3600 Backup failed. Nuff said.Dass in diesem Fall keine Schwellwerte im Graphen angezeigt werden, ist nur sinnvoll. Denn nicht die benötigte Dauer bis zum (fehlgeschlagenen) Backup ist hier relevant, sondern die Tatsache, dass es nicht erfolgreich war.
3.5. Obere und untere Schwellwerte
Manche Parameter haben nicht nur obere, sondern auch untere Schwellwerte. Ein Beispiel dafür ist die Luftfeuchtigkeit. Für solche Fälle bietet der lokale Check die Möglichkeit, jeweils zwei Schwellwerte für die Zustände WARN und CRIT zu übergeben. Sie werden durch einen Doppelpunkt getrennt und stellen jeweils den unteren und den oberen Schwellwert dar.
In der allgemeinen Syntax sieht das so aus:
metricname=value;warn_lower:warn_upper;crit_lower:crit_upper… im Beispiel so:
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
P "My 3rd service" humidity=37;40:60;30:70 A service with lower and upper thresholds… und in der Anzeige einer Service-Ansicht so:
Falls es Ihnen nur um untere Schwellwerte geht, lassen Sie die Felder der oberen Schwellwerte weg:
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
P "My 4th dynamic service" count_lower=37;40:;30: A service with lower thresholds onlyMit dieser Ausgabe legen Sie fest, dass der Service bei einem Wert kleiner 40 WARN und kleiner 30 CRIT werden soll: beim festgelegten Wert 37 wird der Service also den WARN-Zustand erhalten.
|
Das Metrik- und Graphing-System von Checkmk ist aufgrund von Abwägungen zugunsten von Einfachheit auf obere Schwellwerte eingeschränkt. Dies bedeutet, dass zwar die Ermittlung des Status eines Dienstes erwartungsgemäß funktioniert, aber die in der Metrik- und Graphing-Komponente dargestellten Informationen untere Schwellwerte ignorieren. Daher fehlen in der Checkmk-GUI bei ausschließlicher Verwendung unterer Schwellwerte Dinge wie gelbe und rote Linien in Graphen, Perf-O-Meter und Service performance data komplett. |
3.6. Mehrzeilige Ausgaben
Auch die Option, die Ausgabe über mehrere Zeilen zu verteilen, steht Ihnen
zur Verfügung.
Da Checkmk unter Linux läuft, können Sie mit der Escape-Sequenz \n arbeiten, um einen Zeilenumbruch zu erzwingen.
Auch wenn Sie, bedingt durch die Skriptsprache, den Backslash selbst maskieren müssen, wird das von Checkmk korrekt interpretiert:
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
P "My service" humidity=37;40:60;30:70 My service output\nA line with details\nAnother line with detailsIn den Details des Services können Sie dann diese zusätzlichen Zeilen unter der Summary sehen:
4. Asynchrone Ausführung
Die Ausgabe lokaler Checks kann, wie auch die von Agenten-Plugins, zwischengespeichert werden (caching). Das kann nützlich sein, wenn Skripte längere Zeit zur Ausführung benötigen. Ein solches Skript wird dann asynchron und nur in einem definierten Zeitintervall ausgeführt und die letzte Ausgabe zwischengespeichert. Wird der Agent vor Ablauf der Zeit erneut abgefragt, verwendet er für den lokalen Check diesen Cache und liefert ihn in der Agentenausgabe zurück.
|
Das Caching steht nur für AIX, FreeBSD, Linux, OpenWrt und Windows zur Verfügung. Nutzen Sie auf anderen Plattformen Cronjobs in Kombination mit dem Spool-Verzeichnis. |
4.1. Konfiguration unter Linux
Unter Linux oder einem anderen Unix-artigen Betriebssystem kann jedes Plugin asynchron ausgeführt werden. Für einen lokalen Check ist die notwendige Konfiguration sehr ähnlich zu der eines Plugins. Legen Sie dazu ein Unterverzeichnis an, das so heißt, wie die Anzahl der Sekunden, die die Ausgabe zwischengespeichert werden soll und legen Sie Ihr Skript in diesem Unterverzeichnis ab.
In folgenden Beispiel wird der lokale Check nur alle 10 Minuten (600 Sekunden) ausgeführt:
root@linux# /usr/lib/check_mk_agent/local/600/mylocalcheck
2 "My cached service" count=4 Some output of a long running scriptDie zwischengespeicherten Daten werden in ein Cache-Verzeichnis geschrieben.
Für einen Service, der zwischengespeicherte Daten liefert, werden die Cache-spezifischen Informationen in der Service-Ansicht hinzugefügt:
4.2. Konfiguration unter Windows
Unter Windows erfolgt die Konfiguration ebenfalls analog zu der eines Plugins. Statt mit einem speziellen Unterverzeichnis wie bei Linux & Co werden die Optionen in einer Konfigurationsdatei gesetzt:
local:
enabled: yes
execution:
- pattern : $CUSTOM_LOCAL_PATH$\mylocalcheck.bat
async : yes
run : yes
cache_age : 600Wie Sie oben sehen, können Sie unter Windows die asynchrone Ausführung (mit async) und das Zeitintervall (mit cache_age) getrennt konfigurieren.
Alternativ können Sie die Konfiguration unter Windows auch in der Agentenbäckerei durchführen.
5. Verteilung über die Agentenbäckerei
Wenn Sie die Agentenbäckerei bereits nutzen, können Sie die Skripte mit lokalen Checks auch über diesen Weg an mehrere Hosts verteilen.
Erstellen Sie dazu auf dem Checkmk-Server als Instanzbenutzer unterhalb von ~/local/share/check_mk/agents/ zuerst das Verzeichnis custom und darin für jedes Paket von lokalen Checks einen Unterverzeichnisbaum:
OMD[mysite]:~$ cd ~/local/share/check_mk/agents
OMD[mysite]:~$ ~/local/share/check_mk/agents$ mkdir -p custom/mycustompackage/lib/local/Das Paketverzeichnis im obigen Beispiel ist mycustompackage.
Darunter markiert das lib-Verzeichnis das Skript als Plugin oder lokalen Check.
Das nachfolgende Verzeichnis local ordnet die Datei dann eindeutig zu.
Legen Sie in diesem Verzeichnis das Skript mit dem lokalen Check ab.
Wichtig: Unter Linux können Sie die asynchrone Ausführung analog konfigurieren wie im vorherigen Kapitel beschrieben, indem Sie nun unter custom/mycustompackage/lib/local/ ein Verzeichnis mit der Sekundenzahl des Ausführungsintervalls erzeugen und dort das Skript ablegen.
Unter Windows können Sie dafür die Regelsätze Set execution mode for plugins and local checks und Set cache age for plugins and local checks nutzen. Diese und weitere Regelsätze für lokale Checks unter Windows finden Sie in der Agentenbäckerei unter Agent rules > Windows Agent.
In der Konfigurationsumgebung von Checkmk wird dann das Paketverzeichnis mycustompackage als neue Option angezeigt:
Öffnen Sie Setup > Agents > Windows, Linux, Solaris, AIX, erstellen Sie eine neue Regel mit Agents > Agent rules > Generic options > Deploy custom files with agent und wählen Sie das eben erstellte Paket aus:
Checkmk wird nun selbstständig den lokalen Check im Installationspaket der jeweiligen Betriebssysteme richtig einordnen. Nachdem Sie die Änderungen aktiviert und die Agenten gebacken haben, sind Sie mit der Konfiguration auch schon fertig. Die Agenten müssen nun nur noch neu verteilt werden.
6. Fehleranalyse
6.1. Skript testen
Wenn Sie bei einem selbst geschriebenen Skript auf Probleme stoßen, sollten Sie die folgenden potentiellen Fehlerquellen prüfen:
Liegt das Skript im richtigen Verzeichnis?
Ist das Skript ausführbar und stimmen die Zugriffsberechtigungen? Das ist vor allem relevant, wenn Sie den Agenten oder das Skript nicht unter root oder dem LocalSystem-Konto ausführen.
-
Ist die Ausgabe konform zur vorgegebenen Syntax? Die Ausgabe des lokalen Checks muss der Syntax entsprechen, wie sie in den Kapiteln Skript erstellen und Metriken beschrieben ist. Andernfalls kann die fehlerfreie Ausführung nicht garantiert werden.
Probleme und Fehler können insbesondere dann entstehen, wenn ein lokaler Check eine Aufgabe erfüllen soll, die ein vollwertiges Check-Plugin erfordert, beispielsweise, wenn die Ausgabe des lokalen Checks selbst einen Sektions-Header (section header) enthält oder die Definition eines Host-Namens, wie er beim Transport von Piggyback-Daten verwendet wird.
|
Beim direkten Aufruf des Agentenskripts oder des Plugins in einer Shell unter Linux stehen möglicherweise andere Umgebungsvariablen zur Verfügung als beim Aufruf durch den Agent Controller des Checkmk-Agenten. Unter Windows kommt hinzu, dass der Agent Controller unter dem LocalSystem-Konto läuft, der Aufruf im Terminal aber unter einem normalen Benutzer oder Administrator erfolgt. Zusätzlich zur anderen Umgebung kann dies fehlende Berechtigungen bedeuten. Um die Ausgabe des Agentenskripts möglichst nahe an den Bedingungen zu analysieren, unter denen der Checkmk-Agent aufgerufen wird, sollten Sie daher nach Möglichkeit den Agent Controller im Dump-Modus verwenden. |
6.2. Agentenausgabe auf dem Ziel-Host testen
Wenn das Skript selbst korrekt ist, können Sie den Agenten auf dem Host ausführen.
Bei Unix-artigen Betriebssystemen, wie Linux, BSD und so weiter, bietet sich der Befehl grep an, um nach einem bestimmten Textmuster zu suchen.
Mit der Option -A bestimmen Sie die Anzahl der zusätzlichen Zeilen, die nach einem Treffer angezeigt werden sollen.
Sie können diese Zahl entsprechend der Anzahl der erwarteten Ausgabezeilen anpassen:
root@linux# cmk-agent-ctl dump | grep -v grep | grep -A2 "<<<local"
<<<local:sep(0)>>>
P "My service" humidity=37;40:60;30:70 My service output\nA line with details\nAnother line with details
cached(1618580356,600) 2 "My cached service" count=4 Some output of a long running scriptIn der letzten Zeile erkennen Sie einen zwischengespeicherten Service an der vorangestellten cache-Information mit der aktuellen Unixzeit und dem Ausführungsintervall in Sekunden.
Unter Windows können Sie mit der PowerShell und dem „Cmdlet“ Select-String ein sehr ähnliches Resultat erreichen wie mit dem grep-Befehl unter Linux. Im folgenden Befehl bestimmen die beiden Ziffern hinter dem Parameter Context wie viele Zeilen vor und nach dem Treffer ausgegeben werden sollen:
PS C:\Program Files (x86)\checkmk\service> ./cmk-agent-ctl.exe dump | Select-String -Pattern "<<<local" -Context 0,3
> <<<local:sep(0)>>>
0 "My 1st service" - This static service is always OK
cached(1618580520,600) 1 "My cached service on Windows" count=4 Some output of a long running script |
Je nach Umgebung, verwendeter Programmiersprache, Windows-Version und einigen weiteren Bedingungen, sind Sie oft unter Windows mit dem Zeichensatz UTF-16 konfrontiert. Zudem ist dort häufig die Kombination aus Carriage Return und Line Feed für Zeilenumbrüche anzutreffen. Checkmk als Linux-Anwendung erwartet aber ohne wenn und aber UTF-8 und einfache Line Feeds. Der Zeichensatz-bezogenen Fehlersuche widmen wir im Artikel zu Spool-Verzeichnis ein eigenes Kapitel. |
6.3. Agentenausgabe auf dem Checkmk-Server testen
Zuletzt können Sie die Verarbeitung der Skriptausgaben auch auf dem Checkmk-Server mit dem Befehl cmk testen — einmal die Service-Erkennung:
OMD[mysite]:~$ cmk -IIv --detect-plugins=local mycmkserver
Discovering services and host labels on: mycmkserver
mycmkserver:
...
+ EXECUTING DISCOVERY PLUGINS (1)
2 local
SUCCESS - Found 2 services, no host labels… und mit einem ähnlichen Befehl auch die Verarbeitung der Serviceausgabe:
OMD[mysite]:~$ cmk -nv --detect-plugins=local mycmkserver
Checkmk version 2.0.0p2
+ FETCHING DATA
...
+ PARSE FETCHER RESULTS
Received no piggyback data
My cached service Some output of a long running script(!!), Cache generated 6 minutes 52 seconds ago, Cache interval: 10 minutes 0 seconds, Elapsed cache lifespan: 68.71%
My service My service output\, humidity: 37.00 (warn/crit below 40.00/30.00)(!)Für beide Befehle haben wir die Ausgabe um für dieses Thema nicht relevante Zeilen gekürzt.
Alternativ können Sie im Monitoring in der Service-Liste beim Dienst Check_MK in der Spalte Icons den Menüeintrag Download agent output wählen. Sie erhalten dann eine Textdatei mit der gesamten Agentenausgabe.
Wenn es in den lokalen Checks Fehler gibt, wird Checkmk Sie in der Serviceausgabe darauf hinweisen. Das gilt sowohl für fehlerhafte Metriken, als auch für falsche, unvollständige Informationen in der Skriptausgabe oder einen ungültigen Status. Diese Fehlermeldungen sollen Ihnen helfen, die Fehler in den Skripten schnell zu identifizieren.
7. Dateien und Verzeichnisse
Alle angegebenen Pfade beziehen sich auf mit Standardkonfiguration gepackte Installationspakete. Falls Sie ein ungepacktes Agentenskript installiert oder die Installationsverzeichnisse per Bakery-Regel angepasst haben, schlagen Sie die Pfade im Skript selbst nach, respektive passen Sie diese auf Ihre Konfiguration hin an.
7.1. Skript-Verzeichnis auf dem Ziel-Host
In diesen Verzeichnissen legen Sie lokale Checks ab. Lokale Checks können beliebige ausführbare Dateien sein.
| Pfad | Betriebssystem |
|---|---|
|
AIX, Linux und Solaris |
|
Windows |
7.2. Cache-Verzeichnis auf dem Ziel-Host
Hier werden zwischengespeicherte Daten einzelner Sektionen, u.a. der local Sektion, abgelegt und dem Agenten, solange die Daten gültig sind, bei jeder Ausführung wieder angehängt.
| Pfad | Betriebssystem |
|---|---|
|
AIX, Linux und Solaris |