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-Host-System 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 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 wie in der folgenden Abbildung dargestellt. Ein Host A kennt nicht nur seine Monitoring-Daten sondern auch die anderer Hosts — oder allgemeiner gesagt: anderer Objekte. So kennt z.B. ein ESX-Host den Zustand und viele aktuelle Metriken zu jeder seiner virtuellen Maschinen (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 Piggyback-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.

CEE In den kommerziellen Editionen 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.

Hinweis: Piggyback-Daten von Hosts, deren Namen mit einem Punkt beginnen, werden nicht in Checkmk verarbeitet. Dies betrifft z.B. Namen wie ., .hostname oder .hostname.domain.com. Um diese Hosts ins Monitoring aufzunehmen, müssen die Host-Namen wie beschrieben geändert werden.

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? Ungeeignet sind z. B. Namen von Piggyback-Hosts, die nur aus einem Punkt bestehen oder mit einem Punkt beginnen, wie .myhostname, da diese in Checkmk nicht verarbeitet werden. Für die Umbenennung von Piggyback-Hosts gibt es einen 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.

3.4. Veraltete Piggyback-Daten

Verändert sich Ihr Netzwerk, so können sich auch die Piggyback-Daten ändern. Das wirft neue Fragen auf. Wie reagiert das Monitoring darauf, wenn ein Host nicht erreichbar ist? Was passiert, wenn Piggyback-Daten veralten, zum Beispiel, weil das Objekt temporär - oder sogar dauerhaft - nicht mehr vorhanden ist? Werden alle Piggyback-Daten gleich behandelt oder gibt es Unterschiede? Wie bei vielen anderen Themen in Checkmk ist das Verhalten auch hier wieder Einstellungs- und damit Regelsache. Mit der Regel Processing of piggybacked host data, die Sie unter Setup > Agents > Agent access rules finden, können Sie verschiedene Optionen einstellen.

Im Abschnitt Processing of piggybacked host data geben Sie die eigentlich interessanten Angaben zur Verarbeitung der Piggyback-Daten an.

Festlegung der Regeln für veraltete Piggyback-Daten.

Checkmk erleichtert Ihnen die Arbeit bei der Verwaltung der Piggyback-Daten. So entfernt es unter anderem automatisch alle Hosts/Objekte, zu denen keine Piggyback-Daten (mehr) von einem Quell-Host geliefert werden. Mit der Option Keep hosts while piggyback source sends piggyback data only for other hosts legen Sie fest, nach welcher Zeit die betroffenen Dateien mit Piggyback-Daten gelöscht werden. Achten Sie darauf, dass dieser Zeitraum mindestens so groß sein muss wie das Check-Intervall für die Piggyback-Hosts.

Über die beiden Optionen in Set period how long outdated piggyback data is treated as valid legen Sie fest, für wie lange vorhandene Piggyback-Daten noch als valide angesehen werden sollen, wenn der Host keine neuen Daten mehr liefert. Nach Ablauf des definierten Zeitraums werden die Services, die auf den Piggyback-Daten basieren, als stale angezeigt. Außerdem legen Sie den Zustand des Services Check_MK in diesem Zeitraum fest. Insbesondere wenn es immer wieder zu kurzzeitigen Verbindungsunterbrechungen kommen kann, können Sie damit unnötige Warnungen umgehen.

Nachdem Sie die Behandlung der Piggyback-Daten im Allgemeinen festgelegt haben, können Sie unter Exceptions for piggybacked hosts mit den beschriebenen Optionen gezielt für einzelne Hosts eine gesonderte Behandlung (nach dem gleichen Schema) definieren.

In den Conditions müssen Sie zum Abschluss auf jeden Fall in der Option Explicit hosts den Namen des Quell-Hosts angeben.

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 Piggyback-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 Quell-Host und die Piggyback-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.

5. Dateien und Verzeichnisse

5.1. Pfade auf dem Checkmk-Server

Pfad Bedeutung

~/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/

Metadaten 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