Seite wählen

NETWAYS Blog

NETWAYS GitHub Update Januar 2024

This entry is part 12 of 12 in the series NETWAYS GitHub Update

Willkommen beim NETWAYS GitHub Update, der monatliche Überblick über unsere neuesten Releases.

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

check-system-basics v0.1.0

Das erste Release von check-system-basics, ein Monitoring Plugin für eine ganze handvoll Systemeigenschaften, war zwar schon Ende Dezember zugänglich, die Werbetrommel wollten wir aber erst im Januar schlagen.

NETWAYS Consultant Lorenz hat in seinem Blogpost das Plugin und die Motivation dahinter ausführlich besprochen. Unbedingt lesen!

Changelog

  • Initiales Release

https://github.com/NETWAYS/check_system_basics/releases

notify-zammad v0.1.0

Das offene und freie Helpdesk-System Zammad hat zwar eine eigene Icinga Integration, diese hat aber Anforderungen unserer Kunden nicht erfüllt. Mit unserem neuen Notification Plugin lassen sich Tickets in Zammad über Icinga Benachrichtigungen verwalten.

Das Plugin ist nun unter einer GPLv2 Lizenz öffentlich verfügbar. Feedback könnt ihr gerne und jederzeit auf GitHub abgeben!

Changelog

  • Initiales Release

https://github.com/NETWAYS/notify_zammad/releases/tag/v0.1.0

Markus Opolka
Markus Opolka
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 November 2023

This entry is part 10 of 12 in the series NETWAYS GitHub Update

Willkommen beim NETWAYS GitHub Update, der monatliche Überblick über unsere neuesten Releases.

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

go-check v0.6.1

Changelog

  • Bugfix in der partialResults Berechnung

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

check-sentinelone v0.3.0

Changelog

  • Anpassung für Änderungen in der SentinelOne Cloud API hinzugefügt
  • Build mit neuerer Golang Version
  • Diverse Abhängigkeiten aktualisiert

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

icinga-installer v1.2.7

Changelog

  • Bugfix: Icinga Director Port ist nun konfigurierbar

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

 

Markus Opolka
Markus Opolka
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 12 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
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
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.