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:
Proxmox VE
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 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:
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 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:
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:
Legen Sie eine Regel an und stellen Sie die Bedingung so ein, dass Sie auf dem Quell-Host greift — also quasi auf Host A.
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:
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:
Aktivieren Sie die Option Multiple regular expressions.
Fügen Sie mit dem Knopf Add expression einen Übersetzungseintrag an. Jetzt erscheinen zwei Felder.
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.
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,\2usw. 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-MGMDurch 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
barVM02Diese 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
| Pfad | Bedeutung |
|---|---|
|
Ablageort für Piggyback-Daten |
|
Verzeichnis von Piggyback-Daten für Host B |
|
Datei mit Piggyback-Daten von Host A für Host B |
|
Metainformationen zu den Hosts, die Piggyback-Daten erzeugen |
|
Agentenausgabe von Host A — inklusive eventuell vorhandenen Piggyback-Daten in Rohform |