Seite wählen

NETWAYS Blog

Herausforderungen beim Prometheus Scaling

Prometheus ist eine ausgezeichnete Monitoring-Lösung, wenn es um die Überwachung von Verfügbarkeit und Performance geht. Das initiale Deployment geht schnell und mit ein bisschen PromQL KnowHow hat man die Dashboards und Alarme schnell am Laufen. Schon steht die Prometheus Monitoring Lösung. Aber wie skaliert das Ganze?

In größeren oder wachsenden Umgebungen ergeben sich einige Herausforderungen, die es zu überwinden gilt. Im ersten Teil dieses Artikels sollen diese zunächst problematisiert werden. Der zweite Teil stellt dann im Prometheus Ökosystem etablierte Werkzeuge vor, die diese Herausforderungen lösen können.

 

Zentrale Oberfläche für mehrere Prometheus Instanzen

Eine häufige Anforderung ist, eine zentrale Anlaufstelle für mehrere Prometheus Instanzen abzubilden. Soll heißen, dass über die Zeit mehr und mehr Instanzen in Betrieb genommen werden und keine zentralen Abfragen möglich sind. Gründe dafür können sein, dass mehrere unabhängige Systeme jeweils eine oder mehrere Prometheus Instanzen bekommen (beispielsweise Kubernetes Cluster). Außerdem könnten verschiedene Teams oder Netzwerkzonen eigenständige Instanzen benötigen. Häufig zeigt sich: ein Prometheus kommt selten allein.

Fun Fact: der Plural von „Prometheus“ ist „Prometheis“. Im Deutschen wird aber auch gerne „die Prometheus“ als Plural genutzt. Vermutlich auch, weil der dentale Frikative „th“ des Englischen im Deutschen aber als Plosiv zur Geltung kommt und /pʁoˈmeːtaɪ̯s/ komisch klingt.

Auch wenn dank Federation und Remote Write verschiedene zentrale, dezentrale oder hochverfügbare Prometheus Architekturen möglich sind, haben diese oft hohen operativen Aufwand. In zentralen Architekturen könnten zudem einzelne Instanzen, die sich „danebenbenehmen“, das Gesamtkonstrukt stören. Damit sind beispielsweise Daten mit hoher Kardinalität gemeint, oder Instanzen, die hohe Last erzeugen. Es kann also durchaus sinnvoll sein, eigenständige Prometheus Instanzen zu betreiben.

Dadurch hat man aber nun keine zentrale API, um die Daten abzufragen. Heißt, eine Lösung, die eine globale Sicht auf mehrere Instanzen bereitstellt, muss her.

 

Prometheus Mandantenfähigkeit

Da sich, wie eben beschrieben, schnell mehrere Instanzen in der Infrastruktur tummeln, die an einer zentralen Stelle zusammenlaufen sollen, sollte diese Stelle idealerweise Mandantentrennung unterstützen. Heißt beispielsweise, Team A und B möchten sich beim Schreiben und Lesen von Daten nicht über die Füße laufen, aber dennoch die zentrale Infrastruktur nutzen. Daten sollen im besten Fall getrennt voneinander gespeichert werden und Abfragen isoliert voneinander sein.

Mandantenfähigkeit soll also dafür sorgen, dass wir zentrale Infrastruktur gemeinsam nutzen können. Wenn sich diese dann noch in bestehenden Authentifizierungslösung integrieren lässt, wäre das natürlich optimal.

 

Langzeitspeicherung von Daten

Die Anforderungen, für wie lange Metriken aufbewahrt werden müssen, unterscheiden sich je nach Anwendungsfall sehr stark. Dabei sind verschiedenste Faktoren ausschlaggebend.

Für produktive Systeme oder Testumgebungen möchte man vielleicht verschiedene Aufbewahrungsfristen. Daneben ist natürlich die Größe der jeweiligen Umgebung zu beachten, eine handvoll Nodes erzeugen wesentlich weniger Daten, als hunderte. Selbstverständlich spielen auch hier Netzwerkzonen oder Teams eine Rolle. Oder auch ganz einfach der Kostenfaktor, Speicher ist zwar günstig, aber nicht umsonst.

Man möchte also womöglich Daten von Prometheus Instanzen nur für 30 Tage lokal aufbewahren, um das tagtägliche Monitoring zu bewerkstelligen, aber gleichzeitig 6 oder 12 Monate historische Daten, um längerfristige oder wiederkehrende Trends zu erkennen.

Im Folgenden werden einige etablierte Lösungen für die eben beschriebenen Herausforderungen beim Prometheus Scaling beschreiben.

 

Thanos

Thanos (https://thanos.io/) besteht aus einer handvoll Komponenten, die zusätzlich zu Prometheus Instanzen laufen, um so ein skalierbares und hochverfügbares Gesamtkonstrukt zu bauen. Jede Komponente hat hier eine sehr spezifische Aufgabe und versucht diese so gut wie möglich zu lösen (KISS-Prinzip).

Anmerkung des Autors: auch wenn sich einzelne Komponenten eines Systems nach dem „Keep It Simple“ Prinzip ausrichten, heißt das nicht, dass das daraus resultierende Konstrukt nicht durchaus komplex sein kann.

Dieses modulare Design von Thanos hat einige Vorteile. Nicht alle Komponenten müssen zum Einsatz kommen, viele davon sind „stateless“ (speichern also keinen Zustand) und sie skalieren unabhängig voreinander.

Als ein Kernstück von Thanos könnte man das „Store Gateway“ sehen. Diese Komponente spricht mit einem Objektspeicher (beispielsweise S3), um historische Daten zu speichern und stellt eine gRPC API bereit, über welche die Daten angefragt werden können.

Bestehende Prometheus Instanzen können unverändert weiterlaufen und werden jeweils mit der Thanos Sidecar Komponente ausgestattet. Diese schiebt die Prometheus Zeitserienblöcke regelmäßig in den Objektspeicher. Gleichzeitig können mehrere Sidecars über die „Query Frontend“ Komponente gebündelt werden, damit wird eine zentrale API erzeugt, die alle Prometheus Instanzen so wie die historischen Daten abfragen kann.

Eine optionale Downsampling Komponente kann die historischen Daten im Objektspeicher in regelmäßigen Intervallen komprimieren. Außerdem kann eine „Receiver“ Komponente genutzt werden, um Metriken direkt aus Prometheus mittels Remote Write abzuliefern, so vermeidet man die Sidecar Komponente.

Mit Thanos lässt sich problemlos eine zentrale Oberfläche für mehrere Prometheus Instanzen erstellen und auch Langzeitspeicherung von Daten ist machbar. Die Mandantenfähigkeit ist jedoch (Stand August 2023) noch nicht ganz ausgereift. Zwar kennen einige Komponenten das Konzept von Mandanten, die Implementierung ist aber noch nicht sehr einheitlich (ist aber in Arbeit). Dazu muss man fairerweise auch sagen, dass Thanos eine Apache-2.0-lizenzierte freie Software ist, hinter der keine Firma steht, sondern die CNCF.

 

Cortex

Cortex (https://cortexmetrics.io/) basiert in Teilen auf Thanos/Prometheus Code und hat ähnliche Features wie Thanos. Ein wesentlicher Unterschied ist, dass Prometheus Instanzen die Daten immer mittels Remote Write selbst einliefern. Es gibt also keine Sidecar Komponente, aber die Prometheus Konfiguration muss angepasst werden. Diese Anpassung ist jedoch trivial.

Interessant am Cortex Design ist auch, dass es sich um eine einzelne Binärdatei handelt, die alle Komponenten beinhalten. Heißt, Cortex kann im einfachsten Fall als ein Prozess laufen. Ändern sich die Anforderungen, kann man entweder mehrere Instanzen starten, die auf den gleichen Objektspeicher zugreifen, oder einzelne Komponenten skalieren. Sind die Daten einmal im Objektspeicher ist die Architektur sehr ähnlich zu Thanos.

Es gibt aber auch entscheidende Unterschiede. Beispielsweise ist das Downsampling von historischen Daten noch auf der Roadmap (Stand August 2023). Ein vorteilhafter Unterschied ist aber, dass die Mandantenfähigkeit in allen Komponenten verfügbar ist.

Cortex unterstützt Mandantenfähigkeit mittels einem HTTP-Header (X-Scope-OrgID), welcher den jeweiligen Tenant beinhaltet. Jeder Tenant hat dann eine eigene Zeitseriendatenbank im Cortex Objektspeicher und auch jede Abfrage muss diesen HTTP-Header mit der Tenant-ID schicken. Cortex vertraut diesem HTTP-Header, heißt, externe Tools (beispielsweise ein Reverse Proxy) müssen für die Authentifizierung sorgen. HTTP Authentifizierung ist immerhin ein gut verstandenes Problem mit vielen Lösungen.

 

Grafana Mimir

Grafana Mimir (https://grafana.com/oss/mimir/) basiert auf dem Cortex Code. Grafana Labs – ein Haupt-Contributor bei Cortex – hat hier zusätzliche Features zum Produkt „Mimir“ entwickelt. Die Architektur ist großteils identisch und Mimir wurde bewusst in der Version 2.0 veröffentlicht, um den Fork und dessen Features zu differenzieren. Außerdem wurde, basierend auf der Grafana Mimir Code-Base, das Produkt „Grafana Enterprise Metrics (GEM)“ entwickelt, was nochmals weitere Features für den Enterprise-Bereich enthält.

In den Versionen nach dem Fork wurde der Fokus auf Performance-Optimierung und Mandantenfähigkeit gelegt. Erwähnenswert ist allerdings auch, dass Grafana Mimir unter der AGPL-3.0 Lizenz veröffentlicht wurde.

 

Fazit

Monitoring mit Prometheus bringt einige Herausforderungen mit sich. Nicht nur, dass man PromQL verstehen und schreiben lernen muss, bei wachsender Infrastruktur hat man operative Hürden zu bewältigen. Meine persönliche Empfehlung ist aktuell Cortex oder Mimir. Zum einen ist die elegante Deployment Option mit einer (Golang) Binärdatei ein Faktor, und zum anderen die durchgängige Mandantenfähigkeit mittels HTTP-Header. Trotzdem muss man auch sagen, dass die Authentifizierung mit HTTP eigene Herausforderungen mitbringt. Technologisch könnte man das Ganze als gelöstes Problem sehen, Authentifizierung/Autorisierung/Verschlüsselung mit HTTP sind gut verstandene Probleme. Aus einer organisatorischen Perspektive ist das Thema aber immer noch trickreich, da viele Komponenten integriert und betreut werden müssen.

Alles in allem ist Prometheus Monitoring ein spannender Bereich, in dem es noch viele spannende Probleme zu lösen gibt.

Markus Opolka
Markus Opolka
Senior Consultant

Markus war nach seiner Ausbildung als Fachinformatiker mehrere Jahre als Systemadministrator tätig und hat währenddessen ein Master-Studium Linguistik an der FAU absolviert. Seit 2022 ist er bei NETWAYS als Consultant tätig. Hier kümmert er sich um die Themen Container, Kubernetes, Puppet und Ansible. Privat findet man ihn auf dem Fahrrad, dem Sofa oder auf GitHub.

NETWAYS GitHub Update Juli 2023

This entry is part 6 of 15 in the series NETWAYS GitHub Update

Willkommen beim NETWAYS GitHub Update, unser monatlicher Überblick über unsere neuesten Releases.

Im Juli 2023 haben wir wieder einen ganzen Schwung spannender Updates an den Start gebracht. Dazu gehören unter anderem eine Aktualisierung der Golang Bibliothek für Check-Plugins, Version 1.2.5 unseres beliebten Icinga Installers sowie ein neuer Release des NETWAYS Support Collectors.

Zudem haben die Check-Plugins für Bareos, Elasticsearch und Logstash einige Änderungen spendiert bekommen!

Wenn du in Zukunft Updates direkt zu Release erhalten willst, folge uns einfach auf GitHub: https://github.com/NETWAYS/

check-bareos Release v2.0.0

Wir haben diesen Monat einen großen Refactor des Check Plugins durch, damit werden wir das Tool in Zukunft besser warten können. Gibt viele Änderungen, am besten die Release Notes lesen.

Changelog

  • Hinzugefügt: Viele neue Unittests!
  • Hinzugefügt: CLI Parameter unterstützen Thresholds
  • Ausgabe normalisiert und erweitert
  • Diverse Bugfixes

https://github.com/NETWAYS/check_bareos/releases/tag/v2.0.0

go-check Release v0.5.0

Ein etwas größeres Release unserer Golang Bibliothek für Check Plugins. Mit diesem Release haben wir einiges an Code aufgeräumt.

Changelog

  • Einige Abhängigkeiten entfernt
  • Breaking Change: metric und benchmark Pakete entfernt
  • Breaking Change: http/mock Paket entfernt
  • Breaking Change: Ältere Funktionen entfernt
  • Bugfix: Fehler in der Ausgabe von PartialResult gefixt
  • Viele kleine Fixes unter der Haube

https://github.com/NETWAYS/go-check/releases/tag/v0.5.0

check-elasticsearch Release v0.3.0

Changelog

  • Hinzugefügt: Neuer Subcheck für Ingest Pipelines
  • Refactor um teilweise kompatibel mit OpenSearch zu sein
  • Viele Optimierungen unter der Haube

https://github.com/NETWAYS/check_elasticsearch/releases/tag/v0.3.0

check-logstash Release v0.9.0

Changelog

  • Hinzugefügt: Neuer Subcheck für Logstash 8 Pipeline Metriken
  • Hinzugefügt: Neuer Subcheck für Logstash Pipeline Reload Fehler

https://github.com/NETWAYS/check_logstash/releases/tag/v0.9.0

support-collector Release v0.9.0

Changelog

  • Hinzugefügt: Viele neue Kollektoren (Elastic Stack, Prometheus, Graylog, MongoDB, Foreman, diverse Webserver)
  • Hinzugefügt: Neue CLI Option um sensitive Daten zu entfernen
  • Hinzugefügt: Das Tool sammelt jetzt auch teilweise Logdateien ein
  • Viele Abhängigkeiten unter der Haube aktualisiert

https://github.com/NETWAYS/support-collector/releases/tag/v0.9.0

icinga-installer Release v1.2.5

Changelog

  • Bugfix: Weitere PHP und Apache Konfiguration wird nun von Puppet verwaltet
  • Bugfix: Puppet Daemon auf Debian/Ubuntu deaktiviert

https://github.com/NETWAYS/icinga-installer/releases/tag/v1.2.5

Markus Opolka
Markus Opolka
Senior Consultant

Markus war nach seiner Ausbildung als Fachinformatiker mehrere Jahre als Systemadministrator tätig und hat währenddessen ein Master-Studium Linguistik an der FAU absolviert. Seit 2022 ist er bei NETWAYS als Consultant tätig. Hier kümmert er sich um die Themen Container, Kubernetes, Puppet und Ansible. Privat findet man ihn auf dem Fahrrad, dem Sofa oder auf GitHub.

check_prometheus ist jetzt öffentlich verfügbar!

Monitoring ist komplex, das wissen wir hier bei NETWAYS leider zu gut. Deswegen laufen in der Infrastruktur auch mal gerne mehrere Tools für die Überwachung. Zwei gern gesehene Kandidaten sind dabei Icinga und Prometheus. Icinga und Prometheus erfüllen unterschiedliche Rollen im Monitoring, daher besteht oft Bedarf für eine Integration beider Tools. Genau dafür haben wir check_prometheus geschrieben, was wir nun der Öffentlichkeit zur Verfügung stellen.

https://github.com/NETWAYS/check_prometheus

Mit check_prometheus lassen sich der Status deiner Prometheus Server ermitteln, Alarme aus Prometheus auslesen und sogar PromQL aus Icinga auswerten. Das Check Plugin haben wir in Golang geschrieben, das heißt, es werden keine weiteren Abhängigkeiten auf der Icinga Instanz benötigt. Hier einige Beispiele für die Nutzung:

Wir können grundlegend zunächst mal prüfen, ob unser Prometheus Server erreichbar und operativ ist. Dafür nutzen wir den health Unterbefehl:

$ check_prometheus health

[OK] - Prometheus Server is Healthy. | statuscode=200

Natürlich können wir hier Adresse oder TLS Konfiguration als Parameter angeben.

Mit dem alert Unterbefehl, lässt sich außerdem der Status von in Prometheus definierten Alarmen überprüfen. Entweder eines oder mehrerer spezifischen Alarme:

$ check_prometheus alert --name "MyVeryImportantAlert"

[CRITICAL] - 1 Alerts: 1 Firing - 0 Pending - 0 Inactive
\_[CRITICAL] [MyVeryImportantAlert] - Job: [example] is firing - value: 1.00
| firing=1 pending=0 inactive=0

Oder auch einfach alle bereits in Prometheus definierten Alarme und deren Status:

$ check_prometheus alert

[CRITICAL] - 6 Alerts: 3 Firing - 0 Pending - 3 Inactive
\_[OK] [PrometheusTargetMissing] is inactive
\_[CRITICAL] [PrometheusAlertmanagerJobMissing] - Job: [alertmanager] is firing - value: 1.00
\_[OK] [HostOutOfMemory] - Job: [alertmanager]
\_[OK] [HostHighCpuLoad] - Job: [alertmanager]
\_[CRITICAL] [HighResultLatency] - Job: [prometheus] on Instance: [node01] is firing - value: 11.00
| total=6 firing=3 pending=0 inactive=3

Wenn wir keine Alarme in Prometheus definieren wollen, können wir mit dem query Unterbefehl auch direkt PromQL auswerten lassen und gegen Schwellwerte prüfen:

$ check_prometheus query -q my_very_important_metric{job="prometheus"}[10s]' -c5 -w 10

[WARNING] - 1 Metrics: 1 Critical - 0 Warning - 0 Ok
\_[WARNING] my_very_important_metric{instance="node01", job="prometheus"} - value: 15
| my_very_important_metric_node01_prometheus=15

Persönlich empfehle ich jedoch, Alarme in Prometheus zu definieren da wir hier weitere Möglichkeiten haben, den jeweiligen Alarm zu definieren (beispielsweise das for Schlagwort in der Alarm Definition).

Jetzt da wir unsere Prometheus Instanzen mit Icinga integriert haben, können wir uns ansehen, wie wir den Prometheus Alertmanager aus Icinga ansprechen können. Die Integration mit dem Prometheus Alertmanager ist glücklicherweise kein großes Problem. Durch die Prometheus Alertmanager HTTP API, können wir relativ leicht benutzerdefinierte Alarme mittels JSON erzeugen. Alles was wir brauchen ist ein Notification Plugin, das uns die Statusmeldung in Icinga nach JSON transformiert und diese an den Alertmanager schickt.

Da jede Benachrichtigungsstrategie anders aussieht, können wir hier keine universelle Lösung implementieren. Das heißt aber nicht, dass wir nicht Beispiele zur Verfügung stellen können. Im Repository findet ihr ein kleines Python Skript, dass sich ohne Abhängigkeiten auf jeder Icinga Instanz einsetzen lässt:

notify-alertmanager-example.py --hostname mynode01 --service ping --state 2

Hast du einen Bug gefunden, oder brauchst ein neues Feature? Melde dich einfach auf GitHub!

Markus Opolka
Markus Opolka
Senior Consultant

Markus war nach seiner Ausbildung als Fachinformatiker mehrere Jahre als Systemadministrator tätig und hat währenddessen ein Master-Studium Linguistik an der FAU absolviert. Seit 2022 ist er bei NETWAYS als Consultant tätig. Hier kümmert er sich um die Themen Container, Kubernetes, Puppet und Ansible. Privat findet man ihn auf dem Fahrrad, dem Sofa oder auf GitHub.

Icinga Director auf RHEL 7 / 8 / 9 installieren

Der Icinga Director ist die grafische Konfigurationsmöglichkeit für Icinga. Zu Beginn als unabhängiges Modul für die Open Source Monitoring Lösung Icinga entwickelt, ist er heute ein vollwertiger Teil des Icinga Stacks.
Wenn du statt der Konfiguration mit der Icinga API auf eine grafische Icinga Konfigurationslösung umsteigen willst, bist du bei uns richtig.

Unser Icinga Director Installationsguide hilft dir dabei, den Icinga Director auf RHEL 7 / 8 / 9 zu installieren.

Voraussetzungen für die Icinga Director Installation

  • Icinga Open Source Monitoring mit folgenden Komponenten:
    • Icinga Core
    • Icinga Web
    • Icinga DB
    • Icinga DB Web
  • Internetzugang
  • Zugang zu Icinga Web
  • Installations- und Administrationsrechte für den Icinga Config Master

Du kannst hinter alle diese Punkte einen Haken setzen? Dann legen wir los!

Anmerkung: Alle nachfolgende Schritte werden als root-User durchgeführt. Überprüfe, ob du den richtigen Benutzer verwendest!

Schritt 1: Icinga Repository zu RHEL hinzufügen

Hinweis: Die Schritte die hier für Red Hat Enterprise Linux beschrieben werden, sind ebenso für alle RHEL-basierten Linux Betriebssysteme, zum Beispiel Rocky Linux, Alma Linux, Alpine Linux oder Oracle Linux möglich.

Beachte zudem, dass es sich beim Icinga RHEL Repository um ein kostenpflichtiges Repo handelt. Der Zugang ist Teil der Icinga Subscription Repositories.

Das Repository fügst du mit zwei einfachen Befehlen zu deinem System hinzu:

rpm --import https://packages.icinga.com/icinga.key 
wget https://packages.icinga.com/subscription/rhel/ICINGA-release.repo -O /etc/yum.repos.d/ICINGA-release.repo

Schritt 2: Icinga Director installieren


Um das das Icinga Director Paket aus dem gerade hinzugefügten Repo auf RHEL zu installieren nutzt du diesen Befehl:

RHEL 8 oder später:

dnf install icinga-director

RHEL 7:

yum install icinga-director

 

Schritt 3: Icinga Director Datenbank aufsetzen

Damit der Icinga Director Daten lesen und schreiben kann, benötigt das Icinga 2 Modul eine eigene Datenbank.

Hinweis: In deiner eigenen Umgebung muss SICHERES_PASSWORT mit einem richtigen Passwort deiner Wahl ausgetauscht werden.

MySQL/MariaDB

mysql -e "CREATE DATABASE director CHARACTER SET 'utf8'; 
CREATE USER director@localhost IDENTIFIED BY 'SICHERES_PASSWORT'; 
GRANT ALL ON director.* TO director@localhost;"

PostgreSQL

psql -q -c "CREATE DATABASE director WITH ENCODING 'UTF8';" 
psql director -q -c "CREATE USER director WITH PASSWORD 'SICHERES_PASSWORT'; 
GRANT ALL PRIVILEGES ON DATABASE director TO director; 
CREATE EXTENSION pgcrypto;"

Damit sind alle Schritte im Terminal abgeschlossen. Die nächsten Schritte finden in Icinga Web statt.

Schritt 4: Icinga Director konfigurieren

Damit der Icinga Director in Icinga Web funktioniert, müssen weitere Konfigurationsschritte innerhalb der Icinga Weboberfläche vorgenommen werden.

Anlegen einer neuen Icinga Datenbank Ressource

Im unteren Bereich des linken Icinga Web Menüs befindet sich ein Zahnrad. Sobald du mit der Maus darüber gehst, siehst du das „Hauptmenü“ von Icinga Web. Hier folgst dem folgenden Pfad, um zu den Datenbankressourcen zu gelangen:

Configuration –> Application –> Resources

Mit einem Klick auf Create a New Ressource kommst du zu einer Eingabemaske. Hier trägst du die in Schritt 3 angelegten Zugangsdaten für die Icinga Director Datenbank ein und validierst die Konfiguration.

Screenshot der Icinga Web Umgebung des Monitoring Systems Icinga. Zu sehen ist das Anlegen einer neuen Datenbankressource zur Nutzung des Icinga Moduls "Icinga Director" inklusive der erfolgreichen Validierung

Icinga Director Kickstart Wizard

Nutze den Icinga Director Kickstart Wizard, um den Icinga Director zu konfigurieren. Klicke dafür im nun vorhandenen Menüpunkt unter „Ressources“ auf Icinga Director. Wähle die gerade angelegte Datenbankressource aus, damit der Director seine Daten auch in die gewünschte Datenbank schreibt.

Screenshot der Icinga Web Umgebung des Monitoring Systems Icinga. Zu sehen ist das Auswählen einer neuen Datenbankressource zur Nutzung des Icinga Moduls "Icinga Director"

Mit einem Klick auf Create Schema wird das Datenbankschema übertragen und der Kickstart Wizard gestartet.

Screenshot der Icinga Web Umgebung des Monitoring Systems Icinga. Zu sehen ist der Kickstart Wizard des Icinga Moduls "Icinga Director" der dafür sorgt, dass das Modul automatisiert in das bestehende System integriert wird

An dieser Stelle müssen drei Felder ausgefüllt werden, bevor der Prozess weitergehen kann:

  • Endpoint Name
  • API User
  • (API) Password

Wenn du dich jetzt fragst, was genau der Icinga Endpoint Name noch mal ist, dieser wurde in Schritt 5 des Icinga Installationsguides für Ubuntu oder des Icinga Installationguides für RHEL im Rahmen des Icinga Node Wizard angelegt.
Es handelt sich dabei um den Objektnamen deines Icinga Master.

Er kann jederzeit unter /etc/icinga2/zones.conf nachgelesen werden. Wenn du deinen Icinga API User und das dazugehörige Passwort noch einmal nachschlagen willst, kannst du das unter /etc/icinga2/conf.d/api-users.conf.

Hast du alle erforderlichen Felder ausgefüllt und den Import gestartet, dauert es einen kurzen Moment. Ist der Prozess erfolgreich abgeschlossen, siehst du im Icinga Director Menü neben Activity log eine dreistellige Zahl, ähnlich der im Screenshot:

Screenshot der Icinga Web Umgebung des Monitoring Systems Icinga. Zu sehen ist der Kickstart Wizard des Icinga Moduls "Icinga Director" im Status der erfolgreich durchgeführten Integration

Diese Zahl zeigt die Anzahl der getätigten Änderungen an, die über den Icinga Director durchgeführt wurden, jetzt aber noch auf dein Icinga 2 Monitoring ausgerollt werden müssen. Diesen letzten Schritt führst du aus, indem du auf Activity log klickst und im oberen Bereich des sich öffnenden Menüs auf Deploy XXXX pending changes klickst.

Screenshot der Icinga Web Umgebung des Monitoring Systems Icinga. Zu sehen ist die Ansicht der durchzuführenden Deployments

Damit hast du erfolgreich den Icinga Director auf RHEL installiert und den letzten Teil des Icinga Stack aufgesetzt und konfiguriert.

Wie geht es jetzt weiter?

Egal ob du unsere Guides zur Icinga Installation seit der Anleitung zur Installation von Icinga auf RHEL genutzt hast oder nur für den Guide zur Icinga Director Installation hier gelandet bist: Herzlichen Glückwunsch zum erfolgreichen Abschluss dieses Guides!

Mit dem Icinga Director nutzt du nun ein mächtiges grafisches Konfigurationstool für Icinga, dass dir die tägliche Arbeit sicher erleichtern kann. Zusammen mit dem IcingaIcinga WebIcinga DB und Icinga DB Web steht dir nun der volle Icinga Stack zur Verfügung.

An dieser Stelle bleibt mir nur noch übrig, dir viel Spaß mit deinem Open Source Monitoring System Icinga zu wünschen.

Icinga Web und Icinga DB Web auf RHEL 7 / 8 / 9 installieren

Icinga Web ist die vom Icinga Team entwickelte und als Teil des Icinga Stack zur Verfügung gestellt Weboberfläche zur Visualisierung der Icinga Monitoring Daten. Die im Webbrowser nutzbare Lösung hat den Vorteil, dass von überall auf die Daten, die das Infrastrukturmonitoring erzeugt, zugegriffen werden kann.

Icinga Web ist die optimale Lösung, wenn es darum geht, die Abläufe und Checks deines Open Source Monitoring zu visualisieren.
Dieser Guide hilft dir bei der Installation und Konfiguration von Icinga Web und Icinga DB Web auf RHEL 7 / 8 / 9 oder einem auf RHEL basierenden Linux wie Rocky Linux, Alma Linux oder Oracle Linux.

Wenn du bereits unseren Guide zur Installation und Konfiguration von Icinga und Icinga DB auf RHEL durchgeführt hast, kannst du direkt loslegen. Sind Icinga 2 und Icinga DB noch nicht auf deinem System installiert, solltest du jetzt zu unserem Guide zur Icinga Installation wechseln und anschließend hier weiterlesen.

Voraussetzungen für die Icinga Web und Icinga DB Web Installation

Damit dieser Guide erfolgreich umgesetzt werden kann, gibt es einige wichtige Voraussetzungen:

  • Ein bereits vorhandenes Icinga bestehend aus:
    • RHEL Server mit mindestens 2 GB RAM und 20 GB freiem Speicherplatz
      • Die Nutzung von RHEL basierten Linuxen wie Rocky LinuxAlma LinuxOracle LinuxAlpine Linux und anderen ist mit den Repositories ebenfalls möglich
    • Icinga CoreIcinga DBIcingaDB-Redis und MySQL/MariaDB/PostgreSQL
  • sudo – Benutzer ist auf dem Server eingerichtet und du hast das Recht ihn zu nutzen
  • Die aktuellste PHP-Version
  • Eine Internetverbindung auf den Server
  • Ein Webserver (Apache, Nginx, etc.) ist auf dem Server installiert

Du kannst hinter alle diese Punkte einen Haken setzen? Dann legen wir los!

Anmerkung: Alle nachfolgende Schritte werden als root-User durchgeführt. Überprüfe, ob du den richtigen Benutzer verwendest! Um den Text leserlich zu halten, wird bei den Befehlen immer von „RHEL“ gesprochen. Die Befehle lassen sich jedoch ebenso auf allen RHEL basierenden Systemen anwenden.

Schritt 1: Icinga Repository hinzufügen

Um eine Installation von Icinga überhaupt durchzuführen, muss das nachfolgende Repository bereits zum System hinzugefügt sein und nicht wiederholt werden. Falls diese Installation jedoch eine Weile her ist oder du auf „Nummer sicher“ gehen willst, sind hier die Befehle, mit denen du das offizielle Icinga-Repository zu deinem System hinzufügst:

rpm --import https://packages.icinga.com/icinga.key 
wget https://packages.icinga.com/subscription/rhel/ICINGA-release.repo -O /etc/yum.repos.d/ICINGA-release.repo

Hinweis: Beachte jedoch, dass es sich beim Icinga RHEL Repository um ein kostenpflichtiges Repo handelt. Der Zugang ist Teil der Icinga Subscription Repositories.

Schritt 2: Icinga Web und Icinga DB Web auf RHEL installieren

Bevor die Installation und Konfiguration von Icinga Web startet, wird das icingadb-web Paket installiert. Dieser Schritt stellt sicher, dass im späteren Verlauf der Icinga Web Installationsanleitung das Modul direkt aktiviert und konfiguriert werden kann. Zu Installation nutzt du:

RHEL 8 oder später:

dnf install icingadb-web

RHEL 7:

yum install icingadb-web

 

Hinter diesem Befehl verbirgt sich ein Paket, dass NICHT NUR das angesprochene Modul installiert. Zusätzlich installiert dieser Befehl direkt alle noch nicht vorhandenen Abhängigkeiten.
Unter anderem sind das Icinga Web, icingacli und libapache2-mod-php. Dieser kleine Befehl ist somit das Schweizer Taschenmesser dieser Installation.

Ist auf deinem System SELinux aktiv, muss zudem das entsprechende Icinga Web 2 Paket installiert werden:

RHEL 8 oder später:

dnf install icingaweb2-selinux

RHEL 7:

yum install icingaweb2-selinux

 

Im nächsten Schritt geht es weiter mit der Konfiguration und Webinstallation von Icinga Web.

Schritt 3: Einrichtung von Icinga Web

Bevor es zur Einrichtung von Icinga Web im Browser geht, müssen die letzten Konfigurationsschritte durchgeführt werden.

Schritt 3.1: Authentifizierungs-Token erstellen

Damit Icinga Web mit dem Icinga Web Setup Wizard schnell und einfach installiert und konfiguriert werden kann, benötigst du ein Token zu Authentifizierung. Dieses erstellst du mit folgendem icingacli-Befehl:

icingacli setup token create

Für den Fall, dass das Token zu einem späteren Zeitpunkt erneut aufgerufen werden muss, gibt es diesen Befehl:

icingacli setup token show

 

Damit sind alle Vorbereitungen abgeschlossen und die eigentliche Einrichtung von Icinga Web kann beginnen.

Schritt 3.2: Icinga Web Datenbank anlegen

Damit Icinga Web Daten aufrufen, verarbeiten und weiterleiten kann ist eine Datenbank notwendig. Mit den folgenden Befehlen wird eben diese Icinga Web Datenbank angelegt:

mysql -u root -p
CREATE DATABASE icingaweb2;
CREATE USER 'icingaweb2'@'localhost' IDENTIFIED BY 'USE_A_SECURE_PASSWORD_HERE';
GRANT ALL ON icingaweb2.* TO icingaweb2@localhost;

 

Hinweis: Bevor es in den Browser geht, prüfe folgendes:

  • Firewall ist so eingerichtet, dass die Ports 80 und 443 nach außen kommunizieren dürfen
  • Alle Dienste und Services (u.A. Webserver, Icinga 2, Icinga Web 2) wurden noch einmal neu gestartet. Dadurch werden alle Abhängigkeiten untereinander sicher hergestellt

Schritt 4: Icinga Web im Browser einrichten

Um den Icinga Web Wizard zu starten, rufst du im Browse die IP-Adresse deiner Icinga-Instanz auf und hängst /icingaweb2/setup hinten an.

Icinga Token einfügen

Direkt zu Beginn der Installation trägst du das in Schritt 3.2 erzeugte Token ein:

Screenshot des Icinga Web Setups, bei dem die Eingabemaske für das Icinga Token zu sehen ist

Icinga Web Module auswählen

Auf der folgenden Seite wählst du aus den fünf vorgeschlagenen Modulen die aus, die du nutzen willst. Standardmäßig ist bereits das Icinga DB Modul ausgewählt, was beibehalten werden muss!

WICHTIG: Da wir eine aktuelle Installation von Icinga 2 und Icinga Web 2 durchführen, kommt Icinga DB anstelle der bisher verwendeten IDO zum Einsatz. Von daher kann auf das Modul Monitoring verzichtet werden!

Ansicht der Icinga Web Setup Oberfläche zur Einrichtung von Icinga Web Modulen (dunkelblauer Hintergrund, hellblauer Header). In der aktuellen Ansicht ist das Modul IcingaDB zur EInrichtung ausgewählt.

Icinga Web PHP Module überprüfen

Im Anschluss erhältst du eine Übersicht über alle benötigten und optionalen PHP-Module, auf die Icinga Web Zugriff hat. Hier kannst du überprüfen, ob alle kritischen Abhängigkeiten vorhanden sind.

Ansicht der Icinga Web Setup Oberfläche mit einer Übersicht der aktiven PHP Module (dunkelblauer Hintergrund, hellblauer Header). In der aktuellen Ansicht sind ausser ein optionales Modul alle PHP Module aktiv

Authentifizierungsmethode wählen

Um eine Zugangsauthentifizierung zu Icinga Web 2 durchzuführen, stehen dir drei verschiedene Möglichkeiten zur Verfügung: DatabaseLDAP oder External.

Hier kannst du die von dir oder deinem Unternehmen präferierte Authentifizierungsmethode nutzen. Die Eingabe der nötigen Daten erfolgt in einem späteren Schritt.
In diesem Guide beziehen wir uns auf die Authentifizierung über die Datenbank.

Ansicht der Icinga Web Setup Oberfläche zur Auswahl der Authentifizierungsmethode (dunkelblauer Hintergrund, hellblauer Header). In der aktuellen Ansicht wird die Datenbank zur Authentifizierung genutzt

Datenbank-Authentifizierung

Im Formular zur Datenbank-Authentifizierung trägst du alle wichtigen Informationen ein.

Ansicht der Icinga Web Setup Oberfläche mit einem Formular zur Eingabe der Datenbank Zugangsdaten (dunkelblauer Hintergrund, hellblauer Header). In der aktuellen Ansicht ist das leere Formular zu sehen

Hier noch eine kurze Erklärung der einzelnen Punkte:

  • Ressource Name: Name deiner Datenbank-Ressource. Kann den Default Namen behalten
  • Database Type: Je nachdem, ob du MySQL/MariaDB oder PostgreSQL verwendest, wählst du hier den entsprechenden Typen aus
  • Host:Auf welchem Host liegt deine Datenbank? In dem meisten Fällen kannst du hier den Default localhost beibehalten
  • Port: Hast du einen speziellen Port für deine Datenbank freigegeben? Dann musst du diesen hier eintragen
  • Database Name: Namen der Datenbank ein, die du in Schritt 3.3 für Icinga Web angelegt hast
  • Username: Username aus Schritt 3.3
  • Password: Passwort für den User aus Schritt 3.3
  • Character Set: Du nutzt ein bestimmtes Character Set? Hier optional angeben
  • Use SSL: Nutzt du Verschlüsselung und SSL-Zertifikate? Aktiviere den Button und gib deine Daten ein

Hast du deine Daten eingegeben, drückst du Validate Configuration. War alles richtig, bekommst du diese Ansicht:

Ansicht der Icinga Web Setup Oberfläche mit einem Formular zur Eingabe der Datenbank Zugangsdaten (dunkelblauer Hintergrund, hellblauer Header). In der aktuellen Ansicht ist das ausgefüllte Formular inklusive erfolgreicher Validierung zu sehen

Icinga Web Backend Authentifizierung

Wähle im nächsten Schritt einen Namen für dein Icinga Web Authentifizierungsbackend aus.

Ansicht der Icinga Web Setup Oberfläche zur Auswahl er Backend Authentifizierung (dunkelblauer Hintergrund, hellblauer Header).

Icinga Web Admin User anlegen

Als Nächstes legst du deinen Icinga Web Admin an. Gib ihm einen Benutzernamen und ein sicheres Passwort!

Ansicht der Icinga Web Setup Oberfläche zum Anlegen eines administrativen Benutzers (dunkelblauer Hintergrund, hellblauer Header).

Icinga Web Anwendungs- und Loggingeinstellungen

Auf dieser Seite hast du die Möglichkeit, ein paar individuelle Konfigurationen an der Anwendung so wie dem Loggingverhalten von Icinga Web vorzunehmen. Für diesen Guide werden die Standardeinstellungen beibehalten.

Ansicht der Icinga Web Setup Oberfläche zur Auswahl der individuellen Logging-Einstellungen für die Monitoring-Umgebung (dunkelblauer Hintergrund, hellblauer Header).

Übersicht der bisherigen Icinga Web Konfiguration

Zum Abschluss der Konfiguration erhältst du eine Übersichtsseite, auf der du noch einmal alle von dir gewählten Einstellungen überprüfen kannst. Wenn du zufrieden bist und keinen Fehler erkennst, drücke auf Finish und schließe die Icinga Web Konfiguration ab.

Ansicht der Icinga Web Setup Oberfläche mit allen bisher getätigten Einstellungen zur Übersicht am Ende des aktuellen Einrichtungsschrittes (dunkelblauer Hintergrund, hellblauer Header).

Icinga DB Web konfigurieren

Nach der Übersicht der Icinga Web 2 Konfiguration startet die Konfiguration von Icinga DB Web.

Ansicht der Icinga Web Setup Oberfläche mit dem Beginn der IcingaDB Konfiguration (dunkelblauer Hintergrund, hellblauer Header).

Folgt man dem Config Wizard auf die nächste Seite, wirst du aufgefordert, deine Icinga DB Datenbank-Credentials einzugeben.
Wenn du unsere Anleitung zur Installation und Konfiguration von Icinga und Icinga DB [LINK EINFÜGEN] genutzt hast, wurden die Zugangsdaten zu diesem Zeitpunkt erstellt.

Ansicht der Icinga Web Setup Oberfläche mit einem Formular zur Eingabe der IcingaDB Datenbank Zugangsdaten (dunkelblauer Hintergrund, hellblauer Header).

Wurden alle Felder richtig ausgefüllt und die Konfiguration validiert, erscheint eine Erfolgsmeldung.

Ansicht der Icinga Web Setup Oberfläche mit ausgefülltem Formular der IcingaDB Datenbank Zugangsdaten und erfolgreicher Validierung dieser Daten (dunkelblauer Hintergrund, hellblauer Header).

Nachdem die Verbindung zur Datenbank erfolgreich eingerichtet wurde, muss nun noch die Verbindung zu Icinga DB Redis hergestellt werden.

Ansicht der Icinga Web Setup Oberfläche mit einem Formular zur Eingabe der IcingaDB-Redis Datenbank Zugangsdaten (dunkelblauer Hintergrund, hellblauer Header).

Wie bei der Datenbank werden hier die Zugangsdaten eingeben und die Konfiguration validiert.
(Da während der Einrichtung von Redis auf ein Passwort verzichtet wurde, kann das Feld hier ebenfalls freigelassen werden)

Ansicht der Icinga Web Setup Oberfläche mit ausgefülltem Formular der IcingaDB-Redis Datenbank Zugangsdaten und erfolgreicher Validierung dieser Daten (dunkelblauer Hintergrund, hellblauer Header).

Icinga API mit Icinga Web verbinden

Der letzte Schritt vor dem erfolgreichen Abschluss der Konfiguration von Icinga Web ist das Herstellen der Verbindung von Icinga Web zur Icinga API.
Der standardmäßige API-Nutzer ist root. Dieser und das dazugehörige Passwort hast du während unseres Guide zur Installation und Konfiguration von Icinga und Icinga DB erstellt. Das Passwort kann jedoch jederzeit unter /etc/icinga2/conf.d/api-users.conf nachgeschlagen werden.

Ansicht der Icinga Web Setup Oberfläche mit ausgefülltem Formular zur mit der Icinga API und erfolgreicher Validierung dieser Daten (dunkelblauer Hintergrund, hellblauer Header).

Die Konfiguration endet mit einer Übersichtsseite, auf der alle eingegebenen Daten noch einmal überprüft werden können.

Ansicht der Icinga Web Setup Oberfläche mit allen bisher getätigten Einstellungen für IcingaDB zur Übersicht am Ende des aktuellen Einrichtungsschrittes (dunkelblauer Hintergrund, hellblauer Header).

Waren alle hier beschriebenen Schritt erfolgreich, strahlt dir ein grünes Congratultaions! Icinga Web 2 has been successfully set up entgegen.

Nun steht deinem ersten Icinga Web Login nichts mehr im Weg.

Schritt 5: Der erste Icinga Web Login

Mit deinem gerade angelegten Icinga Web 2 User und Passwort loggst du dich nun in Icinga Web ein. Damit gelangst du auf das Dashboard:

Ansicht des Icinga Web Dashboards nach erfolgtem Login. Zu sehen sind alle Menüpunkte sowie einige Monitoringbeispiele

Damit du als neue:r Nutzer:innen einen ersten Eindruck davon erhältst, wie die vom Systemmonitoring oder Netzwerkmonitoring gesammelten Daten dargestellt werden, wird Icinga mit einer Beispielkonfiguration ausgeliefert. Diese kann gelöscht werden, sobald man selbst damit beginnt, Icinga mit seinen eigenen Daten und Templates zu füllen.

Wie gehts es nun weiter?

Herzlichen Glückwunsch, du hast erfolgreich Icinga, Icinga DB und Icinga Web installiert und konfiguriert! Damit steht deiner aktiven Nutzung der Open Source Monitoring Lösung nichts mehr im Weg.
Du kannst direkt loslegen und über die Icinga2 API Objekte anlegen, Actions triggern oder Templates bauen. Welche API-Calls dafür zur Verfügung stehen, erfährst du ausführlich in den Icinga Docs.

Die Verwaltung und Nutzung von Icinga über die API ist eine häufig genutzt und valide Option. Eine weitere Möglichkeit diese Einstellungen vorzunehmen ist der Icinga Director. Dieser gibt Nutzer:innen die Möglichkeit, den Icinga Stack grafisch innerhalb von Icinga Web zu konfigurieren.
Wenn du dich dafür interessierst, wie der Icinga Director installiert und konfiguriert wird und wie du ihn einsetzen kannst, lege ich dir unseren Guide Icinga Director auf RHEL 7 / 8 / 9 installieren ans Herz.