OpenShift überwachen

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.

Checkmk überwacht Ihre OpenShift-Cluster auf zwei Wegen:

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.

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:

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.

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.

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:

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:

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.

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:

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.

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.

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.

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.

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.

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.

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.

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:

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:

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.

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:

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

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:

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:

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