Seite wählen

NETWAYS Blog

Die Migration von IDO zu Icinga DB – so geht’s kinderleicht!

Letzte Woche hatten wir ein sehr erfolgreiches NETWAYS Webinar, in dem ich demonstriert habe, wie einfach die Installation der Icinga DB auf einem bestehenden System ist. In diesem Blogpost möchte ich auf einige Aspekte und Anleitungsschritte aus dem Webinar eingehen. Ich werde Dir zunächst die Vorteile der Icinga DB und ein paar Unterschiede zwischen IDO und Icinga DB erklären, bevor wir dann in Kürze die notwendigen Schritte auf dem Weg zu Deiner laufenden Icinga DB durchgehen.

Was ist die Icinga DB eigentlich?

Was ist die Icinga DB?“ Auf dieses Thema bin ich letztes Jahr im gleichnamigen Webinar eingegangen. Bei der Icinga DB handelt es sich um ein vollständig neues Backend für Icinga, um Informationen zu speichern und in Icinga Web verfügbar zu machen. IDO und Icinga DB unterscheiden sich maßgeblich in ihrer Architektur. Diesen Unterschied merkt man vor allem in sehr großen oder sehr Check-Intensiven Umgebungen.

Was ist der Unterschied zwischen IDO und Icinga DB?

Alles in die Datenbank

In der bisherigen IDO werden alle Statusinformationen direkt in der MySQL/MariaDB oder PostgreSQL Datenbank gespeichert. Das bedeutet, dass jeder einzelne Check, der von Icinga ausgeführt wird, als Ergebnis in die Datenbank geschrieben wird. Dabei reden wir aber noch nicht von historischen Daten oder Statusänderungen von einem Host/Service. Jeder einzelne Output, der von einem Plugin generiert wird, egal ob es eine Statusänderung gibt oder nicht, wird in die Datenbank geschrieben. Schließlich möchte man im Webinterface den aktuellen Plugin Output sehen.

Werden Checks nun in einem sehr häufigen Intervall ausgeführt oder es handelt sich um eine sehr große Umgebung, steigt die Last auf der Datenbank exponentiell. Das sorgt für Mehrkosten bei der Datenbank, aber auch für mehr Aufwand zum Fine-Tuning.

Aufteilung von volatilen und persistenten Daten

Hier kommt der Vorteil der neuen Icinga DB zum Einsatz. Anders als bei der IDO, werden die Informationen nach Ihrer „Lebensdauer“ sinnvoll verteilt. Bei volatilen Daten sprechen wir beispielsweise von den oben bereits erwähnten Check-Ergebnissen, die keine Auswirkungen auf Statusinformationen haben, sondern rein für den Output relevant sind. Mit der Icinga DB werden diese Daten in einen Redis geschrieben. Dieses Tool erlaubt das Ablegen von Informationen über eine entsprechende API direkt im Memory des Servers, ohne dass eine Schreibaktion auf die Festplatte oder in einer Datenbank notwendig sind. Über die vorhandene API werden die Informationen dann später wieder ausgelesen, aktualisiert oder gelöscht.

In der MySQL/MariaDB/PostgreSQL Datenbank, landen dann nur historische Daten, Statusinformationen oder andere wichtige persistente Daten. Damit reduziert sich die Schreib- und Lese-Last auf der Datenbank enorm. Icinga Web liest die notwendigen Inhalte der jeweiligen Objekte dann sowohl aus dem Redis, als auch aus der Datenbank und stellt diese im neuen Icinga DB Webfrontend dar.

Installation der Icinga DB

Die Installation der notwendigen Komponenten für die Icinga DB ist spielend einfach. Sehr praktisch ist, dass ein Parallelbetrieb zwischen IDO und Icinga DB möglich ist. Somit kannst Du die Icinga DB testen und beide Backends parallel verwenden.

Ja nach Linux Distribution sind die Befehle für die Installation ein wenig anders. Die notwendigen Pakete sind jedoch überall gleich. Du benötigst die Folgenden:

  • icingadb
  • icingadb-redis
  • icingadb-web

Im Webinar sind wir ab 7:58 dabei, die Pakete zu installieren und die Konfigurationen einzustellen. Wichtig ist dabei zu beachten, dass die Icinga DB eine eigene Konfigurationsdatei unter

/etc/icingadb/config.yml

besitzt, die im Vorfeld editiert werden muss. Bei einem klassischen Setup von lokalen Redis und externer Datenbank, sind nur die IP und die Authentifizierungs-Daten für die Datenbank wichtig.

Icinga DB Web

Sind alle Schritte wie in den Anleitungen und im Webinar aufgezeigt durchgeführt worden, hast Du einen sauberen Parallelbetrieb zwischen IDO und Icinga DB verfügbar. Die Unterschiede der Web UI sind bemerkenswert!

In den YouTube Kommentaren kam die Frage auf, wieso wir auf das Paket icingadb-web nicht weiter eingegangen sind, obwohl es installiert wurde. Das liegt daran, dass in der Modulansicht in Icinga Web das Paket als icingadb und nicht als icingadb-web angezeigt wird. Alle Schritte und Konfigurationen innerhalb von Icinga Web, die sich auf das icingadb Modul beziehen, beziehen sich also auf das installierte Paket icingadb-web.

Migration von IDO zu Icinga DB

Zu guter Letzt fehlt nur noch die Migration von IDO auf Icinga DB, um alle historischen Informationen, Ereignisse, etc. im neuen Datenbackend verfügbar zu haben. Damit steht Deinem Parallelbetrieb mit allen Informationen nichts mehr im Wege, Du kannst Dich an das neue Interface gewöhnen, bevor Du die IDO und das alte Monitoring Modul abschaltest. Im Webinar sind wir auf diesen Punkt zwar eingegangen, durch eine Fehlkonfiguration lief es jedoch nicht wie gewünscht durch.

Wer eine vollständige Datenübernahme wünscht, kann dies wie folgt tun. Bitte beachte, dass je nachdem wie große eure Datenbank ist, der Task mehrere Stunden oder Tage in Anspruch nehmen kann. In diesem Fall empfehle ich Dir, das Migrationsskript mehrmals auszuführen und die Zeiträume unterschiedlich zu splitten. Das Skript erkennt, ob Daten bereits übernommen wurden und führt keine doppelten Aktionen aus, auch wenn sich Zeiträume von einem Durchlauf zum nächsten überschreiten.

Als erstes brauchst Du Deine Environment Id für die Icinga DB. Diese erhältst Du wie folgt:

# cat /var/lib/icinga2/icingadb.env

Anschließend generierest Du eine .yml Datei mit folgendem Inhalt – damit werden alle Daten aus der IDO in die Icinga DB migriert:

icinga2:
  # Content of /var/lib/icinga2/icingadb.env
  env: ....

# IDO database
ido:
  type: mysql # or "pgsql" for PostgreSQL
  host: 127.0.0.1
  #port: 3306
  database: ido_db
  user: dbuser
  password: dbpass
  # Input time range
  #from: 0
  #to: 2147483647

# Icinga DB database
icingadb:
  type: mysql # or "pgsql" for PostgreSQL
  host: 127.0.0.1
  #port: 3306
  database: icingadb
  user: icingadb_user
  password: icingadb_pass

 

Ist alles konfiguriert, kannst Du das Skript starten, welches direkt mit dem icingadb Paket installiert wird.

# icingadb-migrate -c icingadbmigrate.yml -t ~/icingadb-migration.cache

In diesem Fall befindest Du Dich direkt in dem Ordner, in welchem Du die .yml Datei abgelegt hast – bei mir heißt diese icingadbmigrate.yml. Das Skript schreibt nun zunächst alle Informationen aus der IDO in die icingadb-migration.cache Datei. Ist dies erledigt, werden die Daten aus dem Cache in die Icinga DB geschrieben. Bricht aus irgendeinem Grund der Vorgang ab oder das System muss neu gestartet werden, ist dies kein Problem. Solange die Konfiguration und die Cache-Datei unverändert bleiben, macht das Skript an der Stelle weiter, wo es aufgehört hat, nachdem Du es erneut aufrufst.

Professionelle Unterstützung

Wer diesen Vorgang nicht allein durchführen möchte, in Probleme läuft oder eine Beratung zur Architektur und dem genauen Vorgehen zur Umstellung wünscht, kann natürlich über uns direkt professionelle Unterstützung in Form von Consulting für euer zeitlich begrenztes Projekt oder Outsourcing für langfristige Unterstützung erhalten.

Beim Outsourcing bieten wir drei unterschiedliche Modelle für Dienstleistungen an und können schnell sowie zielgerichtet auf Themen eingehen. Die Zeitbuchung erfolgt immer im 15 Minuten Intervall und wird von einem vorhandenen Kontingent abgebucht oder über einen Vertrag monatlich abgerechnet. Das ist vor allem hilfreich, wenn kontinuierliche Unterstützung bei kleinen Themen gewünscht ist oder der tägliche Betrieb abgegeben werden soll.

Im Consulting können wir darüber hinaus zielgerichtet auf alle Details zur Architekturplanung, Umstellung oder dem Aufbau/Ausbau eingehen und bei der Konzeptionierung sowie der eigentlichen Umsetzung unterstützen. In Kombination mit dem Outsourcing, bietet das ein starkes und flexibles Paket.

Wer mehr dazu wissen möchte, kann sich über unser Kontaktformular mit uns in Verbindung setzen. Wir stehen beratend zur Seite und stimmen gemeinsam die beste Vorgehensweise ab!

Ich freue mich auf eure Anfragen!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Icinga for Windows v1.6.0 – Einfacher. Zentraler. Sicherer.

Die Kollegen von Icinga haben letzte Woche Icinga for Windows in Version v1.6.0 veröffentlicht. Auch wenn diese Version keine neuen Plugins für die Überwachung bietet, hat sich im Bereich des Icinga PowerShell Frameworks einiges getan. Dadurch ist die Lösung nicht nur einfacher zu verwenden, sondern auch noch zentraler verwaltbar und sicherer.

Dürfen wir vorstellen: Die IMC

Die IMC (Icinga Management Console) wurde im Rahmen vergangener Icinga for Windows als experimental eingeführt. Ziel war es, ein einfaches Management zu schaffen, um die meisten Funktionalitäten über eine UI abbilden zu können. Dadurch ist es nicht mehr notwendig, sich alle Befehle von Icinga for Windows zu merken oder diese zu kennen – sondern die Konfiguration erfolgt direkt darüber.

Im Zuge der Einführung der IMC, wurde ebenfalls ein neuer Setup Wizard generiert, welcher nicht nur einfacher und intuitiver ist als der alte, sondern auch noch über eine Hilfe verfügt, welche einem erklärt, welche Eingaben im jeweiligen Bereich notwendig sind und was diese bedeuten. Die Konfiguration ist hierbei im nicht-advanced Modus auf die absoluten Grundlagen beschränkt, um schnell ans Ziel zu kommen. Die restlichen Einstellungen im advanced Teil, können simpel eingesehen und geändert werden, wurden jedoch so ausgewählt, dass man in vielen Umgebungen auf eine Änderung sogar verzichten könnte.

Zentrale Verwaltung mit Repositories

Einer der großen Kritikpunkte an Icinga for Windows war die Komponenten Installation. Bisher musste jede Komponente einzeln heruntergeladen und mit einem Pfad bei der Installation hinterlegt werden. Mit Icinga for Windows v1.6.0 wurde nun ein Repository-Management hinzugefügt. Hierdurch können direkt entweder die offiziellen Repositories von Icinga for Windows auf packages.icinga.com angebunden werden oder ein eigenes, zentrales. Icinga for Windows bietet dabei die Möglichkeit, vorhandene Repositories zu synchronisieren, um diese in seiner lokalen Umgebung zu spiegeln. Dadurch kann die Installation von Systemen, welche nicht in das Internet können, deutlich vereinfacht werden. Ein Beispiel wäre hier, die offiziellen Icinga Repositories auf seinen Icinga 2 Master zu synchronisieren, um dort ein Repository für alle Systeme bereitzustellen.

Im Falle von DMZ Systemen kann das Repository wiederum von zentralen Icinga 2 Master auf Icinga Satellitensysteme synchronisiert oder aber auf zentrale File-Shares abgelegt werden, um von dort die Komponenten zu installieren. Für das Update von Repositories gibt es ebenfalls Kommandos, die eine Aktualisierung ermöglichen.

Der Vorteil des Repositories liegt darin, dass direkt die aktuellen Versionen der jeweiligen Komponenten installiert oder mit einem simplen Befehl die gesamte Umgebung aktualisiert werden kann. Sollte es aus bestimmen Gründen notwendig sein, kann die Version von einzelnen Komponenten auch gelockt werden. Das bedeutet, sofern eine ältere Version installiert ist, wird bis zur gelockten Version aktualisiert. Ist bereits die gelockte Version installiert und eine neue verfügbar, wird diese übersprungen.

Weitere Details hierzu gibt es direkt in der Icinga for Windows Repository Dokumentation.

Mehr Sicherheit durch JEA

JEA steht für Just-Enough-Administration und ist eine Lösung von Microsoft für PowerShell. Durch JEA können einzelne Benutzer, welche keine Administratoren sind, Befehle mit erhöhten Rechten im System Kontext ausführen. Die Funktionalität ist dabei ähnlich wie sudo auf Linux.

In der Vergangenheit gab es des Öfteren Probleme, das diverse Überwachungsmöglichkeiten nicht genutzt werden können, da der Benutzer beispielsweise nicht in der Hyper-V Administrator Gruppe ist und deshalb den Status der virtuellen Maschinen nicht abfragen kann. Ein weiteres Problem ergibt sich auch, wenn man diverse Services oder Tasks überwachen möchte, welchen mit einem normalen Standardbenutzer nicht eingesehen werden können.

Durch ein JEA-Profil wird es erlaubt, dass ein bestimmter Benutzer diese Plugins nun im Systemkontext mit erhöhten Rechten ausführt. Dabei wird von Icinga for Windows ein Profil basierend auf allen installierten Komponenten erstellt. Dieses Profil deckt jedoch nur die notwendigen Befehle zum Ausführen von Plugins und Komponenten ab. Für Icinga for Windows notwendigen Befehle für das Management der Umgebung, werden dabei nicht berücksichtigt.

Um das ganze abzurunden und die Trennung perfekt zu machen, bietet Icinga for Windows die Möglichkeit an, einen Managed User mit dem Namen icinga anzulegen. Dieser Benutzer ist ein lokaler Benutzer auf dem System, ohne Berechtigungen sich lokal oder per RDP anzumelden. Der einzige Zweck ist, dass er als Service Benutzer fungiert und den Icinga Agent sowie den Icinga for Windows Dienst startet. Im Zusammenspiel mit dem von Icinga for Windows generierten JEA-Profil, kann dann das System vollständig überwacht werden. Die Verwaltung des Benutzers obliegt dabei vollständig Icinga for Windows und im Rahmen der Erstellung des Benutzers oder bei diversen Änderungen an den Services während der Icinga for Windows Installation oder Updates, wird jedes Mal ein neues, zufälliges 60-stelliges Password generiert und dem Benutzer zugewiesen. Dieses Password wird nach Ende der jeweiligen Installationsschritte intern wieder verworfen und wird nirgends abgelegt. Hierdurch wird eine Kompromittierung des Systems ohne bereits vorhandene Administratorrechte deutlich erschwert.

Weitere Details sowie Anforderungen, finden sich direkt in der Icinga for Windows JEA Dokumentation.

Performance Gewinn durch API-Check Forwarder

Ein weiteres Thema welches mit Icinga for Windows v1.6.0 von experimental als stabil gilt, ist der API-Check Forwarder, welcher in vergangenen Versionen eingeführt wurde. Hintergrund dieser Lösung ist, dass das Starten sowie die Ausführung von PowerShell Befehlen innerhalb der von Icinga 2 gestarteten Shells vor allem bei Systemen mit weniger Kernen eine erhöhte Systemlast verursachen. Durch den API-Check Forwarder wird zumindest der Ausführungsteil ausgelagert, da alle Befehle für die Plugin-Ausführung innerhalb des Icinga for Windows Dienstes durchgeführt und lediglich das Ergebnis an die lokale Shell weitergereicht wird.

Für diese Lösung werden zwei zusätzliche von Icinga bereitgestellte Komponenten benötigt, um eine REST-Api bereitzustellen sowie die Checks per API auszuführen. Beides kann direkt über die neuen Icinga Repositories installiert werden. Für eine sichere Verbindung werden direkt die Zertifikate des Icinga Agent verwendet. Nach Bedarf können jedoch auch eigene Zertifikate verwendet werden. Wichtig dabei ist, dass eine Erstellung des REST-Api Sockets ohne ein TLS Zertifikat nicht möglich ist.

In der zugehörigen Dokumentation zum API-Check Forwarder von Icinga for Windows gibt es weitere Details.

Was bringt die Zukunft?

Die nächste Version von Icinga for Windows v1.7.0 ist bereits zur diesjährigen OSMC eingeplant. Hier werden wir noch weiter den Schwerpunkt auf Performance sowie eine Vielzahl von Optimierungen für Entwickler legen, um es noch einfacher zu machen eigene Plugins und Komponenten zu entwickeln. Ein entsprechender Talk ist ebenfalls eingereicht.

Wir freuen uns auf eine rege Teilnahme und wünschen bis dahin alles Gute!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Webinar am 10.02.2021: Icinga 2 kurz erklärt!

Am Mittwoch, den 10.02.2021 ist es soweit, wir bringen Euch ein Webinar zum Thema Icinga 2 Basics.

Anhand eines Walkthrough durch unsere Icinga Web 2 Demo-Oberfläche möchten wir Euch einen allgemeinen Überblick geben, was Icinga 2 für Euch tun kann. Es gibt einiges an Erweiterungen durch integrierte Module zu sehen sowie natürlich auch die richtigen Basics, die in keiner Umgebung fehlen sollten. Wir werden einen Blick werfen in das BusinessProcess Module, das vSphere Module und ins Reporting. Des Weiteren wollen wir Euch kurz Neuigkeiten zu Icinga for Windows mitgeben. Im Anschluss freuen wir uns auf Eure Fragen rund um das Thema Icinga 2, Icinga Web 2 und deren Features.

Wann und Wo

Los geht es am Mittwoch, den 10.02.2021 ab 10:30 Uhr auf dem NETWAYS Youtube Channel. Einfach rechtzeitig über diesen Link in den Stream kommen.

Wer es bis dahin nicht erwarten kann, dem empfehlen wir unsere vergangenen Webinare im Webinararchiv oder auf dem NETWAYS YouTube Channel. Dort können auch Videos der Vorträge unserer vergangenen Konferenzen abgerufen werden. Über anstehende Webinare könnt Ihr Euch immer hier informieren.

Icinga 2 Advanced Training – Last Call für angehende Icinga Expert*innen

Neues Jahr, neue Schulungen: Auch im neuen Jahr bieten wir selbstverständlich wieder Trainings für Dich an. Du möchtest Dich auch im  Jahr 2021 weiterbilden? Dann melde Dich doch zu einem unserer Schulungstermine an!

 

Wenn Du schon über Grundlagen in Icinga 2 verfügst, hast Du bereits kommende Woche die Möglichkeit, zum Genie zu werden. 😊 Die Icinga 2 Advanced-Schulung wird online stattfinden, Du kannst also ganz bequem aus dem Homeoffice teilnehmen.

 

Wann findet die Schulung statt? 19.01. – 21.01.2021

Wo findet die Schulung statt? Online

Auf welcher Sprache wird die Schulung stattfinden? Englisch

 

Diese Inhalte erwarten Dich in der Icinga 2 Advanced Schulung:

  • Einführung in das Icinga Projekt und Monitoring im Allgemeinen
  • Überblick über das Icinga 2 Setup
  • Icinga 2 REST API
  • Distributed Monitoring und Hochverfügbarkeit
  • Einblick in Icinga Web 2
  • Performance-Graphing mit Graphite
  • External Events und Log Monitoring
  • Einführung in webbasierte Konfiguration mit dem Director

 

Brauchst Du Vorkenntnisse für diese Schulung?

Dieser Kurs eignet sich für Dich, wenn Du bereits solide Monitoring-Kenntnisse und Erfahrungen mit Icinga 2 im Arbeitsalltag verfügst. Da die Schulung auf unsere Einsteiger- Icinga Schulung aufbaut, solltest Du diese bestenfalls besucht haben.

Vielleicht haben wir auch Dein Interesse geweckt und wir können uns über eine Anmeldung von Dir freuen. Mehr Informationen  der Icinga 2 Advance Schulung findest Du hier.

 

Auch wenn Du Beginner*in bist, haben wir etwas für Dich. Mehr Informationen erhältst Du hier.

 

Weitere Termine für Icinga 2 Advanced:

Online | 19.01. – 21.04.2021 (English Class)

Online | 20.04. – 22.04.2021

Online | 06.07 – 08.07.2021

Nürnberg | 30.11. – 02.12.2021

Mehr Informationen findest Du hier.

 

Kommende Schulungen:

Icinga 2 Advanced (english class) | online | 19.01. – 21.01.2021

Elastic Stack Schulung | online | 02.02. – 04.02.2021

GitLab Schulung (Fundamentals)| online | 10.02. – 11.02.2021

Terraform Schulung mit OpenStack | online | 23.02. – 24.02.2021

Puppet Schulung (Fundamentals) | online | 23.02. – 25.02.2021

 

Wir hoffen, dass etwas für Dich dabei war. Mehr Details zu all unseren Trainings findest Du hier. Wir freuen uns auf Dich!

Zurück in die Zukunft: Icinga2-Benachrichtigungen mit XMPP

Der klassische Weg um Benachrichtigung an Nutzer zu verschicken ist bei Icinga 2 (wie bei so vielen anderen Systemen auch) das Versenden einer Email. Für zeitnahe und mobilere Benachrichtigung gibt es den Versands von SMS, Sprachanrufe oder andere Optionen.

Mit dem Aufkommen und der starken Verbreitung von Chat-Diensten ist die Einbindung eines solchen Benachrichtigungsfunktion der offensichtliche nächste Schritt (oder zumindest eine tolle Spielerei). So gibt es Skripts für Slack Rocket Chat, Matrix, Telegram, selbstverständlich IRC und gerüchteweise auch Iridium. Wie man aus der Überschrift entnehmen kann geht hier es hier dann um einen weiteren Dienst, nämlich XMPP/Jabber (Jabber ist der alte Name des Protokolls).

XMPP ist ein freier Standard, erweiterbar und es gibt zahlreiche Implementierungen für Server und Clients. Der allgemeine Bekanntheitsgrad ist eher gering, obwohl der Einsatzbereich sehr groß ist. Zahlreiche größere Internetfirmen haben ihre Nachrichtenaustauschfunktionalität zu Beginn schlicht auf XMPP aufgebaut und mit freier Software umgesetzt (und dann natürlich einen „walled garden“ um die Nutzer gebaut). Die Kommunikation verläuft ähnlich wie Email, ein Client (ein Nutzer bzw. sein(e) Endgerät(e)) verbindet sich mit einem Server und übergibt diesem eine Nachricht; diese wird dann zu dem Zielserver transportiert, welcher sie dann an den Empfänger weiterleitet. Ähnlich wie bei Email ist es ein föderiertes System, prinzipiell kann jeder sich einen XMPP-Server aufsetzen und mit allen anderen reden. Dementsprechend wird ein Nutzer auch durch eine JID identifiziert, die aus einem Nutzername und einem Domänenteil in der Form nutzer@domaene.tld besteht.

Es gibt nun drei Gründe für die Benachrichtigung via XMPP:

  1. Ganz generell ist ein zweiter Kanal sinnvoll, da der erste Kanal ausfallen kann. Sollte das Mailsetup ausfallen, kann niemand darüber per Email benachrichtigt werden und natürlich wären alle weiteren Benachrichtigungen ebenfalls nicht mehr möglich.
  2. XMPP ist ein sehr mächtiges vielfältiges Protokoll und kann einen Nutzer zeitnah auf einem quasi beliebigen Endgerät erreichen (vorausgesetzt dieses Endgerät ist in irgendeiner Form online, Stichwort: PUSH-Nachrichten). Zusätzlich kann eine XMPP-Infrastruktur in einer beliebigen Größenordnung selbst betrieben werden ohne sich weitere externe Abhängigkeiten ins Haus zu holen.
  3. Der Autor dieses Artikel ist ein XMPP-Fan und würde gerne ein wenig Werbung dafür machen. Auch als Alternative zu den populären proprietären IM-Lösungen fragwürdiger Unternehmen.

Was die Umsetzung angeht, so gibt es hier schon genug Vorlagen, unter anderem diesen Artikel aus gleichem Hause, welcher das Thema zwar abdeckt, aber nach sechs Jahren doch auch ein Update verdient. Zwei Punkte bedürfen im besonderen einer Aktualisierung:

  1. Der Wechsel von Python2 auf Python3
  2. Die eingesetzte XMPP-Bibliothek hat etwas Rost angesetzt

Aus diesem Grund wurde auch diese Variante entwickelt, aber die Verwendung von Umgebungsvariablen für die Übergabe von sensiblen Daten ist im Moment bei der Verwendung des Directors nicht möglich. Zusätzlich wird die sleekxmpp-Bibliothek mittlerweile nicht mehr weiterentwickelt oder gewartet. Diese und weitere Anpassungen  wurden in diese Version  integriert um die sich dann auch dieser Artikel dreht.

Wenn man nun XMPP-Benachrichtigungen von dem eigenen Icinga 2-System erhalten möchte, benötigt man vorher schon die Möglichkeit XMPP-Nachrichten zu versenden, also mindestens einen Account bei einem Anbieter entsprechender Infrastruktur, beispielsweise einer von conversations.im oder jabber.at. Alternativ kann auch eine eigene Infrastruktur erstellt werden. Zur Installation des Skriptes müssen zuerst die Abhängigkeiten erfüllt werden, was in den meisten Fällen durch die Installation von Python3 mit Standardbibliotheken und der Bibliothek slixmpp abgeschlossen sein sollte. Dann muss das Skript selbst an einen passenden Ort kopiert werden und die Konfiguration aus dem Ordner icinga2_config in die eigene Konfiguration integriert werden. Besonders ist hier natürlich das Eintragen des Pfads zum Skript, dem|den eigenen XMPP-Account(s) (sowohl des Senders als auch des Empfängers) und des Passworts. Alternativ kann die Konfiguration auch mit dem Director erstellt werden.

Das ganze sieht dann beispielsweise in Conversations so aus:

Das Ganze ist noch recht minimalistisch und hilfreiche Ideen|Vorschläge|Kritik sind herzlich willkommen. Dann bleibt an dieser Stelle nicht viel mehr übrig als zu hoffen, dass dies hier jemandem nützt, was übrigens auch gerne mal kurz als Feedback gegeben werden kann 🙂

Lorenz Kästle
Lorenz Kästle
Consultant

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.