Checkmk
to checkmk.com

1. Vorwort

CEE Für die Einrichtung der Überwachung von Kubernetes und diversen Geschmacksrichtungen davon gibt es bereits einen eigenen Artikel. Da OpenShift im Allgemeinen und die Einrichtung im Speziellen allerdings etwas anders funktionieren, haben wir uns für die Beschreibung der Einrichtung der Überwachung von OpenShift beziehungsweise der darin betriebenen Kubernetes-Cluster für einen eigenen Artikel entschieden. Im weiteren Verlauf dieses Artikels nennen wir eben diese Cluster - aus Gründen der Lesbarkeit und der Einfachheit halber - OpenShift-Cluster. Das Monitoring von OpenShift-Clustern ist nur mit einer der kommerziellen Editionen von Checkmk möglich.

2. Einleitung

Checkmk unterstützt Sie bei der Überwachung Ihrer OpenShift-Cluster. Ab Version 2.3.0 können Sie mit jeder unserer kommerziellen Editionen die folgenden Objekte überwachen:

  • Cluster

  • Deployments

  • Nodes

  • Pods

  • DaemonSets

  • StatefulSets

  • CronJobs

Eine vollständige Auflistung aller verfügbaren Check-Plugins für die Überwachung von Kubernetes finden Sie in unserem Katalog der Check-Plugins.

2.1. Aufbau der Monitoring-Umgebung

Da es in OpenShift-Cluster sehr schnell auch zu größeren Veränderungen kommen kann, was die Anzahl und Verortung der einzelnen Komponenten angeht, empfehlen wir für das Monitoring Ihrer OpenShift-Umgebung eine eigene Checkmk-Instanz zu erstellen. Diese können Sie dann wie üblich über das verteilte Monitoring an Ihre Zentralinstanz anbinden.

2.2. Ablauf des OpenShift-Monitorings in Checkmk

Checkmk überwacht Ihre OpenShift-Cluster auf zwei Wegen:

  • Grundlegende Informationen holt sich Checkmk direkt über die Kubernetes-API bei Ihrem Cluster ab. Hierüber lassen sich bereits die Zustände von Nodes und Containern abrufen. Auch die meisten Metadaten über Ihre Pods und Deployment werden auf diesem Wege gewonnen. Für ein umfängliches Monitoring fehlt bis zum diesem Punkt allerdings noch etwas. Die Fragen, wie viel Last beispielsweise ein bestimmtes Deployment auf der CPU erzeugt, oder wie viel Arbeitsspeicher ein DaemonSet gerade bindet, lassen sich so nicht beantworten.

  • Da in OpenShift-Cluster standardmäßig bereits Prometheus installiert ist, kann Checkmk genau diese Prometheus-Instanz innerhalb Ihrer OpenShift-Umgebung abfragen und die so gewonnenen Daten für Sie in gewohnter Checkmk-Manier aufbereiten. Für ein vollumfängliches Monitoring Ihrer OpenShift-Umgebung empfehlen wir unbedingt diese Anbindung einzurichten. Auch ist die Verwendung der Kubernetes-Dashboards nur dann sinnvoll, wenn die entsprechenden Daten zur Auslastung vorliegen.

3. Voraussetzungen im Cluster schaffen

Um Ihre OpenShift-Umgebung in Checkmk überwachen zu können, schaffen Sie zuerst die Voraussetzungen in Ihrem Cluster.

3.1. Namespace und Service-Account anlegen

Zuerst müssen Sie in Ihrem OpenShift-Cluster einen Namespace und einen Service-Account für Checkmk einrichten. Am schnellsten lässt sich das über die OpenShift CLI (kurz: oc) bewerkstelligen.

Im folgenden Beispiel nennen wir diesen Namespace checkmk-monitoring. Sollten Sie einen anderen Namen wählen wollen oder müssen, dann müssen Sie diese Änderung auch in bei der Erzeugung des Service-Account vornehmen.

user@host:~$ oc create namespace checkmk-monitoring
namespace/checkmk-monitoring created

Den Service-Account mit der zugehörigen Rolle und der sogenannten RoleBinding, können Sie durch die Angabe einer von uns vorgefertigten und auf GitHub veröffentlichten YAML-Datei vornehmen. Prüfen Sie deren Inhalt und führen Sie anschließend den folgenden Befehl aus:

user@host:~$ oc apply -f https://raw.githubusercontent.com/Checkmk/checkmk_kube_agent/checkmk_docs/deploy/kubernetes/checkmk-serviceaccount.yaml
serviceaccount/checkmk created
clusterrole.rbac.authorization.k8s.io/checkmk-metrics-reader created
clusterrolebinding.rbac.authorization.k8s.io/checkmk-metrics-reader-binding created

Alternativ können Sie diese YAML-Datei auch zuerst herunterladen, nach Ihren Bedürfnissen anpassen und anschließend oc apply -f auf Ihre lokale Kopie anwenden.

3.2. API-Endpunkte, Token und Zertifikat besorgen

Mit dem Kommandozeilen-Tool oc können Sie nun auch alle Informationen aus Ihrem Cluster auslesen, welche Sie in der Regel zur Einrichtung des Spezialagenten angeben müssen. Wenn Sie den den Namen des Service-Account oder den Namespace verändert haben, müssen diese Angaben in der folgenden Befehlen entsprechend anpassen.

Kubernetes-API-Endpunkt auslesen

Den Endpunkt der Kubernetes-API zeigt oc mit dem folgenden Befehl an:

user@host:~$ oc cluster-info
Kubernetes control plane is running at https://api.myopenshift.example.com:6443

Diese Adresse inklusive des angegebenen Ports gehört in der Kubernetes-Regel später in das Feld API server connection > Endpoint.

Prometheus-API-Endpunkt auslesen

Die Adresse vom API-Endpunkt der Prometheus-Instanz in Ihrem Cluster herauszufinden, kann womöglich über die GUI von OpenShift einfacher sein. In der Rolle des Administrators finden Sie über Networking > Routes eine mehr oder weniger lange Liste. Hier sollte sich auch eine Route finden, die vermutlich das Wort Prometheus in Ihrem Namen trägt. Auch das hängt schlicht von der Konfiguration Ihres OpenShift-Cluster ab. Unter Location finden Sie dann eben die URL, die Sie später für das Feld Prometheus API endpoint benötigen.

Mit dem folgenden Befehl können Sie die FQDN womöglich auch auf der Kommandozeile ermitteln.

user@host:~$ oc get routes --all-namespaces | grep prometheus
openshift-monitoring    prometheus-k8s   prometheus-k8s-openshift-monitoring.apps.myopenshift.example.com   prometheus-k8s  web  reencrypt/Redirect   None

Dem String prometheus-k8s-openshift-monitoring.apps.myopenshift.example.com müssen Sie dann später in der Kubernetes-Regel im Feld Prometheus API endpoint nur noch das Protokoll voranstellen.

Token auslesen

Um das Token auszulesen, welches Sie später in Checkmk in der Regel für den Spezialagenten angeben müssen, können Sie den folgenden Befehl verwenden:

user@host:~$ oc get secret $(oc describe sa checkmk -n checkmk-monitoring | grep 'Tokens' | awk '{ print $2 }') -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode
eyJhbGciOiJSUzI1NiIsImtpZCI6IkxFbDdZb25t...

Lassen Sie die Shell mit diesen Informationen geöffnet oder kopieren Sie das Token an einen Ort, auf den Sie während der folgenden Einrichtung in Checkmk zugreifen können.

Zertifikat auslesen

Um das Zertifikat auszulesen, welches Sie später in Checkmk in den Global settings angeben müssen, können Sie den folgenden Befehl verwenden

user@host:~$ oc get secret $(oc describe sa checkmk -n checkmk-monitoring | grep 'Tokens' | awk '{ print $2 }') -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decode

Lassen Sie die Shell mit diesen Informationen geöffnet oder kopieren Sie das Zertifikat – inklusive der Zeilen BEGIN CERTIFICATE und END CERTIFICATE – an einen Ort, auf den Sie während der folgenden Einrichtung in Checkmk zugreifen können.

Sollte die Ausgabe leer sein, gilt der gleiche Hinweis, wie im Abschnitt Token auslesen.

4. Monitoring in Checkmk einrichten

Als nächstes geht es in der GUI von Checkmk an die Einrichtung des Spezialagenten und einer Regel für die automatische Erzeugung von Hosts für Ihre Kubernetes-Objekte. Für die Einrichtung des Spezialagenten müssen aber zuerst noch einige Voraussetzungen erfüllt werden:

4.1. Passwort (Token) in Checkmk hinterlegen

Das Passwort (Token) des Service-Accounts hinterlegen Sie am besten im Passwortspeicher von Checkmk. Das ist die sicherste Variante, da Sie Hinterlegung und Benutzung des Passworts organisatorisch trennen können. Alternativ geben Sie es beim Anlegen der Regel (siehe weiter unten) direkt im Klartext ein.

Um das Passwort in den Checkmk-Passwortspeicher einzufügen, navigieren Sie zu Setup > General > Passwords > Add password. Wir verwenden für unser Beispiel als ID und Titel My OpenShift Token:

kubernetes password

4.2. CA-Zertifikat des Service-Accounts in Checkmk importieren

Damit Checkmk der Zertifikatskette des Service-Accounts vertrauen kann, müssen Sie diese in Checkmk hinterlegen. Kopieren Sie hier alles – inklusive der Zeilen, die BEGIN CERTIFICATE und END CERTIFICATE enthalten – und fügen Sie das Zertifikat im Setup-Menü unter Setup > General > Global settings > Site management > Trusted certificate authorities for SSL hinzu:

kubernetes ca

4.3. Piggyback Quell-Host anlegen

Erzeugen Sie in Checkmk auf gewohnte Weise einen neuen Host und nennen Sie diesen beispielsweise myopenshiftclusterhost. Wie Überschrift und Host-Name schon nahelegen, dient dieser Host dazu, die Piggyback-Daten zu sammeln und außerdem alle Services und Metriken auf Cluster-Ebene abzubilden. Da dieser Host ausschließlich über den Spezialagenten Daten erhält, setzen Sie in den Eigenschaften des Hosts die Option IP address family unbedingt auf No IP. Bestätigen Sie das Ganze mit einem Druck auf den Knopf Save & view folder.

Beispielhafte Einrichtung eines Cluster-Hosts mit der wichtigen Einstellung 'No IP'.

4.4. Dynamische Host-Konfiguration einrichten

Um eine Trennung zwischen den Objekten verschiedener Kubernetes-Cluster zu gewährleisten, ist es meist praktisch, über Setup > Hosts > Add folder pro Cluster einen Ordner anzulegen, in welchem die dynamische Host-Konfiguration automatisch alle Hosts eines Clusters anlegen kann. Einen solchen Ordner zu erzeugen und zu nutzen ist aber optional.

Als nächstes richten Sie einen Konnektor für die anfallenden Piggyback-Daten ein. Navigieren Sie hierfür zu Setup > Hosts > Dynamic host management > Add connection. Tragen Sie zuerst einen Titel ein und klicken Sie anschließend unter Connection Properties auf show more.

Als nächstes ist es sehr wichtig unter Restrict source hosts den zuvor angelegten Piggyback Quell-Host einzutragen.

Klicken Sie anschließend unter Piggyback creation options auf Add new element und wählen Sie unter Create hosts in den zuvor angelegten Ordner aus.

Die voreingestellten Attribute unter Host attributes to set können Sie so belassen. Sie sorgen dafür, dass sich Checkmk bei den automatisch angelegten Hosts ausschließlich an die Piggyback-Daten hält und nicht versucht. diese beispielsweise zu pingen oder per SNMP zu erreichen.

In einer OpenShift-Umgebung, in der überwachbare und überwachte Objekte kontinuierlich kommen und gehen, empfiehlt es sich meist, auch die Option Automatically delete hosts without piggyback data zu aktivieren. Was genau diese Option bewirkt und unter welchen Umständen Hosts dann tatsächlich gelöscht werden, erklären wir im Kapitel Automatisches Löschen von Hosts im Artikel zur dynamischen Host-Konfiguration.

Aktivieren Sie abschließend noch die Option Discover services during creation.

Der Abschnitt Connection Properties dieses neuen Konnektors könnte im Anschluss wie folgt aussehen:

Beispielhafte Einstellungen einer dynamischen Host-Konfiguration.

4.5. Periodische Service-Erkennung anpassen

Standardmäßig führt Checkmk alle zwei Stunden eine Service-Erkennung durch und zeigt das Ergebnis dieser Erkennung im Service Check_MK Discovery an. Sie finden diese Einstellung im Regelsatz Periodic service discovery. Im Kontext von OpenShift empfehlen wir eine Regel für alle Hosts mit dem Label cmk/kubernetes:yes zu erstellen. Dieses Label erhält nämlich jeder Host, der Kubernetes-Objekte repräsentiert, automatisch von Checkmk. Sie sollten hier ein kleineres Intervall als zwei Stunden für die Service-Erkennung wählen und auch die Option Automatically update service configuration aktivieren. Die Einstellungen im folgenden Screenshot sind nur exemplarisch. Was für Ihre Cluster sinnvoll ist, müssen Sie von Fall zu Fall entscheiden.

Exemplarische Einrichtung der periodischen Service-Erkennung für Kubernetes-Objekte.

Um diese Regel auf alle Hosts Ihrer Cluster zu beschränken, genügt es bei den Conditions unter Host labels cmk/kubernetes:yes einzutragen. Wollen Sie jedoch für verschiedene Cluster auch verschiedene Regeln erstellen, verwenden Sie hier einfach das jeweilige Cluster-spezifische Label. Diese Labels haben immer die Form cmk/kubernetes/cluster:mycluster.

Exemplarische Einschränkung auf Hosts mit einem Cluster-spezifischen Label.

4.6. Spezialagent einrichten

Nachdem nun alle Voraussetzungen im Cluster und in Checkmk geschaffen sind, können Sie sich der Konfiguration des Spezialagenten widmen. Diese finden Sie über Setup > Agents > VM, cloud, container > Kubernetes. Erstellen Sie mit Add rule eine neue Regel.

Zuallererst müssen Sie einen Namen für den zu überwachenden Cluster vergeben. Diesen Namen können Sie frei wählen. Er dient dazu, alle Objekte, die aus genau diesem Cluster stammen, mit einem eindeutigen Namen zu versehen. Wenn Sie hier beispielsweise mycluster eintragen, werden die Namen der Hosts aller Pods aus diesem Cluster später mit pod_mycluster beginnen. Der nächste Teil des Host-Namens wird dann immer der Namespace sein, in dem dieses Kubernetes-Objekt existiert. Der Host-Name eines Pods könnte dann beispielsweise pod_mycluster_kube-system_svclb-traefik-8bgw7 lauten.

Wählen Sie unter Token nun den zuvor angelegten Eintrag aus dem Passwortspeicher von Checkmk aus.

Beispielhafter Cluster-Name und Auswahl des Tokens.

Unter API server connection > Endpoint verlangt Checkmk nun die Eingabe der URL über welche Ihr Kubernetes API-Server erreichbar ist. Die Angabe des Ports ist nur notwendig, wenn der Dienst nicht über einen virtuellen Host bereitgestellt wird. Tragen Sie hier die Adresse ein, welche Sie im Abschnitt Kubernetes-API-Endpunkt auslesen ermittelt haben.

Wenn Sie diese Anleitung bisher Schritt für Schritt befolgt haben und das CA-Zertifikat Ihres Clusters - wie oben beschrieben - in Checkmk hinterlegt haben, wählen Sie unter SSL certificate verification den Eintrag Verify the certificate aus.

Exemplarische Angabe der API-Server Verbindung.

Aktivieren Sie die Option Enrich with usage data, wählen Sie im folgenden Menü Use data from OpenShift und tragen Sie den Prometheus API endpoint ein, den Sie im Abschnitt Prometheus-API-Endpunkt auslesen ermittelt haben.

Exemplarische Angabe der Cluster Collector Verbindung.

Die Liste unter Collect information about…​ erlaubt Ihnen noch die Auswahl, welche Objekte innerhalb Ihres Cluster überwacht werden sollen. Unsere Vorauswahl deckt hier die relevantesten Objekte ab. Sollten Sie sich dazu entscheiden auch die Pods of CronJobs zu überwachen, so beachten Sie die Inline-Hilfe zu diesem Punkt.

Exemplarische Auswahl überwachbarer Kubernetes-Objekte.

Mit den nächsten beiden Auswahlmöglichkeiten können Sie die zu überwachenden Objekte weiter eingrenzen. Falls Sie sich nur für die Objekte aus bestimmten Namespaces interessieren, stellen Sie dies entsprechend unter Monitor namespaces ein. Hier können Sie entweder einzelne Namespaces eintragen, die überwacht werden sollen, oder aber einzelne Namespaces explizit vom Monitoring ausschließen.

Mit der Option Cluster resource aggregation können Sie Nodes benennen, welche keine Ressourcen für die Arbeitslast Ihres Clusters zur Verfügung stellen. Diese Nodes sollten aus der Berechnung der zur Verfügung stehenden Ressourcen ausgenommen werden. Ansonsten besteht die Gefahr, dass Kapazitätsengpässe nicht erkannt werden. Standardmäßig nehmen wir daher bereits die Nodes control-plane und infra aus der Berechnung heraus.

Beispielhafte Konfiguration für Namensräume und Ressourcen-Aggregation

Als letzte Option können Sie noch sogenannte Annotations aus Kubernetes importieren. In Checkmk werden diese Annotations zu Host-Labels und können somit als Bedingungen in Regeln weiterverwendet werden. Welche Annotations importiert werden sollen, können Sie über reguläre Ausdrücke festlegen. Konsultieren Sie an dieser Stelle erneut die ausführliche Inline-Hilfe.

Hinweis: Die Option Import all valid annotations bieten wir an dieser Stelle nur der Vollständigkeit halber an. Wir raten davon ab, einfach unbesehen alle Annotations zu importieren, weil hierdurch mitunter ein sehr großer Berg nutzloser Labels in Checkmk erzeugt wird.

Wichtig: Unter Conditions > Explicit hosts müssen Sie nun den zuvor angelegten Host eintragen:

Regeln für Spezialagenten müssen, wie hier zu sehen, immer auf explizite Hosts festgelegt werden.

Speichern Sie anschließend die Regel und führen Sie eine Service-Erkennung für diesen Host durch. Sie werden hier gleich die ersten Services auf Cluster-Ebene sehen:

Exemplarische Ansicht der ersten Service-Erkennung nach Abschluss der Konfiguration.

Aktivieren Sie im Anschluss alle vorgenommenen Änderungen und überlassen Sie ab jetzt der dynamischen Host-Konfiguration die Arbeit. Diese wird schon nach kurzer Zeit alle Hosts für Ihre Kubernetes-Objekte erzeugen.

5. Labels für Kubernetes-Objekte

Checkmk erzeugt Labels für Objekte wie Cluster, Deployments oder Namespaces während der Service-Erkennung automatisch. Alle Labels zu diesen Objekten, die Checkmk automatisch erzeugt, beginnen mit cmk/kubernetes/. Ein Pod erhält beispielsweise immer ein Label der Node (cmk/kubernetes/node:mynode), ein Label, welches eben zeigt, dass es sich bei diesem Objekt um einen Pod handelt (cmk/kubernetes/object:pod) und ein Label für den Namespace (cmk/kubernetes/namespace:mynamespace). So lassen sich in der Folge sehr einfach Filter und Regeln für alle Objekte gleichen Typs bzw. im gleichen Namespace erstellen.

6. Dashboards und Ansichten

6.1. Kubernetes-Dashboards

CEE Die kommerziellen Editionen von Checkmk werden mit sechs eingebauten Dashboards für Kubernetes ausgeliefert. Um diese Dashboards sinnvoll verwenden zu können, ist es notwendig, dass unser Cluster Collector installiert und konfiguriert ist. Im einzelnen heißen diese Dashboards:

  • Kubernetes (Overview)

  • Kubernetes Cluster

  • Kubernetes DaemonSet

  • Kubernetes Deployment

  • Kubernetes Namespace

  • Kubernetes StatefulSet

Der Einstieg geschieht dabei immer über das Dashboard Kubernetes, welches Sie über Monitor > Applications > Kubernetes erreichen:

Exemplarische Ansicht des Übersichts-Dashboards.

Im Dashboard Kubernetes werden auf der linken Seite alle Ihre überwachten Cluster aufgelistet. Diese Auflistung der Cluster ist auch Ihr Einstieg, um sich tiefer in die Dashboards zu bohren. Mit einem Klick auf den Namen eines Clusters gelangen Sie in das Dashboard Kubernetes Cluster des angewählten Clusters. Im Dashboard Kubernetes Cluster führt ein Klick auf den jeweiligen Namen dann in die übrigen kontextabhängigen Dashboards:

Ausschnitt des Cluster-Dashboards mit Wegen in die weiteren Dashboards.

6.2. Hardware-/Software-Inventur

Die Überwachung von OpenShift mit Checkmk unterstützt auch die HW-/SW-Inventur. Wenn Sie beispielsweise in dem obigen Cluster-Dashboard auf den großen Namen des Clusters (hier: mycluster) klicken, gelangen Sie zur Inventur des Clusters.

Auf dem gleichen Weg, also über die Boxen mit den großen Namen der Objekte, gelangen Sie auch in den anderen Dashboards zur Inventur des jeweiligen Objekts. Im folgenden Beispiel sehen Sie die HW-/SW-Inventur eines Pods:

kubernetes monitoring hw sw inventory

7. Prüfung der Installation

In der GUI von Checkmk können Sie die erfolgreiche Installation und Konfiguration prüfen.

Die wichtigsten Services sind hier sicherlich Kubernetes API und Cluster collector. Diese müssen auf dem von Ihnen erstellten Cluster-Host vorhanden sein und sollten auch bestimmte Informationen anzeigen.

Wichtigste Services zur Prüfung der korrekten Installation

Der Service Kubernetes API sollte im Normalfall unter Summary Live, Ready vermelden und wenn der Cluster Collector eingerichtet ist, wird dieser im Idealfall Successfully queried usage data from Prometheus ausgeben.

Im Dashboard Kubernetes können Sie bereits sehr früh erkennen, ob der Cluster Collector in einem Cluster läuft und Daten sammelt. Bei korrekter Einrichtung sollte das Dashboard Kubernetes in etwa so aussehen:

Kubernetes-Dashbaord mit Daten für CPU resources und Memory resources

Wenn Sie hier nun auf den Namen des Clusters klicken, landen Sie im Dashboard Kubernetes Cluster des jeweiligen Clusters. Hier sollten die drei Boxen Primary datasource, Cluster collector und API health grün sein und OK anzeigen.

Funktionierendes Cluster-Monitoring.

8. Monitoring-Komponenten aus OpenShift entfernen

8.1. Service-Account löschen

Wenn Sie zur Erzeugung des Service-Accounts unsere vorgegebene YAML-Datei verwendet haben, können Sie diesen wie folgt auch wieder entfernen:

user@host:~$ oc delete -f https://raw.githubusercontent.com/Checkmk/checkmk_kube_agent/checkmk_docs/deploy/kubernetes/checkmk-serviceaccount.yaml
serviceaccount "checkmk" deleted
clusterrole.rbac.authorization.k8s.io "checkmk-metrics-reader" deleted
clusterrolebinding.rbac.authorization.k8s.io "checkmk-metrics-reader-binding" deleted

8.2. Namespace entfernen, wenn gewünscht

user@host:~$ oc delete namespace checkmk-monitoring
namespace "checkmk-monitoring" deleted
Auf dieser Seite