1. Einleitung
1.1. Hintergrund und Motivation
Vielleicht fragen Sie sich jetzt, warum man überhaupt Prometheus in Checkmk integrieren sollte. Deswegen an dieser Stelle ein wichtiger Hinweis: Unsere Integration von Prometheus richtet sich an alle unsere Nutzer, die Prometheus bereits im Einsatz haben. Damit Sie nicht dauerhaft zwei Monitoring-Systeme prüfen müssen, schließen wir durch die Integration von Prometheus in Checkmk die hier entstandene Lücke.
Damit ermöglichen wir eine Korrelation der Daten aus den beiden Systemen, beschleunigen eine etwaige Fehlerursachenanalyse und erleichtern gleichzeitig die Kommunikation zwischen Checkmk- und Prometheus-Nutzern.
Endlich wieder Kontext
Mit der angenehmste Nebeneffekt dieser Integration ist es wohl, dass Ihre Metriken aus Prometheus in Checkmk automatisch einen sinnvollen Kontext erhalten. Während Prometheus Ihnen beispielsweise die Menge des belegten Hauptspeichers korrekt anzeigt, müssen Sie in Checkmk keine weiteren manuellen Schritte gehen, um zu erfahren, wie groß dabei der Anteil am insgesamt verfügbaren Speicher ist. So banal das Beispiel sein mag, zeigt es an welchen Stellen Checkmk das Monitoring bereits im ganz Kleinen erleichtert.
1.2. Exporter oder PromQL
Die Integration der wichtigsten Exporter für Prometheus wird über einen Spezialagenten zur Verfügung gestellt. Für Prometheus stehen Ihnen die folgenden Exporter zur Verfügung:
Sollte unter den von uns unterstützen Exportern noch nicht das richtige für Sie dabei sein, haben erfahrene Nutzer von Prometheus auch die Möglichkeit direkt über Checkmk selbst-definierte Abfragen an Prometheus zu richten. Dies geschieht in der Prometheus-eigenen Abfragesprache PromQL.
2. Einrichten der Integration
2.1. Host anlegen
Da es das Konzept der Hosts in Prometheus schlicht nicht gibt, schaffen Sie zuerst einen Ort, der die gewünschten Metriken sammelt. Dieser Host bildet die zentrale Anlaufstelle für den Spezialagenten und verteilt die angelieferten Daten dann später an die richtigen Hosts in Checkmk. Erzeugen Sie dazu einen neuen Host über das gleichnamige WATO-Modul.
Sollte der angegebene Hostname keiner FQDN entsprechen, geben Sie hier noch die IP-Adresse an unter der der Prometheus-Server erreichbar ist.
Nehmen Sie alle weiteren Einstellungen Ihrer Umgebung entsprechend vor und bestätigen Sie Ihre Auswahl über Save & go to folder.
2.2. Regel für Datasource Prometheus anlegen
Bevor Checkmk Ihre Metriken aus Prometheus finden kann, müssen Sie zuerst noch den Spezialagenten über den Regelsatz Prometheus einrichten. Diesen finden Sie in WATO über Setup > Agents > VM, Cloud, Container > Prometheus. Unabhängig davon welchen Exporter Sie verwenden wollen, gibt es verschiedene Möglichkeiten, die Verbindung zu dem Web Frontend Ihres Prometheus-Servers anzupassen. Bitte beachten Sie, dass es vor Version 2.0.0 lediglich die Bestimmung des Ports verfügbar war.
Prometheus connection option: Legen Sie hier fest, wie der Prometheus-Server kontaktiert werden soll. Besonders, wenn der Server nur per HTTPS erreichbar ist, ist sind die Optionen Custom URL oder Host name wichtig und sinnvoll, da das Zertifikat nur selten die IP-Adresse beinhaltet.
Prometheus web port: Der Port muss nur geändert werden, wenn er von dem Standard des Prometheus-Servers abweicht.
Basic authentication: Ist ein Login erforderlich, geben Sie diesen hier an.
Protocol: Nach der Installation wird das Web Frontend per HTTP zur Verfügung gestellt. Sofern Sie den Zugriff mit HTTPS abgesichert haben, stellen Sie hier das Protokoll entsprechend um.
Die Standardwerte sehen Sie in folgendem Screenshot:
Integration per Node Exporter
Wenn Sie nun beispielsweise die Hardware-Komponenten eines sogenannten Scrape Targets aus Prometheus integrieren möchten, nutzen Sie dafür den sogenannten Node Exporter. Wählen Sie nun Add new Scrape Target und danach in dem ersten Dropdown-Menü Node Exporter aus:
Sie haben immer die Option, Informationen abzuwählen, wenn Sie diese nicht abrufen wollen. Die erzeugten Services benutzen dann dieselben Check-Plugins, wie sie auch für andere Linux-Hosts verwendet werden. Dadurch sind sie in ihrem Verhalten identisch zu den bekannten und Sie können ohne große Umstellung Schwellwerte konfigurieren, oder mit den Graphen arbeiten.
Normalerweise wird der Agent versuchen, die Daten automatisch den Hosts in Checkmk zuzuordnen. So auch für den Host in Checkmk, der die Daten holt. Sollte in den Daten des Prometheus-Servers aber weder die IP-Adresse, der FQDN, noch localhost vorkommen, bestimmen Sie über die Option Explicitly map Node Exporter host, welcher Host aus den Daten des Prometheus-Servers dem Prometheus-Host in Checkmk zugeordnet wird.
Integration per cAdvisor
Der Exporter cAdvisor erlaubt die Überwachung von Docker-Umgebungen und liefert dabei Metriken zu Verwendungs- und Performancedaten zurück.
Über das Auswahlmenü Entity level used to create Checkmk piggyback hosts können Sie festlegen, ob und wie die Daten aus Prometheus schon aggregiert abgeholt werden sollen. Ihnen stehen dabei die folgenden drei Optionen zu Auswahl:
Both - Display the information for both, pod and container, levels
Container - Display the information on container level
Pod - Display the information for pod level
Wählen Sie hierbei entweder Both oder Container aus, legen Sie außerdem noch fest, unter welchem Namen Hosts für Ihre Container angelegt werden. Die folgenden drei Option stehen Ihnen für die Benamung zur Verfügung. Die Option Short ist hierbei der Standard:
Short - Use the first 12 characters of the docker container ID
Long - Use the full docker container ID
Name - Use the containers' name
Bitte beachten Sie, dass ihre Auswahl an dieser Stelle Auswirkungen auf das automatische Anlegen und Löschen von Hosts entsprechend Ihrer dynamischen Host-Konfiguration hat.
Um die Anzahl der überwachten Objekte einschränken zu können, haben Sie mit Monitor namespaces matching die Möglichkeit, eben diese einzuschränken. Alle Namespaces, die nicht von den regulären Ausdrücken erfasst werden, werden dann entsprechend ignoriert.
Integration per kube-state-metrics
Mit dem Exporter kube-state-metrics lassen sich Deployments, Nodes und Pods innerhalb eines Kubernetes-Clusters abfragen. Die Mechanik ist hier weitgehend die gleiche, wie auch für den Node Exporter oder den cAdvisor oben beschrieben: Sie wählen die Metriken aus, die Sie überwachen wollen. Einzig über das Feld Cluster name können Sie individuell bestimmen, wie der Host heißt, unter dem die Daten zu einem Cluster angezeigt werden sollen.
Integration per PromQL
Wie bereits erwähnt ist es mit Hilfe des Spezialagenten auch möglich Ihren Prometheus-Server über PromQL anzufragen. Geben Sie auch hier den Port an über den Prometheus erreichbar ist und wählen Sie Service creation using PromQL queries > Add new Service aus. Mit dem Feld Service name bestimmten Sie, wie der neue Service in Checkmk heißen soll.
Wählen Sie dann Add new PromQL query und legen Sie über das Feld Metric label fest, wie die zu importierende Metrik in Checkmk heißen soll. In das Feld PromQL query geben Sie nun Ihre Abfrage ein. Dabei ist es wichtig, dass diese Abfrage nur einen Rückgabewert haben darf.
In diesem Beispiel wird Prometheus nach der Anzahl der laufenden und blockierten Prozesse gefragt. In Checkmk werden diese dann in einem Service mit dem Namen Processes und den beiden Metriken Running und Blocked zusammengefasst.
Sie können diesen Metriken ab Version 2.0.0 auch Schwellwerte zuweisen. Aktivieren Sie dafür die Metric levels und wählen Sie danach zwischen Lower levels oder Upper levels. Beachten Sie, dass sie zwar immer Gleitkommazahlen angeben, diese sich aber natürlich auch auf Metriken beziehen, welche nur Ganzzahlen zurückgeben.
Regel dem Prometheus-Host zuweisen
Weisen Sie diese Regel explizit dem soeben angelegten Host zu und bestätigen Sie Ihre Angaben mit Save.
2.3. Service Discovery
Nachdem Sie den Spezialagenten nun konfiguriert haben, ist es Zeit, eine Service-Erkennung auf dem Prometheus-Host durchzuführen.
3. Dynamische Host-Konfiguration
3.1. Generelle Konfiguration
Die Überwachung von Kubernetes Clustern ist vermutlich eine der Aufgaben, die am häufigsten mit Prometheus bewerkstelligt wird. Um eine Integration der mitunter sehr kurzlebigen Container, die per Kubernetes orchestriert und mit Prometheus überwacht werden auch in Checkmk ohne großen Aufwand zu gewährleisten, bietet sich die Einrichtung einer dynamischen Host-Konfiguration an. Die Daten der einzelnen Container werden dabei als Piggyback-Daten an Checkmk weitergeleitet.
Legen Sie einfach über WATO > Hosts > Dynamic config > New connection eine neue Verbindung an, wählen als Sie als Connector type Piggyback data und legen Sie über Add new element die Bedingungen fest unter denen neue Hosts dynamisch erstellt werden sollen.
Beachten Sie bitte auch ob es für Ihre Umgebung notwendig ist, Hosts auch wieder dynamisch zu löschen, wenn keine Daten mehr über den Piggyback-Mechanismus bei Checkmk ankommen. Stellen Sie die Option Delete vanished hosts entsprechend ein.
3.2. Besonderheit im Zusammenspiel mit cAdvisor
Normalerweise bekommen Container eine neue ID, wenn sie neu gestartet werden. In Checkmk werden die Metriken des Hosts mit der alten ID nicht automatisch auf die neue ID übertragen. Das würde in den meisten Fällen auch gar keinen Sinn ergeben. Im Falle von Containern kann das aber durchaus nützlich sein, wie in dem Beispiel eben gesehen: Wenn ein Container nur neu gestartet wird, möchten Sie sehr wahrscheinlich auch die Historie nicht verlieren. Um das zu erreichen, legen Sie die Container nicht unter ihrer ID, sondern stattdessen unter ihrem Namen (Option Name - Use the containers' name in der Prometheus-Regel) an. Auf diese Weise können Sie nicht mehr vorhandene Container dennoch mit der Option Delete vanished hosts in der dynamischen Host-Konfiguration löschen, ohne befürchten zu müssen, dass die Historie damit auch verloren ist. Stattdessen wird diese — durch den identischen Namen des Containers — fortgeführt, auch wenn es sich um einen anderen Container handelt, der aber denselben Namen hat.