Wir nutzen Cookies, um Ihnen eine optimale Nutzung dieser Webseite zu ermöglichen. Mehr Informationen finden Sie im Datenschutzhinweis. Wir nehmen an, dass Sie damit einverstanden sind, falls Sie diese Webseite weiter besuchen.

Ihre Cookie-Einstellungen
Ihre Einstellungen wurden aktualisiert.
Damit die Änderungen wirksam werden, löschen Sie bitte Ihre Browser-Cookies und den Cache und laden dann die Seite neu.

Die Checkmk-Konferenz #6 steht an! Regulärer Verkauf endet in . Tickets hier!

Der Piggyback-Mechanismus

Dieser Artikel ist noch nicht fertig und nur ein Entwurf!

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 Operating, 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 AWS, Azure, Kubernetes oder Docker. Es ist 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 Quellhost (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:

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:

3. Piggyback in der Praxis

3.1. Einrichten von Piggyback

Die gute Nachricht ist, dass der Piggyback-Mechanismus 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 {{Data Sources}} einstellen, wie dieser auf vorhandene oder fehlende Piggyback-Daten reagieren soll:

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 Checkmk-Service 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.

Ab Version 1.6.0 der Enterprise Editions können Sie das mithilfe der dynamischen Konfiguration automatisieren und Hosts, für die Piggyback-Daten vorhanden sind, automatisch anlegen lassen.

3.3. Hostnamen 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 Objekten in den Piggyback-Daten für das Monitoring ungeeignet oder ungewünscht sind? Dafür gibt es den speziellen Regelsatz Access to Agents ➳ General Settings ➳ Hostname translation for piggybacked hosts.

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

  1. Legen Sie eine Regel in dieser Regelkette an und stellen Sie die Bedingung so ein, dass Sie auf dem Quellhost greift – also quasi auf Host A.
  2. Legen Sie im Wert der Regel eine passende Namenszuordnung an.

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

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 Zielhostnamen 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 im Agenten-Output des „Quellhosts“ 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 Hostname. 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 Quellhost.

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 Zielhost (z. B. für jede VM) ein Unterverzeichnis – in unserem Beispiel also ein Ordner mit dem Namen B. Darin ist dann pro Quellhost 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 Monitoringinstanz im Verzeichnis tmp/check_mk/cache. Eine Übersicht über alle beteiligten Dateien und Verzeichnisse finden Sie weiter unten.

4.2. Verwaiste Piggyback-Daten

Falls Sie die dynamische Konfiguration von Hosts nicht verwenden können oder möchten, 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 Piggyhost 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 in verteilten Umgebungen

Beachten Sie, dass es in verteilten Umgebungen aktuell so ist, dass der Quellhost und die piggybacked Hosts in der gleichen Instanz überwacht werden müssen. Dies liegt einfach 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 Austauch von Piggyback-Daten über Instanzgrenzen hinweg ermöglicht.

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/ Metainformationen zu den Hosts, die Piggyback-Daten erzeugen
tmp/check_mk/cache/A Agentenausgabe von Host A – inklusive eventuell vorhandenen Piggyback-Daten in Rohform