Checkmk
to checkmk.com

1. Einleitung

Der Piggyback-Mechanismus wurde bereits in den frühen Zeiten von Checkmk eingeführt — und zwar im Rahmen der Überwachung von VMware. Hier ist die Situation, dass Daten von einem bestimmten Host abgefragt werden müssen, weil sie nur dort bereitstehen (z.B. von einem ESX-Hostsystem oder dem vCenter), diese aber im Monitoring einen ganz anderen Host betreffen (z.B. eine virtuelle Maschine).

Das ist mit dem normalen Mechanismus von Checkmk nicht zu realisieren, denn dieser ordnet Daten und Services, die er von einem Host holt, automatisch diesem zu. Und es wäre schließlich sehr unpraktisch für das Monitoring, wenn alle Informationen zu allen VMs immer direkt beim ESX-Host oder gar vCenter erschienen.

Der Begriff „Piggyback“ (im Deutschen „Huckepack“) drückt aus, dass Monitoring-Daten zu Host B quasi huckepack beim Abfragen von Host A mit übertragen werden.

Heute kommt Piggyback bei vielen weiteren Monitoring-Plugins zum Einsatz, z.B. bei der Überwachung von:

Neben Virtualisierungsumgebungen kann der Piggyback-Mechanismus auch beim Monitoring von Mobilgeräten (Mobileiron) oder dem Klima-Monitoring im Rechenzentrum (MQTT) eingesetzt werden. Da die Abfrageschnittstellen sehr simpel sind, ist es sehr einfach, den Piggyback-Mechanismus selbst zu verwenden. Sie können ihn beispielsweise beim Realisieren eigener Check-Plugins nutzen, um Daten aus einer Quelle beliebigen anderen Hosts zuzuordnen.

2. Das Piggyback-Prinzip

Das Grundprinzip von Piggyback funktioniert so: Ein Host A kennt nicht nur Monitoring-Daten zu sich selbst, sondern auch zu anderen Hosts — oder allgemeiner gesagt: zu anderen Objekten. So kennt z.B. ein ESX-Host den Zustand und viele aktuelle Metriken zu jeder seiner VMs. Der Host A wird in diesem Zusammenhang manchmal auch als Quell-Host (source host) bezeichnet.

Wenn Checkmk jetzt von A in seinem minütlichen Rhythmus die Monitoring-Daten abruft — sei es vom normalen Checkmk-Agenten oder von einem Spezialagenten über eine Hersteller-API --, bekommt es in der Antwort speziell markiert auch Daten zu den anderen Hosts/Objekten B, C usw. mitgeteilt. Diese Piggyback-Daten legt es dann für die spätere Verarbeitung in Dateien auf dem Checkmk-Server ab. Die Hosts B, C usw. werden als piggybacked Hosts bezeichnet.

Wenn Checkmk dann später die Monitoring-Daten von B oder C benötigt, liegen diese bereits in den Dateien vor und können direkt verarbeitet werden, ohne einen Agenten abzufragen:

Schematische Darstellung der indirekten Datenweitergabe über den Piggyback-Mechanismus.

Es ist auch möglich und sinnvoll, normales Monitoring und Piggyback zu kombinieren. Nehmen wir wieder das VMware-Beispiel: Vielleicht haben Sie ja in Ihrer VM B einen Checkmk-Agenten installiert, der lokale Informationen aus der VM auswertet, die dem ESX-Host nicht bekannt sind (z.B. die in der VM laufenden Prozesse). In diesem Fall wird der Agent abgefragt, und die Daten werden mit den Piggyback-Daten von Host A zusammengefasst:

Schematische Darstellung der kombinierten Datenweitergabe: Ein Teil der Daten kommt via Piggyback, der Rest direkt vom überwachten Host.

3. Piggyback in der Praxis

3.1. Einrichten von Piggyback

Die gute Nachricht ist, dass der Piggyback-Mechanismus häufig völlig automatisch funktioniert:

  • Wenn beim Abfragen von A Piggyback-Daten für andere Hosts entdeckt werden, werden diese automatisch für die spätere Auswertung gespeichert.

  • Wenn beim Abfragen von B Piggyback-Daten von einem anderen Host auftauchen, werden diese automatisch verwendet.

Allerdings ist — wie immer in Checkmk — alles konfigurierbar. So können Sie beispielsweise bei den Eigenschaften eines Hosts (Host B) im Kasten Monitoring agents einstellen, wie dieser auf vorhandene oder fehlende Piggyback-Daten reagieren soll:

Die Umleitung der Piggyback-Daten wird in den Agenten-Einstellungen festgelegt

Der Standard ist Use piggyback data from other hosts if present. Falls vorhanden, werden also Piggyback-Daten verwendet, und wenn keine da sind, verwendet der Host eben nur seine „eigenen“ Monitoring-Daten.

Bei der Einstellung Always use and expect piggyback data erzwingen Sie die Verarbeitung von Piggyback-Daten. Wenn diese fehlen oder veraltet sind, wird der Service Check_MK eine Warnung ausgeben.

Bei Never use piggyback data werden eventuell vorhandene Piggyback-Daten einfach ignoriert — eine Einstellung, die Sie nur in Ausnahmefällen brauchen werden.

3.2. Hosts müssen vorhanden sein

Damit ein Host Piggyback-Daten verarbeiten kann, muss dieser natürlich im Monitoring vorhanden sein. Im Beispiel von ESX bedeutet das, dass Sie Ihre VMs auch als Hosts in Checkmk aufnehmen müssen, damit sie überhaupt überwacht werden.

Mittlerweile können Sie dies mithilfe der dynamischen Konfiguration automatisieren und Hosts, für die Piggyback-Daten vorhanden sind, automatisch anlegen lassen.

3.3. Host-Namen und ihre Zuordnung

Im Beispiel oben war es irgendwie logisch, dass die Daten von Objekt B auch dem Host B im Monitoring zugeordnet wurden. Aber wie genau funktioniert das? Beim Piggyback-Mechanismus geht die Zuordnung immer über einen Namen. Der (Spezial-)Agent schreibt zu jedem Satz von Piggyback-Daten einen Objektnamen. Im Fall von ESX ist das z.B. der Name der virtuellen Maschine. Manche Plugins wie z.B. Docker haben auch mehrere Möglichkeiten, was als Name verwendet werden soll.

Damit die Zuordnung klappt, muss der Name des passenden Hosts in Checkmk natürlich identisch sein — auch die Groß-/Kleinschreibung betreffend.

Was aber, wenn die Namen der Objekte in den Piggyback-Daten für das Monitoring ungeeignet oder unerwünscht sind? Dafür gibt es den speziellen Regelsatz Hostname translation for piggybacked hosts, den Sie im Setup-Menü unter Setup > Agents > Agent access rules finden.

Um eine Umbenennung zu konfigurieren, führen Sie die folgenden zwei Schritte aus:

  1. Legen Sie eine Regel an und stellen Sie die Bedingung so ein, dass Sie auf dem Quell-Host greift — also quasi auf Host A.

  2. Legen Sie im Wert der Regel eine passende Namenszuordnung fest.

Hier ist ein Beispiel für den Wert der Regel. Es wurden zwei Dinge konfiguriert: Zunächst werden alle Host-Namen aus den Piggyback-Daten in Kleinbuchstaben umgewandelt. Danach werden noch die beiden Hosts vm0815 bzw. vm0816 in die Checkmk-Hosts mylnxserver07 bzw. mylnxserver08 umgewandelt:

Optionen der 'Hostname translation', Entfernen des Domain-Parts, Umwandlung nach Kleinbuchstaben oder explizites Mapping.

Flexibler ist die Methode mit regulären Ausdrücken, die Sie unter Multiple regular expressions finden. Diese bietet sich an, wenn die Umbenennung von vielen Hosts notwendig ist und diese nach einem bestimmten Schema erfolgt. Gehen sie wie folgt vor:

  1. Aktivieren Sie die Option Multiple regular expressions.

  2. Fügen Sie mit dem Knopf Add expression einen Übersetzungseintrag an. Jetzt erscheinen zwei Felder.

  3. Geben Sie im Feld Regular expression einen regulären Ausdruck ein, der auf die ursprünglichen Objektnamen matcht und der mindestens eine Subgruppe enthält — also einen Teilausdruck, der in runde Klammern gesetzt ist. Eine gute Erklärung zu diesen Gruppen finden Sie im Artikel zu regulären Ausdrücken.

  4. Geben Sie bei Replacement ein Schema für den gewünschten Namen des Ziel-Hosts an, wobei Sie die Werte, die mit den Subgruppen „eingefangen“ wurden, durch \1, \2 usw. ersetzen können.

Ein Beispiel für den regulären Ausdruck wäre z.B. vm(.*)-local. Die Ersetzung myvm\1 würde dann z.B. den Namen vmharri-local in myvmharri übersetzen.

4. Die Technik dahinter

4.1. Transport der Piggyback-Daten

Wie oben beschrieben werden die Piggyback-Daten zu anderen Hosts in der Agentenausgabe des Quell-Hosts transportiert. Die Ausgabe des Checkmk-Agenten ist ein einfaches textbasiertes Format, das der Artikel über die Agenten vorstellt.

Neu ist jetzt, dass im Output eine Zeile erlaubt ist, die mit <<<< beginnt und mit >>>> endet. Dazwischen steht ein Host-Name. Alle weiteren Monitoring-Daten ab dieser Zeile werden dann diesem Host zugeordnet. Hier ist ein beispielhafter Auszug, der die Sektion <<<esx_vsphere_vm>>> dem Host 316-VM-MGM zuordnet:

<<<<316-VM-MGM>>>>
<<<esx_vsphere_vm>>>
config.datastoreUrl url /vmfs/volumes/55b643e1-3f344a10-68eb-90b11c00ff94|uncommitted 12472944334|name EQLSAS-DS-04|type VMFS|accessible true|capacity 1099243192320|freeSpace 620699320320
config.hardware.memoryMB 4096
config.hardware.numCPU 2
config.hardware.numCoresPerSocket 2
guest.toolsVersion 9537
guest.toolsVersionStatus guestToolsCurrent
guestHeartbeatStatus green
name 316-VM-MGM

Durch eine Zeile mit dem Inhalt <<<<>>>> kann diese Zuordnung wieder aufgehoben werden. Der weitere Output gehört dann wieder zum Quell-Host.

Bei der Verarbeitung der Agentenausgabe extrahiert Checkmk die Teile, die für andere Hosts bestimmt sind, und legt sie in Dateien unterhalb von tmp/check_mk/piggyback ab. Darunter befindet sich für jeden Ziel-Host (z.B. für jede VM) ein Unterverzeichnis — in unserem Beispiel also ein Ordner mit dem Namen B. Darin ist dann pro Quell-Host eine Datei mit den eigentlichen Daten. Deren Name wäre in unserem Beispiel A. Warum ist das so kompliziert gelöst? Nun, ein Host kann in der Tat Piggyback-Daten von mehreren Hosts bekommen, somit wäre eine einzelne Datei nicht ausreichend.

Tipp: Wenn Sie neugierig sind, wie die Piggyback-Daten bei Ihnen aussehen, finden Sie die Agentenausgaben Ihrer Hosts in der Monitoring-Instanz im Verzeichnis tmp/check_mk/cache. Eine Übersicht über alle beteiligten Dateien und Verzeichnisse finden Sie weiter unten.

4.2. Verwaiste Piggyback-Daten

Wenn Sie in in einer Umgebung arbeiten, in der Hosts automatisiert den Quell-Host wechseln, empfehlen wir die Nutzung der dynamischen Host-Konfiguration. Wird deren Einsatz nicht benötigt oder erwünscht (beispielsweise weil virtuelle Maschinen manuell umgezogen werden), dann kann es Ihnen passieren, dass Piggyback-Daten für einen Host vorhanden sind, den Sie in Checkmk gar nicht angelegt haben. Das kann Absicht sein, vielleicht aber auch ein Fehler — z.B. weil ein Name nicht genau übereinstimmt.

In den „Treasures“ finden Sie ein Skript mit dem Namen find_piggy_orphans, das Checkmk nach Piggyback-Daten durchsucht, zu denen es keinen Host im Monitoring gibt. Dieses rufen Sie einfach ohne Argumente auf. Es gibt dann pro Zeile den Namen von einem nicht überwachten piggybacked Host aus:

OMD[mysite]:~$ share/doc/check_mk/treasures/find_piggy_orphans
fooVM01
barVM02

Diese Ausgabe ist „sauber“, und Sie können Sie z.B. in einem Skript weiterverarbeiten.

4.3. Piggyback im verteilten Monitoring

Beachten Sie, dass in verteilten Umgebungen aktuell QuellHost und die piggybacked Hosts in der gleichen Instanz überwacht werden müssen. Dies liegt daran, dass die Übertragung der Daten zwischen den Hosts aus Effizienzgründen mit einem lokalen Dateiaustausch über das Verzeichnis tmp/check_mk läuft.

Zukünftige Versionen von Checkmk werden eventuell einen Mechanismus anbieten, der optional den Austausch von Piggyback-Daten über Instanzgrenzen hinweg ermöglicht.

5. Dateien und Verzeichnisse

5.1. Pfade auf dem Checkmk-Server

PfadBedeutung

tmp/check_mk/piggyback/

Ablageort für Piggyback-Daten

tmp/check_mk/piggyback/B/

Verzeichnis von Piggyback-Daten für Host B

tmp/check_mk/piggyback/B/A

Datei mit Piggyback-Daten von Host A für Host B

tmp/check_mk/piggyback_sources/

Metainformationen zu den Hosts, die Piggyback-Daten erzeugen

tmp/check_mk/cache/A

Agentenausgabe von Host A — inklusive eventuell vorhandenen Piggyback-Daten in Rohform

Auf dieser Seite