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.

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 Monitoringdaten zu Host B quasi huckepack beim Abfragen von Host A mitübertragen werden.

Heute kommt Piggyback bei vielen weiteren Monitoringplugins zum Einsatz, z. B. bei der Überwachung von AWS, Azure, Kubernetes oder Docker. Auch ist es sehr einfach, den Piggyback-Mechanismus selbst zu verwenden, falls Sie eigene Checkplugins realisieren möchten, bei denen Sie Daten, die aus einer Quelle stammen, beliebigen Hosts zuordnen möchten.

2. Prinzip von Piggyback

Das Grundprinzip von Piggyback funktioniert wie in folgendem Schema dargestellt. Ein Host A kennt nicht nur Monitoringdaten zu sich selbst, sondern auch zu anderen Hosts – oder allgemeiner anderen Objekten. So kennt z. B. ein ESX-Host den Zustand und viele aktuelle Metriken zu jeder seiner VMs. Dieser Host A wird in diesem Zusammenhang manchmal auch als Quellhost (Source host) bezeichnet.

Wenn Checkmk jetzt von A in seinem minütlichen Rhytmus die Monitoringdaten 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 Piggybackdaten 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 Monitoringdaten 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, dass normales Monitoring und Piggyback kombiniert wird. Nehmen wir wieder das Beispiel von VMware: 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 wird sowohl der Agent abgefragt, als auch die Piggybackdaten von Host A verwendet und beide einfach zusammengefasst:

3. Piggyback in der Praxis

3.1. Einrichten von Piggyback

Die gute Nachricht ist erstmal: Der Piggyback-Mechanismus funktioniert völlig automatisch:

  • Wenn beim Abfragen von A Piggybackdaten für andere Hosts entdeckt werden, werden diese automatisch für die spätere Auswertung gespeichert.
  • Wenn beim Abfragen von B Piggybackdaten von einem anderen Host vorhanden sind, werden diese automatisch verwendet.

Allerdings ist – wie immer in Checkmk – alles konfigurierbar. Und zwar können sie bei den Eigenschaften eines Hosts (quasi Host B) im Kasten {{Data Sources}} einstellen, wie dieser auf vorhandene oder fehlende Piggybackdaten reagieren soll:

Der Default lautet Use piggyback data from other hosts if present. Falls vorhanden werden also Piggybackdaten verwendet, und wenn keine da sind, verwendet der Host eben nur seine „eigenen“ Monitoringdaten

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

Und bei Never use piggyback data werden eventuell vorhandene Piggybackdaten einfach ignoriert – eine Einstellung, die Sie nur in Ausnahmefällen brauchen werden.

3.2. Hosts müssen vorhanden sein

Damit ein Host Piggybackdaten 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 dynamsichen Konfiguration auch automatisieren und Hosts, für die Piggbackdaten vorhanden sind, automatisch anlegen lassen.

3.3. Hostnamen und ihre Zuordnung

In den obigen Schemata war es irgendwie logisch, dass die Daten von Objekt B im Monitoring dem Host B zugeordnet wurden. Aber heißt eigentlich B genau?

Beim Piggyback-Mechanismus geht die Zurordnung immer über einen Namen. Der (Spezial-) Agent schreibt zu jedem Satz von Piggybackdaten einen Objektnamen. Im Falle 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 – und zwar auch was Groß-/Kleinschreibung betrifft.

Was aber, wenn die Namen der Objekten in den Piggybackdaten 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 gehen Sie in zwei Schritten vor:

  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 Piggybackdaten in Kleinbuchstaben umgewandelt. Danach werden noch die beiden Hosts mv0815 bzw. vm0816 auf 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 ersten Feld, welches Regular expression heißt, 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 über die regulären Ausdrücke.
  4. Geben Sie bei Replacement ein Schema für den gewünschten Zielhostnamen an, wobei Sie die Werte, welche mit den Subgruppen „eingefangen“ wurden mit \1, \2 usw. einsetzen 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 Piggydaten

Wie oben beschrieben werden die Piggydaten zu anderen Hosts im Agentenoutput des „Quellhosts“ mittransportiert. Die Ausgabe des Checkmk-Agenten ist ein einfaches textbasiertes Format, das in dem Artikel über die Agenten etwas gezeigt wird.

Neu ist jetzt, dass im Output eine Zeile erlaubt ist, die mit <<<< beginnt und mit >>>> endet. Dazwischen steht ein Hostname. Alle weiteren Monitoringdaten 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 diese in Dateien unterhalb von tmp/check_mk/piggyback ab. Darunter befindet sich für jeden Zielhost (z. B. für jede VM) ein Unterverzeichnis – also wenn wir bei unserem Beispiel bleiben 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 Piggybackdaten von mehreren Hosts bekommen, somit wäre eine einzelne Datei nicht ausreichend.

Tipp: Wenn Sie neugierig sind, wie die Piggydaten 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 Piggydaten

Falls Sie die dynamische Konfiguration von Hosts nicht verwenden können oder möchten, dann kann es Ihnen passieren, dass Piggydaten für einen Host vorhanden sind, den Sie in Checkmk garnicht angelegt haben. Das kann Absicht sein, vielleicht aber auch ein Fehler – z. B. weil ein Name nicht genau übereinstimmt.

In den „Treasures“ finden Sie in Skript mit dem Namen find_piggy_orphans, welches Ihr Checkmk nach Piggydaten 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

Bitte 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 per lokalem Dateiaustausch über das Verzeichnis tmp/check_mk läuft.

Zukünftige Versionen von Checkmk werden eventuell einen Mechanismus anbieten, der optional den Austauch von Piggybackdaten ü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 Piggybackdaten
tmp/check_mk/piggyback/B/ Verzeichnis von Piggybackdaten für Host B
tmp/check_mk/piggyback/B/A Datei mit Piggybackdaten von Host A für Host B
tmp/check_mk/piggyback_sources/ Metainformationen zu den Hosts, welche Piggybackdaten erzeugen
tmp/check_mk/cache/A Agentenausgabe von Host A – inklusive eventuell vorhanderen Piggybackdaten in Rohform