Ergebnisse für " Icinga Master "

Icinga mit IcingaDB auf Ubuntu 20.04 / 22.04 installieren

von Marc Rupprecht | Jul 3, 2023 | Icinga, Monitoring & Observability

Wer nach einer Open Source Monitoring Lösung zur System- und Netzwerküberwachung sucht, kommt an Icinga (auch als Icinga 2 bekannt) nicht vorbei. Es hilft dir dabei Verfügbarkeit, Leistung und Trends der gesamten IT-Infrastruktur zu überwachen. Dank individualisierbarer Benachrichtigungseinstellungen kommen die Informationen immer genau an der gewünschten Stelle an.

Mit diesem Guide wollen wir dir dabei helfen, einen leichten Einstieg ins Icinga Monitoring zu finden und Icinga, Icinga DB und Redis erfolgreich installierst.
In diesem Guide spielt die IDO keine Rolle mehr, da diese von Icinga DB als Datenbackend abgelöst wurde. Die neue Komponente sorgt für eine bessere Performance und Skalierbarkeit von Icinga.

Voraussetzungen für die Icinga und Icinga DB Installation

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

Einen Ubuntu 20.04 / 22.04 Server mit mindestens 2 GB RAM und 20 GB freiem Speicherplatz
Der sudo – Benutzer ist auf dem Server eingerichtet und du hast das Recht, ihn zu nutzen
Zugriff auf eine SQL-Datenbank (in diesem Guide wird MariaDB verwendet)
Die aktuellste PHP-Version ist auf dem Server installiert
Eine Internetverbindung auf den Server
Optional: Ein Webserver (Apache, Nginx, etc.) ist auf dem Server installiert (als Teil des LAMP-Stack)

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 hinzufügen

Um die aktuelle Version von Icinga zu installieren, wird das offizielle Icinga-Repository zu unserem System hinzugefügt. Dazu führst du in deinem Terminal die folgenden Befehle aus:

apt update 
apt -y install apt-transport-https wget gnupg 
wget -O - https://packages.icinga.com/icinga.key | gpg --dearmor -o /usr/share/keyrings/icinga-archive-keyring.gpg
. /etc/os-release; if [ ! -z ${UBUNTU_CODENAME+x} ]; then DIST="${UBUNTU_CODENAME}"; else DIST="$(lsb_release -c| awk '{print $2}')"; fi; \
 echo "deb [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg] https://packages.icinga.com/ubuntu icinga-${DIST} main" > \
 /etc/apt/sources.list.d/${DIST}-icinga.list  
echo "deb-src [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg] https://packages.icinga.com/ubuntu icinga-${DIST} main" >> \
 /etc/apt/sources.list.d/${DIST}-icinga.list
apt update

Sobald dieser Befehlsblock erfolgreich durchgelaufen ist, siehst du in deinem Terminal, dass die neuen Repos nun in deiner Liste zu finden sind. Es sollte in etwa so aussehen:

Schritt 2: Icinga-Paket auf Ubuntu 20.04 oder Ubuntu 22.04 installieren

Da du nun Zugriff auf das Icinga-Repository hast, kannst du direkt damit weiter machen und das Icinga Paket installieren. Dafür nutzt du:

apt install -y icinga2

Dieses Paket ist die Basis der gesamten Icinga 2 Monitoring Installation. Um zu überprüfen, ob die Installation erfolgreich war, nutzt du

icinga2 daemon -C

Mithilfe dieses Befehls kannst zukünftige Konfigurationsanpassungen mit einem Terminalbefehl überprüfen.

Schritt 3: Aktivieren der Icinga API und Installieren der Monitoring Plugins

Ein Monitoringsystem ist nur so gut wie die Daten, die es sammelt und die Checks, die ausgeführt werden.
Für moderne, aus Nagios hervorgegangene Open Source Monitoring Systeme haben sich die bereits am Anfang angesprochenen Monitoring Plugins etabliert. Diese installierst du im nächsten Schritt.

Damit kannst du direkt nach Abschluss dieses Icinga Installationsguides die ersten Checks anlegen und mit deinem System Monitoring oder Netzwerk Monitoring starten. Dafür nutzt du im Terminal den folgenden Befehl:

apt install monitoring-plugins

Um die Ergebnisse der Check Plugins abzurufen oder mit Icinga zu interagieren, muss die Icinga API eingerichtet werden. Das machst du ganz einfach mit diesen beiden Befehlen:

icinga2 api setup
systemctl restart icinga2

Damit legst du in der Konfigurationsdatei /etc/icinga2/conf.d/api-users.conf einen API-User (inkl. zufallsgeneriertem Passwort) an.
(Die hier erzeugten Zugangsdaten benötigst du im weiteren Verlauf bei der Einrichtung von Icinga Web. Du wirst im entsprechenden Schritt noch einmal darauf hingewiesen!)

Falls du bestimmte Vorgaben erfüllen musst oder generell mehr über die Icinga API erfahren willst, lege ich dir entsprechende Seite in den Icinga Docs ans Herz.

Weiter geht es mit der Einrichtung von Icinga DB.

Schritt 4: Icinga DB einrichten

Icinga DB ist keine, wie der Name vielleicht vermuten lässt, eigenständige Datenbank.
Vielmehr handelt es sich hierbei um eine Sammlung von Komponenten zur Veröffentlichung, Synchronisierung und Visualisierung von Überwachungsdaten im Icinga-Ökosystem. Dazu gehören Redis, das IcingaDB-Feature des Icinga Core und der Icinga DB-Daemon.

Schritt 4.1: Redis Server installieren

Um Icinga DB zu nutzen, benötigst du einen Redis Server. Für einen reibungslosen Installations- und Konfigurationsprozess bietet das Icinga Team ein eigenes Redis-Paket an, das speziell auf Icinga zugeschnitten ist.
icindadb-redis umfasst deshalb eine aktuelle Version von Redis und kommt out of the box mit Anpassungen der Freigabe auf Port 6380 statt dem sonst für Redis üblichen Port 6379.
Das Paket installierst du mit:

apt install icingadb-redis

Hinweis: Der Redis Server kann grundsätzlich überall in deiner Icinga Umgebung installiert werden. Es ist jedoch sinnvoll, diesen auf dem zentralen Icinga-Node zu installieren, um die Latenz so niedrig wie möglich zu halten.
Ein bereits vorhandener und selbst konfigurierter Redis Server kann ebenso verwendet werden. Hier sind jedoch entsprechende Anpassungen notwendig, weshalb die Nutzung des entsprechenden Icinga-Pakets empfohlen wird.

Schritt 4.2: Aktivieren von Redis

Die Installation von icingadb-redis installiert automatisch alle systemd Dateien, die Icinga DB Redis braucht. Der Service kann also direkt aktiviert und gestartet werden:

systemctl enable --now icingadb-redis-server

Standardmäßig lauscht icingadb-redis nur auf 127.0.0.1, also deinem localhost. Wenn Icinga Web 2 oder Icinga 2 auf einer anderen Node laufen als Redis, dann muss das in der Konfigurationsdatei

/etc/icingadb-redis/icingadb-redis.conf

angepasst werden.

Auch wenn in diesem Guide alle Schritte auf einer Icinga-Node durchgeführt werden, wird die Konfigurationsdatei so angepasst, dass das Aufsetzen weiterer Nodes in der Zukunft kein Problem darstellen.
Dafür sind innerhalb der Konfigurationsdatei zwei kleine Anpassungen notwendig:

protected-mode von yes auf no
bind von 127.0.0.1 auf 0.0.0.0 –> Dadurch können alle Interfaces auf Redis zugreifen

Um die Änderungen zu aktivieren, muss der Service neu gestartet werden:

systemctl restart icingadb-redis

Damit Icinga über Icinga DB später Daten an Redis weitergibt, muss das entsprechende Feature aktiviert und Icinga anschließend neu gestartet werden:

icinga2 feature enable icingadb 
systemctl restart icinga2

Sicherheitshinweis:
Redis hat standardmäßig KEINE Authentifizierung aktiviert!
Mit der Änderung von bind auf 0.0.0.0 wird dringend, um unbefugten Zugriff zu verhindern, empfohlen, einige Sicherheitsmaßnahmen durchzuführen. Dazu gehören: Einrichten eines Passworts, Aufstellen von Firewall-Regeln oder Einrichten von TLS.
Zur einfacheren Installation wird in diesem Guide jedoch auf diese Schritte verzichtet! Diese Anpassungen lassen sich ebenfalls nachträglich durchführen.

Schritt 4.3: Installieren von Icinga DB und einrichten der Datenbank

Nachdem im gerade abgeschlossenen Schritt die Schnittstelle von Icinga 2 zu Icinga DB aktiviert wurde, wird nun Icinga DB selbst installiert:

apt-get install icingadb

Damit das gerade installierte Paket die verarbeiteten Daten auch speichern kann, muss eine Datenbank für Icinga DB angelegt und Zugriff dazu gewährt werden. (In diesem Guide wird MariaDB 10.6.12 verwendet. Die Einrichtung von MySQL ist mit den gleichen Befehlen möglich. Nutzt du PostgreSQL findest du die entsprechenden Befehle in den offiziellen Icinga Docs.)

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

Damit hast du die Datenbank und den Datenbank-Nutzer erfolgreich angelegt. Icinga DB stellt zudem ein Datenbankschema zur Verfügung, dass nun importiert wird:

mysql -u root -p icingadb </usr/share/icingadb/schema/mysql/schema.sql

Schritt 4.3: Zugriffsberechtigungen anpassen

Während der Installation von Icinga DB wird unter /etc/icingadb/config.yml eine Konfigurationsdatei angelegt, die mit Standardwerten gefüllt ist. Damit die Verbindung von Icinga DB zu Redis und MariaDB erfolgreich stattfinden kann, müssen diese Werte überprüft und gegebenenfalls angepasst werden.

Öffne also den Pfad mit einem Texteditor deiner Wahl und passe die folgenden Parameter gegebenenfalls an.

Für die Datenbank:
host mit dem entsprechenden Hostname/Host-IP deiner Datenbank, database mit dem Namen deiner Datenbank (in diesem Guide icingadb), user mit dem Namen deines Datenbanknutzers und password mit dem Passwort, dass du für deine Datenbank vergeben hast.

Für Redis:
host mit dem entsprechenden Hostname/Host-IP deiner Redis Instanz. Wenn du während der Installation deines Redis-Servers den port geändert oder ein password gesetzt hast, musst du dies hier ebenfalls eintragen.

Sobald diese Änderungen abgeschlossen sind, kann der Icinga DB Service aktiviert werden:

systemctl enable --now icingadb

Schritt 5: Icinga Node Wizard ausführen

Nachdem die Grundkomponenten für die Nutzung von Icinga installiert und konfiguriert wurden, muss noch er Node Wizard ausgeführt werden. Dieses interaktive Skript hilft dir dabei, Zonen einzustellen und die Endpunkte deines Icinga Monitoring festzulegen.

Dafür gibst du im Terminal diesen Befehl ein:

icinga2 node wizard

Da hier einige wichtige Einstellungen vorgenommen werden, hier eine Übersicht der einzelnen Punkte:

Is this agent/satellite setup? –> Hier ’n‘ eingeben und mit Enter bestätigen
Specifiy common name (FQDN of your master) –> Nichts eingeben und mit Enter bestätigen
Master zone name –> Nichts eingeben und mit Enter bestätigen
Specify additional global zones –> Nichts eingeben und mit Enter bestätigen
Specify API bind host/port –> Nichts eingeben und mit Enter bestätigen
Bind Host –> Nichts eingeben und mit Enter bestätigen
Bind Port –> Nichts eingeben und mit Enter bestätigen
Disable inclusion of conf.d directory –> Nichts eingeben und mit Enter bestätigen

Im Anschluss verifizierst du die getätigte Konfiguration und lädst Icinga 2 neu:

icinga2 daemon -C 
systemctl reload icinga2

Damit hast alle wichtigen Schritte zur Icinga und Icinga DB abgeschlossen!

Wie gehts es nun weiter?

Herzlichen Glückwunsch, du hast erfolgreich ein lokales Icinga installiert und konfiguriert! Damit könntest du nun direkt loslegen und über die Icinga2 API deine ersten Objekte anlegen, Actions triggern oder Templates bauen. Welche API-Calls dir dafür zur Verfügung stehen, kannst du übersichtlich in den Icinga Docs nachlesen.

Grundsätzlich ist die Icinga Installation nun einsatzbereit. Damit eine Open Source Monitoring Lösung wie Icinga aber produktiv genutzt werden kann, müssen die gesammelten Daten noch visualisiert werden.
Dabei helfen Icinga Web und Icinga DB Web. Wie diesen beiden Tools installiert und mit der hier aufgesetzten Basis verbunden werden erfährst du im Installationsguide zu Icinga Web und Icinga DB Web auf Ubuntu 20.04 / 22.04.

Icinga Monitoring-Satelliten – wieso sie für dich sinnvoll sind

von Christoph Niemann | Apr 11, 2023 | NETWAYS, Icinga

This entry is part 4 of 5 in the series Icinga. Einfach. Erklärt.

Eine zuverlässige und robuste IT-Infrastruktur, die den Anforderungen von Unternehmen gerecht wird, ist von entscheidender Bedeutung. Da Unternehmen wachsen und immer komplexer werden, wird es immer schwieriger, die IT-Infrastruktur effektiv zu überwachen und zu verwalten. An dieser Stelle kommen Monitoringlösungen wie Icinga ins Spiel.

Icinga ist eine Open-Source-Monitoringlösung, mit der man die Verfügbarkeit und Leistung der IT-Infrastruktur, einschließlich Servern, Anwendungen und Netzwerkgeräten überwachen kann. Mit Icinga kannst du deine Infrastruktur proaktiv überwachen und Probleme erkennen, bevor sie zu Problemen werden.

Obwohl Icinga ein leistungsstarkes Monitoringtool ist, ist die zu Grunde liegende Hardware nicht unfehlbar. Wenn es um eine große und komplexe Infrastruktur geht, kann sinnvoll sein, sich nicht auf einen einzigen Server zu verlassen. Hier kommt der Einsatz mehrerer Icinga-Satelliten ins Spiel. Diese können jeweils zu zweit in einer „Zone“ zusammengefasst werden, wobei beide Knoten die gleiche Rolle einnehmen und sich die zu erledigenden Aufgaben aufteilen.

Also, was sind die Vorteile, mehrere Icinga-Satelliten einzusetzen?

Hohe Verfügbarkeit der Monitoringumgebung

Einer der wichtigsten Vorteile für die Nutzung mehrerer Icinga-Satelliten ist die hohe Verfügbarkeit. Durch den Einsatz mehrerer Satelliten in verschiedenen Rechenzentren oder geografischen Standorten wird sichergestellt, dass die Monitoringinfrastruktur hochverfügbar ist. Wenn ein Satellit ausfällt, kann zunächst mal der zweite Knoten alle Aufgaben übernehmen.
Sollte die Verbindung zu einem Standort weg sein, werden lokale Messergebnisse zwischengespeichert. Sobald sie wieder da ist, werden sie wieder abgespielt. In der Zwischenzeit können die anderen Standorte ihre Infrastruktur weiter überwachen und bei Problemen Warnungen senden.

Diese hohe Verfügbarkeit trägt dazu bei, Ausfallzeiten zu minimieren und sicherzustellen, dass geschäftskritische Systeme verfügbar bleiben und wie vorgesehen funktionieren. Durch die Bereitstellung von Redundanz können mehrere Satelliten dazu beitragen, das Risiko eines einzelnen Ausfallpunkts zu verringern, was helfen kann, kostspielige Ausfallzeiten zu vermeiden.

Besseres Load-Balancing

Ein weiterer Vorteil des Einsatzes mehrerer Icinga-Satelliten ist Load-Balancing. Durch die Verteilung der Überwachungslast auf mehrere Satelliten kannst du sicherstellen, dass kein einzelner Monitoringknoten mit Monitoringaufgaben überlastet wird.
Durch den Lastausgleich kannst du deine Monitoringinfrastruktur auch für verschiedene Anwendungsfälle optimieren. So kannst du beispielsweise einen Satelliten für das Monitoring von Webservern und einen anderen für das Monitoring von Datenbankservern einsetzen.

Skalierbarkeit deiner Icinga-Umgebung

Wenn das Unternehmen wächst, wird die IT-Infrastruktur wahrscheinlich immer komplexer. Das Hinzufügen weiterer Server, Anwendungen und Netzwerkgeräte zur Infrastruktur kann einen einzelnen Überwachungsknoten schnell überfordern. Indem mehrere Icinga-Satelliten genutzt werden, kann die Monitoringinfrastruktur skalieren, um die erhöhte Last zu bewältigen.

Skalierbarkeit ist für Unternehmen, die schnell wachsen oder unvorhersehbare Arbeitslasten haben, von entscheidender Bedeutung. Die Möglichkeit, bei Bedarf weitere Satelliten hinzufügen zu können, stellt sicher, dass deine Monitoringinfrastruktur mit den Anforderungen des Business Schritt halten kann.

In einer finalen Ausbaustufe muss der zentrale Icinga-Knoten gar keine Monitoringaufgaben mehr übernehmen. Er kann dann konzentriert Performancedaten schreiben, die Datenbank befüllen, Config entgegennehmen und verarbeiten oder Benachrichtigungen verschicken.

Geografische Vielfalt

Durch die Platzierung von Icinga-Satelliten an verschiedenen geografischen Standorten kannst du die Verfügbarkeit und Leistung deiner IT-Infrastruktur aus verschiedenen Perspektiven überwachen. Auf diese Weise kannst du Probleme erkennen, die möglicherweise nur in bestimmten Regionen auftreten, z. B. Netzwerküberlastung oder Latenzprobleme.

Geografische Vielfalt kann auch für Unternehmen nützlich sein, die Kunden oder Betriebe in verschiedenen Teilen der Welt haben. Indem du die Infrastruktur von verschiedenen Standorten aus überwachst, kannst du sicherstellen, dass alle Dienste für Kunden unabhängig vom Standort verfügbar sind und gut funktionieren.

Hierarchie und Verschachtelung

Besonders bei großen Standorten und hoch-gesicherten Netzen bietet es sich an, Satelliten in verschiedenen Netz-Segmenten zu installieren. Beispielsweise im Produktionsnetz, im Management-Netz oder in einer DMZ.
Hierdurch lässt sich der Netzwerkverkehr zwischen den Netzwerkzonen verringern und die Firewallfreischaltungen auf das Nötigste reduzieren. Besonders praktisch ist es dabei, dass man sich aussuchen kann, ob der Satellit einen Listener-Port öffnet und auf Anfragen wartet oder sich aktiv zu seinem Upstream-Server verbindet.

Durch hierarchische Organisation der Satelliten lässt sich sicherstellen, welche Informationen wo verfügbar sind, jeder Satellit lässt sich hierbei mit einem eigenen Web-Interface und eigenen Benachrichtigungen ausstatten.
Dadurch kann jeder Standort auch im Fall eines totalen WAN-Ausfalls lokal seine Monitoring-Informationen sehen. Er sieht jedoch nicht die Informationen der anderen Standorte. An der obersten Icinga-Instanz im HQ sind alle Informationen verfügbar, da die Satelliten ihre Nachrichten hoch melden.

Mehr Infos und Hilfe

Wenn du Hilfe beim Aufbau einer komplexen Umgebung brauchst oder deinen externen Icinga-Satelliten bei NETWAYS in der Cloud betreiben möchtest, komm gerne auf uns zu und vereinbare ein Gespräch. Du kannst Icinga, egal ob als Master oder als Satellit, ganz unverbindlich einen Monat bei NETWAYS Web Services testen.

Falls Du stattdessen eine Review deiner bestehenden Icinga-Satelliten durchführen lassen willst oder bei der Einrichtung von Icinga-Satelliten Hilfe suchst, melde Dich gerne! Ich oder ein:e Kolleg:in führen gerne eine individuelle Betrachtung zu Deiner IT-Umgebung und ihren Anforderungen durch. Im Rahmen eines solchen Consultingtermins erstellen wir Dir zunächst ein Konzept und können gerne auch direkt mit der Umsetzung beginnen.

Christoph Niemann

Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Lies mehr von Christoph und triff unser Team

Icinga Installationsmethoden (und Wissenswertes zu Komponenten und Subscription)

von Dirk Götz | Mrz 23, 2023 | Icinga, Monitoring & Observability

This entry is part 2 of 5 in the series Icinga. Einfach. Erklärt.

Im ersten Teil bin ich auf die passende Plattform und die Wahl des passenden Betriebssystems eingegangen. Wenn du den ersten Teil noch nicht gelesen hast, dann solltest du das jetzt nachholen und anschließend hier weiterlesen!

In diesem Post beantworte ich nun die Frage, ob du das System eher als „Pet or Cattle“ ansehen solltest, was sich natürlich auf Installationsmethode, Management und einige weitere Aspekte auswirkt. Auch welche Icinga-Komponenten für mich ein Muss, eine nette Ergänzung oder doch eher ein Spezialfall sind, ist Teil meines Blogposts. Nebenbei beantworte ich dir hoffentlich auch die Frage, ob du dafür mittlerweile eine Icinga-Repository-Subscription brauchst oder nicht.

Wie installieren wir nun?

Bevor ich auf die Installation von Icinga eingehe, muss ich einen kleinen Exkurs einschieben und zwar zum Thema Agent. In meinen Augen gibt es kein agentenloses Monitoring, denn selbst wenn man SSH dafür her nimmt, nutzt man den eigentlichen Anmeldedienst als Monitoringagent und muss dafür etwas konfigurieren. Daher habe ich lieber einen dedizierten Agenten installiert und hier bietet die Nutzung von Icinga als Agent in meinen Augen die meisten Vorteile. Wir erhalten eine hohe Kommunikationssicherheit, Verfügbarkeit auf vielen Plattformen, einheitliche Konfiguration und keinen „Medienbruch“ durch externe Komponenten.

Daher möchte ich mit der Annahme starten, dass wir drei Arten von Installation haben. Zum einen das zentrale System, zum anderen die Agents und je nach Größe und Aufbau dazwischen noch Satelliten. Bei allen drei Varianten beantworte ich zudem die Frage, ob es sich aus meiner Sicht dabei um „Pet or Cattle“ handelt.

Auf dem Agent brauchen wir Icinga und eine gewisse Zahl Plugins für die lokalen Checks installiert. Zudem muss die Kommunikation mit dem übergeordneten System konfiguriert sein. In einer großen Umgebung wird die Zahl der Icinga-Agenten sehr schnell sehr groß und wir reden hier sicher von „Cattle“. Deshalb setzen wir hier auf ein gut konzipiertes Konfigurationsmanagement. Ich empfehle die Nutzung der offiziellen Puppet-Module oder Ansible-Collection anstatt etwas selber zu entwickeln. Wer diese Werkzeuge nicht für seine Windowssysteme nutzt, bekommt mit Icinga for Windows ein sehr gutes Hilfsmittel an die Hand.

Der Satellit dient üblicherweise nur dazu, die Last zu verteilen oder Netzwerkstrukturen abzubilden und kommt ohne Webinterface aus. Daher braucht es auch nicht viel mehr als bei einem Agent, wahrscheinlich nur kleine Anpassungen an der Konfiguration und mehr Plugins. Trotz der vermutlich überschaubaren Anzahl an Satelliten würde ich diese als „Cattle“ einordnen und wie Agents managen.

Beim zentralen System wird es dann doch etwas komplizierter. Neben den bisherigen Komponenten Icinga und den gewünschten Plugins braucht es die Datenbank als Schnittstelle und das Webfrontend für eine grafische Darstellung.
Als Freund des „Keep it simple (and) stupid“ würde ich sagen Hochverfügbarkeit nimmt uns die Virtualisierungsplattform ab, Lastverteilung bekommen durch Satelliten und Agents und die Kommunikation zwischen den verschiedenen Komponenten ist auf einem System am einfachsten und sichersten. So ein System kann aber entsprechend viel Ressourcenbedarf entwickeln und aus vielen Komponenten bestehen. Wer das vermeiden will, verteilt diese auf verschiedene Systeme und gewinnt damit die Möglichkeit, alles separat zu skalieren. Dann sind wir aber schnell weit weg von simpel! Egal wie die Umsetzung am Ende aussieht, hier haben wir ein System oder einen Verbund aus Systemen, das ich als „Pet“ betrachten würde.
Um diese Komponenten zu installieren, gibt es für mich drei valide Installationswege: manuell, semi-manuell mit dem Icinga-Installer oder auch automatisiert.

Der manuelle Weg ist für viele wohl der transparenteste und da man ja eine neue Software kennenlernt und noch nicht alle Stellschrauben kennt, auch der naheliegendste. Aber wer diesen Weg einmal beschritten hat, merkt hier schnell, dass der große Vorteil von Icinga, die Flexibilität und Integration bestehender Lösungen sich bei der Installation in einen Nachteil verwandelt. Schließlich muss ja genau jede dieser Komponenten installiert und das dafür notwendige Stellschräubchen gedreht werden.

Vollständig automatisieren ist zum Einstieg aber auch schwierig, daher stellt der Icinga-Installer von NETWAYS einen sehr guten Mittelweg dar. Vor allem verbaut man sich nicht die spätere Automatisierung. Auch gut geeignet ist der Weg als mögliche Restore-Möglichkeit oder zum einfacheren Bereitstellen von Testumgebungen. Als Puppet-Nutzer hat man sogar noch den Vorteil, dass der Installer auf genau diesen Modulen aufbaut und das Wissen bereits vorhanden ist oder ausgebaut werden kann.
Ein weiterer Vorteil des Icinga-Installers sowie der Puppet-Module, Ansible-Collection und Icinga for Windows ist, dass nach einem Update eventuell notwendige Änderung direkt vorgenommen werden. Somit wird das einfache Update über Pakete noch mal vereinfacht.

Welche Komponenten sollte mein Icinga haben?

Datenbank

Was installiere ich nun am besten auf dem zentralen System? Die erste Komponente ist natürlich die Datenbank. Hier stehe ich vor zwei wichtigen Entscheidungen. Zum einen, welches Datenbankschema ich nutzen will, den bisher verwendeten IDO oder die neue IcingaDB. Zum anderen, ob ich MySQL oder PostgreSQL als Backend einsetze. Bei einer neuen Installation würde ich ganz klar auf die IcingaDB setzen! Einzige Ausnahme wäre eine andere Komponente spielt noch nicht sauber mit. Aber auch hier wäre mein Ansatz eher über Issues diese Komponente dazu bewegen, IcingaDB zu unterstützen, also noch mit IDO zu starten. Als Backend würde ich MySQL empfehlen, was vor allem an der Verbreitung im Icinga-Umfeld liegt. Es ist einfach das häufiger genutzte und damit auch deutlich mehr getestete Backend. Wenn in Deinem Unternehmen jedoch PostgreSQL genutzt wird, gibt es aus meiner Sicht keinen Grund, hier nicht auf das gewohnte Backend zu gehen.

Frontend

Die zweite Komponente ist das Frontend, besser bekannt als Icinga Web. Hier brauchen wir neben den entsprechenden Abhängigkeiten auf alle Fälle noch das zusätzliche Modul Icinga DB Web, da wir uns für IcingaDB als Backend entschieden haben.

Alle Icinga-Komponenten die ich nachfolgend aufzähle, sind optionale Module. Dennoch will ich dir manche davon noch empfehlen.

Optionale Module

Als erste Entscheidung bei den „nicht-grundlegenden“ Modulen werfe ich die Frage nach dem Icinga Director in den Raum. Ich muss sagen, für mich ist das grafische Konfigurationstool fast schon gesetzt. Zum Warum, wieso, weshalb kommt in Kürze ein weiterer Blogpost von mir. Darum gibt es von mir hier nur den Hinweis, dass Du diese Entscheidung möglichst früh treffen solltest. Und zwar weil eine nachträgliche Migration einiges an Arbeit, aber auch Umdenken erfordert, die man sich so sparen kann.

Die erste Erweiterung, die ich persönlich als notwendig erachte, ist die Ergänzung um eine Graphing-Lösung. Ohne diese zeigt einem Icinga zwar sehr schön den aktuellen Status an, mit einem Graphing-Modul erhält der Status aber noch mal deutlich mehr Kontext. Mein Beispiel dafür ist immer die volllaufende Festplatte, bei der ich dank der Graphen leicht sehe, ob akuter Handlungsbedarf besteht oder der nächste Wartungstermin reichen wird. Ich bin zwar persönlich immer noch großer Fan der Einfachheit von Graphite, aber InfluxDB ist hier einfach die modernere Lösung und braucht auch deutlich weniger Pflege. Baut man also einen neuen Datenpool auf, empfehle ich InfluxDB und würde es sogar mit auf dem zentralen System installieren. Gibt es in Deinem Unternehmen schon eine bestehende Graphing-Lösung würde ich Icinga an diese anbinden, sodass man vielleicht später Daten korrelieren kann. Als Frontend zu den Daten ist aus meiner Sicht Grafana die erste Wahl. Das dazugehörige Modul kann problemlos in Icinga Web integriert werden.

Für weitere empfehlenswerte Erweiterungen hat man zu Beginn noch nicht genug Daten, daher empfehle ich Reporting, die Modellierung von Geschäftsprozessen oder das Cube-Modul für eine spätere Runde aufzusparen.

Heißt ich würde eher schauen, mit welcher Integration kann man vielleicht punkten oder mit welchem Eye candy Benutzer überzeugen. Hier können die Entscheidungen sehr unterschiedlich ausfallen!
Das Map-Modul hat mir schon oft freudige Anwender beschert, da plötzlich eine ganz andere Sicht auf die Umgebung gegeben ist. Auch über die vSphere-Integration hab ich schon gehört, dass diese übersichtlicher sei als die eigentlich vSphere-Oberfläche. Schau dich da also mal bei den Modulen um, meistens finden meine Kunden etwas, das sie direkt oder zumindest in einer späteren Ausbaustufe haben wollen.

Bevor wir zum letzten Themenbereich kommen, will ich auf ein Modul noch gesondert eingehen: Director-Branches, weil es nur mit der Icinga-Repository-Subscription verfügbar ist. Da es den Director erweitert, kommt es eh nur infrage, wenn Du dich für die grafische Konfiguration entschieden hast.
Bei der Erweiterung stellt sich die Frage, wie viele Editoren hat Deine Konfiguration bzw. wie viele soll sie haben. Wenn Du hier einen Nutzerkreis größer den eigentlichen Monitoringadministratoren anstrebst, ist das Modul auf alle Fälle einen Blick wert. Es erweitert den Icinga Director um Git-ähnliche Branching-Workflows und Review-Prozesse. Das erhöht zwar in gewissem Maß die Komplexität und ist somit nicht für jeden das Richtige, verhindert aber Situationen nach dem Motto „Viele Köche verderben den Brei“.

Die Frage nach der Subscription

Zum Abschluss nun noch meine Antwort auf die Frage „Brauche ich die Icinga-Repository-Subscription?“. Das ist eine sehr berechtigte Frage, zu deren Beantwortung ich hier ein paar Überlegungen mit Dir teilen will.
Wenn Dir der Community-Support reicht, suchst Du Dir die dazu passende Distribution aus, also vermutlich Debian.
Director-Branches kann jedoch für einen bestimmten Benutzerkreis hilfreich und den Preis einer Subscription wert sein. Ob Du und Dein Team dazu zählen kannst im vorangehenden Abschnitt noch mal prüfen.
Hast Du eine Umgebung, in der Du aber Red Hat Enterprise Linux oder SUSE Linux Enterprise Server überwachen möchtest und den Agenten nutzen, aber nicht selber paketieren willst, kannst Du eine Repository Subscription von Icinga erwerben.

Eine andere, aus meiner Sicht lohnendere Möglichkeit ist die Nutzung einer NETWAYS Support-Subscription, die Du auch über NETWAYS als erfahrenen Icinga-Partner bekommst.
Die Variante „Basic“ beinhaltet zum Repository-Zugriff bereits eine unlimitierte Anzahl von Support-Anfragen, allerdings mit Reaktionszeiten von 8 Stunden. Wer sich nicht solange gedulden kann oder will schaut besser auf die Variante „Premium“ mit kürzeren Reaktionszeiten und zusätzlich einem Tag Remote-Consulting für die jährliche Review der Umgebung. Für Umgebungen in denen das Monitoring eine wirklich kritische Komponente ist, gibt es noch die Variante „Enterprise“ mit Support rund um die Uhr und zwei Tagen Remote-Consulting. Wer es individueller braucht, wendet sich direkt an meine Kollegen vom Vertrieb.
Der Vorteil jeder Variante, Du hast nicht nur Zugriff auf die Software sondern immer direkt eine Ansprechperson.

Schlusswort

Im Rahmen meiner beiden Beiträge habe ich versucht, den passenden Detailgrad zu finden, sie nicht unnötig in die Länge zu ziehen, meine Empfehlungen aber nachvollziehbar darzulegen. Ob mir das gelungen ist, überlasse ich meinen Leser:innen zu beurteilen ;-). Zumindest hoffe ich meine Entscheidungen und welche Beweggründe zu diesen führen, sind für Dich nachvollziehbar und hilfreich.
Falls Du nun Interesse an Icinga gefunden hast und es auch in Deinem Unternehmen vorschlagen oder sogar einführen willst, führen ich oder ein:e Kolleg:in gerne eine individuelle Betrachtung der vorhanden IT-Umgebung durch. Im Rahmen eines solchen Consultingtermins erstellen wir gerne zunächst ein Proof of Concept. Natürlich können wir auch gleich mit der Implementierung von Icinga beginnen.

Dirk Götz

Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Lies mehr von Dirk und triff unser Team

Automate Icinga for Windows with Ansible

von Daniel Patrick | Nov 24, 2022 | IT Automation, Ansible

This article will cover how to automate the monitoring of your windows infrastructure with Ansible and Icinga for Windows. For that, I developed a new Ansible role which you can find here: https://github.com/DanOPT/ansible-role-ifw

The role will allow you to manage your infrastructure dynamically with an Inventory and group_vars file. It’s also possible to define PKI Tickets in the inventory and the support of the Self-Service API is coming soon. The parent as well as the zone of each host will be defined with the group name and their associated group variables.

The following topics will be covered:

How to organize your Windows infrastructure with an Inventory and group_vars file dynamically
Setup with On-Demand CSR Signing on the master
Setup with PKI Tickets for the client (agent or satellite) generated on the master
Coming soon

Prerequisites

This guide will not cover how to configure your Ansible host for WinRM connections. For that, there are already enough Blog Posts about that topic and the Ansible Documentation also covers it in detail (https://docs.ansible.com/ansible/latest/user_guide/windows.html).

What we will need:

Icinga2 master instance
You will need an Icinga2 master instance. I will use Ubuntu 20.04 and the Icinga Installer (https://github.com/NETWAYS/icinga-installer) to deploy the instance.
Windows host
For that, I will use a Windows Server 2012.
Ansible host
Ansible host with remote access to the Windows hosts.

How to deploy your Icinga2 master instance

Configure the Netways extra repository:

wget -O – https://packages.netways.de/netways-repo.asc | sudo apt-key add –

echo „deb https://packages.netways.de/extras/ubuntu focal main“ | sudo tee /etc/apt/sources.list.d/netways-extras-release.list

Icinga Installer requires the Puppet repository. So we will also need to configure the repository with the following commands:

wget -O – https://apt.puppetlabs.com/DEB-GPG-KEY-puppet-20250406 | sudo apt-key add –

echo „deb http://apt.puppetlabs.com focal puppet7“ | sudo tee /etc/apt/sources.list.d/puppet7.list

Install Icinga2 master instance (including IcingaWeb2 and Director):

sudo apt update

sudo apt install icinga-installer

sudo icinga-installer -S server-ido-mysql

Do not forget to write down your Password and Username.

How to organize the Windows hosts of your infrastructure with an Inventory and group_vars file dynamically

For the organization of your Windows hosts, you will need an Inventory file and a group_vars/<zone-name> file. In the group variables file, we will define the parent node name(s) as well as the parent address(es). In the Inventory it is possible to define a PKI ticket as a host variable.

So if we have a simple setup like this:

The Inventory file would look like this:

[master]

windows-2012 ansible_host=10.77.14.229
[satellite]

windows-2012-2 ansible_host=10.77.14.230

The group name will be used to define the zone name of the parent. The parent node name and address will be defined in group_vars/master and group_vars/satellite. Here is an example of the master file:

ifw_parent_nodes:
  - 'i2-master'
  #- 'i2-master-2'
ifw_parent_address:
  - '10.77.14.171'
  #- '10.77.14.172'

The variables always have to be a list, even if only one master needs to be specified.

Setup with On-Demand CSR Signing on the master

For simplification I will only use one host in my Inventory and the group_vars/masters file I already described:

[master]

windows-2012 ansible_host=10.77.14.229

The most simple way to connect agents is to sign the certificates on the master. To achieve this the agent has to be connected and after that, we can sign them. The role has already all variables required, so we just need to run the Playbook:

---
- hosts: all
  roles:
    - ansible-role-ifw

Run the playbook with the following command:

$ ansible-playbook playbook.yml -i hosts
PLAY [all] ****************************************************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ****************************************************************************************************************************************************************************************************************************************************
ok: [windows-2012]

TASK [ansible-role-ifw : Create icinga-install.ps1 using Jinja2] **********************************************************************************************************************************************************************************************************
ok: [windows-2012]

TASK [ansible-role-ifw : Execute icinga-install.ps1] **********************************************************************************************************************************************************************************************************************
skipping: [windows-2012]

PLAY RECAP ****************************************************************************************************************************************************************************************************************************************************************
windows-2012 : ok=2 changed=0 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0

After that, we can verify if a request has been made on the master with this command:

$ icinga2 ca list

Fingerprint | Timestamp | Signed | Subject

—————————————————————–|————————–|——–|——–

*****************************************************************| Nov 2 04:57:32 2022 GMT | | CN = windows-2012

Setup with PKI Tickets for the client (agent or satellite) generated on the master

It’s also possible to define a PKI ticket as a hosts variable in the Inventory (replace <pki-ticket>):

[master]

windows-2012 ansible_host=10.77.14.229 pki_ticket=<pki-ticket>

After that we need to set the variable ‚ifw_certificate_creation‘ to 1 in the Playbook:

---
- hosts: all
  vars:
    ifw_certificate_creation: 1
  roles:
    - ansible-role-ifw

Just run the Playbook and the agent should be connected to your master.

Coming soon

Self-Service API for Director
JEA Profile
Local ca.crt
Custom repository

Daniel Patrick

Systems Engineer

Daniel interessiert sich schon sein Leben lang für Linux-Distributionen, Programmieren und Technik. Im Bereich Linux konnte er bereits zwischen vier und fünf Jahre Berufserfahrung sammeln. Seit August 2022 arbeitet er für NETWAYS. Bei seinem letzten Arbeitgeber war er mitverantwortlich für das Leiten und Organisieren eines sechsköpfigen Teams, galt als Wissensträger und einer der ersten Ansprechpartner des Kunden, wenn es um technische Probleme ging. Nach der Arbeit hört er meistens auch nicht mit dem Arbeiten auf, sondern schraubt unentwegt an seinen Maschinen herum. In seiner Freizeit schaut er sich gerne gute Filme an und kümmert sich um seine zwei geliebten Katzen.

Lies mehr von Daniel und triff unser Team

Icinga: Installer, Diagnostics, Support Collector

von Alexander Stoll | Okt 6, 2022 | Icinga

Beim letzten Mal habe ich über Troubleshooting, Debugging und Performance innerhalb von Icinga for Windows geredet und heute wird das Ganze mal etwas Allgemeiner für Icinga und zwar ein paar Projekte, die dem ein oder anderen gar nicht bekannt sind, beziehungsweise deren Nützlichkeit in Hinsicht auf Informationsbeschaffung und Testen, was fürs Troubleshooting und Debugging auch nicht gerade unwichtig ist.

Icinga Installer

Zum einen wäre da der Icinga Installer, welcher eine exzellente Möglichkeit darstellt, schnell und einfach eine Icinga-Instanz zum Laufen zu bringen. Entsprechend einfach ist es auch, sich schnell mit ein oder zwei virtuellen Maschinen eine Icinga-Testumgebung zu zaubern, ohne viel Zeit in Konfigurationsdateien zu verbringen.

Hierbei bietet der Icinga-Installer unterschiedliche Installations-Szenarien an. Respektive ‘server-ido-mysql’ & ‘server-ido-pgsql’ für Icinga-Master; ‘worker’ für Icinga-Satelliten; und ‘agent’ für Icinga-Agenten.

Die Installation des Icinga-Installers ist ebenso denkbar simpel, da dieser im NETWAYS Packages Repository enthalten ist. Einfach das entsprechende Repository hinzufügen und daraufhin mit dem Paketmanager der Wahl installieren. Mehr dazu ist auch hier zu finden: https://github.com/NETWAYS/icinga-installer

Darüber hinaus kann der Installer auch im produktiven Betrieb zum Konfigurationsmanagement eingesetzt werden.

Icinga 2 diagnostics

Bei Icinga 2 diagnostics handelt es sich, um ein Bash-Script, das Daten der Umgebung sammelt und gegebenenfalls Anomalien entdeckt. Eigentlich ist das Skript zwar dafür gedacht, dass Daten gesammelt werden können, um diese mit entsprechenden Kanälen zu teilen, aber im Zweifelsfall kann es durchaus auch aufschlussreich sein, um einen simplen Fehler zu finden. Und das Skript findet ihr hier: https://github.com/Icinga/icinga2-diagnostics

Aber Vorsicht beim Teilen der Umgebungsinformationen in der Community. Immerhin enthält dieser mitunter auch Passwörter.

Support Collector

Wenn man schon Icinga 2 diagnostics erwähnt, dann kann man da genauso gut auch noch den Support Collector, welcher im eigenen NETWAYS Supports Anwendung findet, erwähnen. Dieses Projekt ist hier Zuhause: https://github.com/NETWAYS/support-collector

Genauso wie Icinga2 diagnostics ist auch der Support Collector eine gute Wahl um Konfiguration zu prüfen und erinnert vor allem den Laien daran, welche Datei dieser noch vergessen hat. Auch hier ist wieder Vorsicht geboten, die gesammelten Daten zu teilen, immerhin sind auch hier Passwörter enthalten.

Was noch?

An der Stelle ist final noch anzumerken, wie hilfreich es ist, sich Backups von Konfigurationen der Umgebung zu machen. Hierzu sollte man natürlich manuell und kontrolliert Backups anfertigen und weder Icinga2 diagnostics noch den Support Collector als Alternative betrachten, aber gelegentlich einen Abzug der Umgebung zu haben durch eines der beiden Tools ist schon praktisch. Auch der Installer kann zur Sicherung der Konfiguration und deren Wiederherstellung genutzt werden.

Es ist nicht selten der Fall, dass man glaubt, man hätte gar nichts geändert und ein diff zwischen der aktuellen zones.conf und der aus dem Support-Collector vor drei Wochen behauptet das Gegenteil.

Und eine entsprechende Testumgebung, die mit dem Icinga-Installer binnen 10 Minuten stehen könnte, gibt einen die Möglichkeit neue Konfiguration vorher an anderer Stelle als der Produktivumgebung zu testen, beziehungsweise die Möglichkeit Fehler nachzustellen und somit fehlerhafte Konfiguration zu identifizieren. Oder um es anders auszudrücken, ein Fehler ist einfacher zu beheben, wenn man klar weiß, wie er entstanden ist.

Und wenn dann der Fehler noch immer nicht gefunden ist, dann bleibt einem noch die Community oder NETWAYS Support, um dem Problem auf die Spur zu kommen.

Alexander Stoll

Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

Lies mehr von Alexander und triff unser Team