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.

Prometheus integrieren

Checkmk Manual
Letzte Aktualisierung: 18. Mai 2020

Suche im Handbuch

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

Mit dem Erscheinen des Feature Pack 2 können Sie Prometheus in Checkmk ab der Version 1.6.0p12 integrieren. Die Integration der wichtigsten Exporter für Prometheus wird dabei über einen Spezialagenten zur Verfügung gestellt.

Nach der Aktivierung des Erweitungspakets 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 & Finish.

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 Host & Service Parameters ➳ Datasource Programs ➳ Prometheus. Unabhängig davon welchen Exporter Sie verwenden wollen, geben Sie unter TCP Port number den Port an über den auch das Webfrontend Ihres Prometheus-Servers erreichbar ist.

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 im sich öffnenden Dropdown-Menü Node Exporter aus:

Desweiteren können Sie hier auswählen, welche Hardware bzw. welche Instanzen des Betriebssystems durch den Node Exporter abgefragt werden sollen. Die dadurch erzeugten Services benutzen dieselben Checkplugins, 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.

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 Hostkonfiguration hat.

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 weitgehen 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.

Wichtig: Zurzeit ist es noch nicht möglich den auf diese Weise importierten Metriken Schwellwerte zuzuweisen.

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 Serviceerkennung auf dem Prometheus-Host durchzuführen.

3. Dynamische Hostkonfiguration

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 Hostkonfiguration 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 Hostkonfiguration 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.