Seite wählen

NETWAYS Blog

Linux Monitoring mit Icinga – so löst du bekannte Probleme

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

Beim Betrieb von Computerinfrastrukturen treten früher oder später Probleme auf. Typischerweise schon bei der Einrichtung und später bei Änderungen, aber auch im “Normalbetrieb”. Die Ursachen dafür sind entweder extern, intern oder eine Mischung aus beidem. Zu regelmäßig auftretenden externen Ursachen zählen zum Beispiel eine Änderung des Kontextes der Maschinen, wie etwa ein Strom- und/oder Netzwerkausfall oder Updates, die etwas am äußeren Verhalten eines Programmes ändern.
Aber auch schlicht der Fortlauf der Zeit muss hier erwähnt werden. Eine tragische und unaufhaltsame Gewissheit, die durchaus technische Bedeutung hat, etwa in der Gültigkeit von Zertifikaten oder Problemen mit der Zeitsynchronisation.

Intern können Probleme durch eine bestehende Fehlkonfiguration entstehen. Dieser Begriff ist jedoch etwas Vorsicht zu genießen, da es durchaus Szenarien gibt, in denen eine bestimmte Konfiguration zum Zeitpunkt der Entstehung durchaus richtig und angemessen war. Oftmals zeigt sich erst im Verlauf von Monaten oder Jahren oder durch Änderung des Kontextes, dass die damals „richtigen“ Einstellungen problematisch sind.

An dieser Stelle tritt Monitoring auf den Plan und nimmt seinen Platz in einer gut geplanten IT-Infrastruktur ein. Enterprise-Monitoringlösungen wie Icinga versuchen bei der Voraussage, Entdeckung und Behebung von Problemen zu helfen. Um dir einen guten und vielfältigen Eindruck von den Möglichkeiten eines gut eingerichteten Monitoringtools zu geben, gehe ich in diesem Blogpost auf einige klassische und häufige Probleme, speziell im Kontext von Linux (und damit häufig auch anderen unixoiden Betriebssystemen) ein.

Im Laufe meines Beitrags werde ich regelmäßig auf die Monitoring Plugins eingehen, da diese beim Erkennen von Problemen eine wichtige Rolle spielen. Diese Zusammenstellung an Plugins ist neben Icinga auch für den Einsatz mit anderen Monitoring-Systemen geeignet, solange diese die Monitoring Plugins unterstützen.

Gängige Probleme auf Linux-Maschinen und Monitoringlösungen mit Icinga

Dateisysteme erreichen die Kapazitätsgrenzen

Ein nicht sehr häufiges (bezogen auf die Auftretenswahrscheinlichkeit), aber fatales Problem ist ganz klassisch, dass im Betrieb ein Dateisystem bis an die Kapazitätsgrenzen vollläuft. Dies führt üblicherweise dazu, dass das System seinen Betrieb ganz oder teilweise einstellt, jedoch ist das Fehlerbild potenziell auf den ersten Blick nicht offensichtlich. Beispielsweise können Programme keine großen Dateien mehr anlegen, beziehungsweise wird das Schreiben derselben abgebrochen, aber kleine, temporäre Dateien sind vielleicht (für den Moment) noch möglich.
Das führt je nach betrachteter Software und deren Fehlerbehandlung dazu, dass erst mal noch alles in Ordnung erscheint. Ein Webdienst wird weiterhin ansprechbar sein und kleine Abfragen durchaus beantworten, dann aber bei anderen (bei denen dann versucht wird größere Dateien zu schreiben) die Bearbeitung abbrechen und nur noch Fehler ausgeben, aber nicht vollständig abstürzen.

Ein anderes Beispiel ist eine Datenbank, die zwar noch lesende Zugriffe durchführen kann, aber eben keine Schreibenden. In diesen Fällen wird ein einfacher Test auf die Funktionalität des Dienstes (das init-System des Systems bescheinigt, dass der Dienst läuft; entsprechende Anfragen auf bestimmten Ports werden noch angenommen) ein positives Ergebnis bescheinigen. Trotzdem ist die eigentliche Hauptfunktionalität nicht mehr gegeben.

In einem typischen Szenario, in dem die Checks für das System lokal (oder aus der Ferne über gängige Transportwege wie SSH) ausgeführt werden, ist die klassische und gängigste Wahl beim Monitoring mit Icinga check_disk ( aus den Monitoring Plugins (Debian- und Suse-artige Distributionen) bzw. nagios-plugins (RedHat-Familie)). Zwar ist die Benutzung teilweise etwas ungewöhnlich (Stichwort Gruppierung), aber für unkomplizierte Dateisystem-Setups (und damit die häufigsten) durchaus noch ausreichend.

Ein typischer Aufruf könnte etwa so aussehen:

# ./plugins/check_disk -w 2% -c 1% \
    -X none -X tmpfs -X fuse.portal -X fuse.gvfsd-fuse \
    -X sysfs -X proc -X squashfs -X devtmpfs
DISK OK - free space: / 32892MiB (58% inode=83%); /boot 257MiB (57% inode=99%); /var 147782MiB (65% inode=92%); /home 154929MiB (34% inode=96%); /boot/efi 503MiB (98% inode=-);| /=24961351680B;61414781747;62041463193;0;62668144640 /boot=197132288B;482974105;487902412;0;492830720 /var=83065044992B;245826626519;248335061483;0;250843496448 /home=314740572160B;492755872645;497783993794;0;502812114944 /boot/efi=7340032B;524078284;529426022;0;534773760

# ./plugins/check_disk -w 2% -c 1% -N ext2 -N ext4
DISK OK - free space: / 32892MiB (58% inode=83%); /boot 257MiB (57% inode=99%); /var 147782MiB (65% inode=92%); /home 154935MiB (34% inode=96%);| /=24961351680B;61414781747;62041463193;0;62668144640 /boot=197132288B;482974105;487902412;0;492830720 /var=83065044992B;245826626519;248335061483;0;250843496448 /home=314734280704B;492755872645;497783993794;0;502812114944

In diesem Beispiel werden die Grenzwerte für Dateisysteme so gesetzt, dass der Warnzustand bei weniger als zwei Prozent freiem Speicherplatz und der Kritische bei weniger als einem Prozent auftritt. Die Sammlung an -X-Parametern (beziehungsweise das komplementäre -N) schließt diverse Dateisystemtypen aus, die nicht geprüft werden sollen. Die von mir in diesem Beispiel ausgeschlossenen Dateisystemtypen fallen nicht unter die Kategorie, die man hier im Auge hat. Hierbei handelt es sich um Dateisysteme die meine Dateien persistent auf magnetische Platten oder Halbleiterspeicher fixieren.

Alternativ können check_disk gezielt ein oder mehrere Befestigungspunkte übergeben werden:

./plugins/check_disk -w 2% -c 1% -p /home -p /boot
DISK OK - free space: /home 154935MiB (34% inode=96%); /boot 257MiB (57% inode=99%);| /home=314733232128B;492755872645;497783993794;0;502812114944 /boot=197132288B;482974105;487902412;0;492830720

Zur Feinjustierung existieren noch mehr Optionen, ein check_disk --help kann sehr hilfreich sein. Das Setzen von Grenzwerten für die Benutzung von Inodes mittels -W und -K ist leider ein viel zu häufig vergessenes Problem. Ein Mangel an freien Inodes bietet ein sehr ähnliches Bild wie eine Mangel an freiem Platz, jedoch ist es weniger offensichtlich (und tritt auch deutlich seltener auf).

Alternativen zu check_disk sind diverse andere Monitoring Plugins, wie etwa disk_usage der Linuxfabrik. Damit wird zu großen Teilen dieselbe Problematik abgedeckt. Weiterhin gibt es Plugins, die Rand- oder Sonderfälle behandeln, die außerhalb des Funktionsumfangs der klassischen Plugins liegen.
Sonderfälle dieser Art wären etwa kompliziertere Setups mit Dateisystemen mit einer größeren Menge an Funktionen wie etwas btrfs, xfs oder zfs. Hier ist eine einfache Aussage, wie die von mir bereits betrachtete “Wie viel Platz ist frei/belegt?” nicht so einfach zu treffen. Als wäre das noch nicht genug, gibt es hierbei noch die Problematik von Netzwerk- und verteilten Dateisystemen, die auch etwas komplexer ist.

TLDR

Mindestens das root-Dateisystemen sollte mit check_disk oder etwas Ähnlichem überwacht werden, als Checkintervall reichen fünf Minuten locker aus. Zusätzliche Dateisysteme für das Persistieren von Daten sollten äquivalent überwacht werden. Auch sollte überwacht werden, ob noch genügend Inodes frei sind.

Swapping

Swap-Speicher ist ein Bereich im Langzeitspeicher, der zur Auslagerung von Arbeitsspeicherinhalten dienen kann (Stichwort “Auslagerungsdatei” unter Windows). In Zeiten von sehr limitierter Arbeitsspeicherkapazität eine nützliche Funktion, um kurzfristige Kapazitätsengpässe handhaben zu können, ohne Nutzerprogrammen den angeforderten Speicher zu verweigern. Zusätzlich dient der Swap-Bereich heutzutage oft als Speicherort für Arbeitsspeicherinhalte, wenn eine Maschine in einen Ruhezustand versetzt und der (physikalische) Arbeitsspeicher ebenfalls außer Betrieb geht (Stichwort: “Hibernation”).

Diese Möglichkeiten kommen natürlich mit einem Preis. Festspeicher (“long term storage”) ist immer noch um Größenordnungen langsamer als Arbeitsspeicher (der wiederum deutlich langsamer als die
Speicher (“L*-Caches”) in der CPU ist). Die Auslagerung von aktiv genutzten Arbeitsspeicherinhalten kann dazu führen, dass ein System langsam bis an die Grenze der Benutzbarkeit gebracht wird. Das ist bei einem PC störend und frustrierend, kann jedoch bei Produktivmaschinen teilweise noch schlimmere Konsequenzen haben.
Eine Maschine, die ohnehin gerade unter Last steht, weil sie zum Beispiel sehr viele Abfragen erhält, wird, wenn das Swapping beginnt, sehr viel langsamer werden, was dann die Belastung typischerweise nicht senkt. Es sollte deshalb sichergestellt sein, dass die Nutzung von Swapspeicher (im Normalbetrieb) sowohl in Hinsicht der Quantität (Prozent an freiem/benutzten Speicher) als auch im zeitlichen Rahmen begrenzt ist.

Klassisch bietet sich hier check_swap (wiederum Monitoring Plugins|nagios-plugins) an, beispielsweise:

# ./plugins/check_swap -w 60% -c 20%
SWAP OK - 100% free (36863MB out of 36863MB) |swap=38653657088B;23192194200;7730731400;0;38653657088

In diesem Beispiel wird getestet, ob weniger als 60 Prozent des Swapspeichers frei ist (Grenzwert für WARNING) bzw. 20 Prozent (Grenzwert für CRITICAL). Eine temporär hohe Nutzung mag (je nach Szenario) durchaus erlaubt sein, aber längerfristig dürfte dies ein Problem darstellen.
Als groben Richtwert könnte man vielleicht fünfzehn Minuten anlegen, nach denen jemand alarmiert werden sollte. Das Checkintervall dürfte mit ein, zwei oder drei Minuten ausreichend bedient sein.

Wie hoch ist die Systemlast?

Ganz generell sind Systemressourcen limitiert, seien es CPU-Zeit, Speicher, andere Prozessoren und natürlich die ganzen Schnittstellen dazwischen. Manchmal lässt sich nicht oder nur schlecht an einzelnen kleinen Metriken ablesen, wenn ein Engpass besteht, zumindest wenn die Werte nur eine Teilmenge aller Werte darstellen und die wichtigen Metriken nicht enthalten sind. In unixoiden Systemen gibt es aus diesen und anderen Gründen die load-Metrik, die zwar die Details vermissen lässt, aber zuverlässig einen Indikator für ein Problem liefert.

Händisch kann die load mit dem Programm uptime (beispielsweise) abgerufen werden:

# uptime
 12:21:58 up  1:25,  1 user,  load average: 0.40, 0.38, 0.23

Die load besteht hier aus den drei Zahlenwerten 0.40,0.38 und 0.23, mit einem Aggregatswert über eine Minute, fünf Minuten und fünfzehn Minuten.

Alternativ direkt aus dem Proc-Dateisystem:

# cat /proc/loadavg
0.00 0.06 0.12 1/1316 27272

Und in “proc (5)” findet sich dann auch eine Erklärung der Zahlen.

Wer sich jetzt nicht jedes Mal die Arbeit machen will, diese Werte mit einem händisch eingegebenen Befehl aufzurufen und auszulesen, kann auf eine automatisierte Überwachung durch Check-Plugins, in diesem Fall check_load (Monitoring Plugins|nagios-plugins) setzen. Die Grenzwerte sind in diesem Fall etwas schwierig zu bestimmen, da die “zu hohe Last” stark vom Kontext abhängt.
Generell lässt sich sagen, dass eine load von eins fast der Idealwert ist, da sich damit (im Durchschnitt) immer ein Prozess in der Warteschlange befindet.

Für Werte größer als eins wird die Beurteilung schwieriger. Die Zahlenwerte aus meinem Beispiel stammen von einem Laptop ohne größere Aktivitäten (nur zwei Webbrowser). Für eine größere Maschine, etwa einen Datenbankserver mit 16 (oder mehr) CPU-Kernen, kann ein Wert von 40 auch normal sein und durchaus noch einen akzeptablen Betriebszustand darstellen. Die Option -r für check_load dividiert die load-Werte durch die Anzahl der CPU-Kerne, um eine gewisse “Normalisierung” der Werte zu erreichen, die meistens angemessen ist.

Ein angemessenes Monitoring wäre ein Checkintervall von einer bis drei Minuten mit Benachrichtigung nach fünfzehn Minuten. Als Grenzwerte wären 3,3,3 für WARNING und 5,5,5 für CRITICAL als einigermaßen konservative Einschätzung angemessen.

Ausfälle von Services (systemd) und Prozessen

In den meisten Fällen stellen Maschinen Dienste für Menschen oder andere Maschinen bereit und es ist normalerweise von gesteigertem Interesse, ob dieser Dienst auch läuft. In den meisten Linux-Distributionen ist systemd als Event- und Servicemanager im Einsatz und sollte dazu benutzt werden, durchgängig laufende Programme zu verwalten.

Mittels check_systemd lässt sich ermitteln, ob Dienste (bzw. generalisiert, systemd-units) in einem fehlerhaften Zustand sind oder nicht.

Dazu ein Beispiel mit dem SSH-Serverdienst (openssh):

# ./check_systemd.py -u ssh
SYSTEMD OK - ssh.service: active | count_units=490 data_source=cli startup_time=6.193;60;120 units_activating=8 units_active=332 units_failed=2 units_inactive=148

Im Hintergrund sind Dienste am Ende aber auch “nur” Prozesse und du möchtest potenziell diverse Eigenschaften von Prozessen überprüfen (etwa CPU-Nutzungszeit (in Prozent), oder die Größe des benutzten Speicherbereichs). Erste Anlaufstelle ist für mich check_procs.

Beispielsweise kannst du damit überprüfen, ob Zombieprozesse vorhanden sind:

# ./plugins/check_procs -s Z -w 1
PROCS OK: 0 processes with STATE = Z | procs=0;1;;0;

Ein weiterer Anwendungsfall ist die Überprüfung aller Prozesse, die mehr als zwei Prozent der CPU-Zeit verschlingen:

# ./plugins/check_procs --metric CPU -w 2
CPU WARNING: 1 warn out of 310 processes | procs=310;;;0; procs_warn=1;;;0; procs_crit=0;;;0;

Dateieigenschaften – warum Probleme auftreten können

An vielen Stellen muss überprüft werden, ob eine oder mehrere Dateien vorhanden sind und/oder bestimmte Eigenschaften aufweisen, beispielsweise ob sie älter oder jünger als ein gewisses (relatives) Datum sind, größer oder kleiner als ein Grenzwert sind oder bestimmte Berechtigungen haben. Die Ergebnisse einer solchen Überprüfung können als Indikator für ein Problem in einem Programm dienen, etwa, dass Dateien in einem Spooler-Verzeichnis nicht schnell genug abgeholt werden.

Glücklicherweise ist das ein Bereich, der sich relativ einfach durch selbstgeschriebene, auf den Nutzungsfall abgestimmte Skripte abdecken lässt. Wenn man den passenden find Befehl zusammengebaut hat, kann man nach den Monitoring Plugins Guidelines dann ein Monitoring Plugin bauen, dass den eigenen Spezialfall abdeckt.

Für etwas generellere Fälle gibt es mit check_file_age aber bereits eine Option, die zumindest das Überprüfen auf Alter und Größe erlaubt.

# ./plugins-scripts/check_file_age -f plugins-scripts/check_file_age -w 300:30000000 -c 1: -W 1:300
FILE_AGE WARNING: plugins-scripts/check_file_age is 516096 seconds old and 5193 bytes | age=516096s;300:30000000;1: size=5193B;1:300;0:;0

In diesem Beispiel sollte die Datei plugin-scripts/check_file_age älter als eine Sekunde sein (kritische Bedingung), zwischen 300 und 30000000 Sekunden alt (Bedingung für den WARNING-Zustand) und zwischen einem und 300 Bytes gross (zweite Bedingung für WARNING).

Für alle die es etwas vielfältiger mögen, wären die Monitoring Plugins der Linuxfabrik, die mit file beginnen, eine Option.

Schlusswort

Die angesprochenen Probleme sind natürlich nur ein kleiner Teil der möglichen Problemstellungen, mit denen man als Systemadministrator konfrontiert wird. Zudem habe ich mich für diesen Beitrag auch ausschließlich auf Themen innerhalb einer Maschine limitiert. Die Thematik der Netzwerkproblembehandlung hätte den Rahmen mehr als gesprengt, bietet aber ein gutes Thema für weitere Blogposts.

Ich hoffe, ich konnte anhand meiner gewählten Beispiele verdeutlichen, welche Möglichkeiten der Einsatz von Monitoringlösungen wie Icinga bietet, besonders dann, wenn du ein Unix-basiertes Rechner- oder Servernetz betreibst. Und auch wenn ich mich im Rahmen dieses Posts auf die Ausführung der Checks über die Konsole beschränkt habe, lass dich davon bitte nicht abschrecken. Natürlich können all diese Eingaben auch (bis zu einem gewissen Punkt) mit der grafischen Lösung Icinga Director und die Weboberfläche Icinga Web durchgeführt werden.

Falls du und dein Unternehmen jetzt noch Hilfe bei der Einrichtung und Konfiguration von Icinga benötigt, lass es uns einfach wissen!

In der Zwischenzeit, bleibt zu hoffen dass diese Lektüre jemandem geholfen hat und wenn (aber auch wenn nicht), dann würde sich der Autor über Kommentare freuen.

Lorenz Kästle
Lorenz Kästle
Systems Engineer

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.

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

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
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.

Icinga Director – grafische Konfiguration für alle?

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

Um dir einen reflektierten und ehrlichen Einblick in meine Entscheidungsgrundlage zu geben, gehe ich so vor, als würde ich im Consulting einen Kunden beraten und mit ihm zu einem für ihn passenden Lösungsansatz kommen. Bevor ich die jeweiligen Vor- und Nachteile von Konfigurationsdateien und der grafischen Oberfläche, dem Icinga Director, beleuchte, möchte ich als Einstieg allerdings erst über die Icinga DSL reden. Dies soll dazu dienen, dass Du meine Argumente besser verstehst und nachvollziehen kannst. Nach dem Pro und Kontra werde ich dann mein persönliches Fazit ziehen und Dir verraten, wie ich mich entscheiden würde. Das muss aber nicht der Schluss sein, zu dem Du kommst. Hier darf gerne jede:r mit seiner eigenen Gewichtung zu einem persönlichen Ergebnis kommen. Und eigentlich handelt es sich hierbei nur um ein Zwischenfazit. Denn im Anschluss möchte ich noch auf die Möglichkeiten für eine Automatisierung der Konfiguration eingehen. Und falls Du Automatisierung in Betracht ziehst, wird auch das Deine endgültige Entscheidung maßgeblich beeinflussen. Also, schauen wir uns die Möglichkeiten einmal genauer an!

Icinga DSL

Nun hab ich die Abkürzung DSL bereits zweimal verwendet ohne sie auszuschreiben! Was ich meinen Auszubildenden angekreidet hätte, will ich aber bewusst als Stilmittel verwenden. Denn tatsächlich verwendet Icinga 2 zur Konfiguration nicht eine einfache Konfigurationssprache sondern eine Domain-Specific-Language (DSL). Das Gegenstück wäre eine General-Purpose-Language (GPL) wie beispielsweise YAML. Mit einer solchen ließen sich bestimmt auch alle Monitoring-Objekte abbilden, aber die Icinga DSL erlaubt noch mehr. Dank DSL lassen sich Verzweigungen und Funktionen umsetzen und damit die Konfiguration vereinfachen, was auch die Wartung vereinfacht.

Ein Beispiel für eine Host-Definition:

object Host "localhost" {
  imports "Default Host"
  address = "127.0.0.1"
  vars.os = "Linux"
}

Was aber für mich viel wichtiger ist, ist der Ansatz dahinter. War mit Icinga 1 die Konfiguration noch sehr objekt-basierend, so dass mehr oder weniger jedes Objekt einzeln angelegt und gepflegt werden musste, ist nun die DSL für eine regel-basierte Konfiguration gedacht. Das ermöglicht es, sich Regeln für Überwachung und Benachrichtigung zu überlegen und dann die Host-Objekte mit den passenden Eigenschaften auszustatten, damit die Regeln greifen.

Ein Beispiel für eine solche Regel zur Service-Definition:

apply Service "SSH" {
  import "Default Service"
  check_command = "ssh"

  assign where host.vars.os == "Linux"
}

Auch wenn Du Dich bisher nicht eingehender mit der Icinga DSL befasst hast, kannst Du vermutlich dieses einfache Beispiel nachvollziehen und erkennen, dass für jedes System inklusive unserem „localhost“ mit dem Betriebssystem Linux nun ein Service zur Überwachung des SSH-Diensts erzeugt wird. Natürlich kann es auch durchaus komplexer werden, aber auch das wollen wir vielleicht konfigurieren. Auch für einen komplexeren Befehl möchte ich Dir ein Beispiel geben.

Zeitabhängige Schwellwerte für die Überwachung der Auslastung als Beispiel für komplexere Konfiguration:

apply Service "Load" {
  import "Agent Service"
  check_command = "load"

  vars.load_wload1 = {{
    if (get_time_period("backup").is_inside) {
      return 20
    } else {
      return 5
    }
  }}
  vars.load_cload1 = {{
    if (get_time_period("backup").is_inside) {
      return 40
    } else {
      return 10
    }
  }}

  assign where host.vars.os == "Linux"
}

In diesem Beispiel werden die Schwellwerte für die Auslastung des Systems während der für das Backup definierten Timeperiod hoch gesetzt. Dadurch werden fehlerhaft-positive Alarme vermieden, ohne die Überwachung oder Alarmierung komplett abzuschalten.

Ich hoffe diese kleine Einleitung macht deutlich, was und wie wir aufgrund der Eigenschaften der Icinga DSL konfigurieren müssen. Egal ob in Konfigurationsdateien oder mit Hilfe der grafischen Oberfläche, dem Icinga Director.

Konfigurationsdateien

Der Vorteil von Konfigurationsdateien ist oftmals der „Haben wir schon immer so gemacht“-Faktor. Zwar muss man für den Einstieg die Icinga DSL lernen, aber man kann mit gewohnten Werkzeugen, Strukturen und Arbeitsweisen an die Konfiguration von Icinga herangehen. Auch eine Versionskontrolle mittels Git oder eine Automatisierung mit Ansible oder Puppet ist einfach möglich.

Eine Zusammenarbeit an den Dateien wird schon etwas komplizierter, denn alle müssen das gleiche Verständnis der Struktur mitbringen. Sollen dabei auch noch verschiedene Rollen eingenommen werden, müssen entsprechend feine Dateirechte her oder es braucht zumindest wirklich eine Versionskontrolle und damit verbundene Reviews.

Syntax-Highlighting ist für die wichtigsten Editoren vorhanden, aber trotzdem dürfte das Hauptproblem die Fehleranfälligkeit des Menschen sein. Sowohl syntaktische als auch logische Fehler fallen erst bei der Validierung durch Icinga auf und sind gerade wenn mehrere Personen parallel Änderungen vorgenommen haben auch nicht immer leicht zu finden.

Der größte Vorteil steht dem direkt entgegen, denn ohne eine weitere Abstraktion habe ich direkten und vollen Zugriff auf alle Möglichkeiten der Icinga DSL. Somit sind zahlreiche Anpassungen möglich wie die oben gezeigten zeitabhängigen Schwellwerte, aber noch vieles mehr wie das Erzeugen von Objekten per Schleife auch über komplexe Datenstrukturen oder das Auswerten und Zusammenfassen von bestehenden Checks zu einem Gesamtergebnis. Aber auch ohne die komplexen Beispiele kann eine einfache Ergänzung, wie etwa eine Fallunterscheidung, schon Arbeitserleichterung bringen und doppelte Pflege vermeiden!

Icinga Director

Übersicht des Icinga DirectorsDer Icinga Director als grafisches Frontend zur Konfiguration stellt eine Abstraktion der Icinga DSL dar, denn es müssen natürlich für alle Objekte mit allen Attributen Eingabemasken existieren. Um das noch etwas klarer zu machen, gebe ich Dir einen kurzen Einblick in die Funktionsweise des Icinga Directors. Der Director importiert von einer Icinga-Instanz grundlegende Objekte wie Check-Kommandos, Endpunkte und Zonen. Nach diesem Kickstart musst Du für die allermeisten Objekte zunächst Templates anlegen, wobei direkt Felder für zusätzliche Eigenschaften zu erstellen und anzuhängen sind. Sobald Du auch konkrete Objekte angelegt hast, kannst Du die Konfiguration für Icinga rendern und über den entsprechenden API-Endpunkt produktiv nehmen.

Das heißt auch beim Director können Fehler erst durch die Validierung durch Icinga sichtbar werden. Aber die Eingabemasken reduzieren das Fehlerpotential stark, da Syntax-Fehler weitestgehend ausgeschlossen werden. Bei der Erstellung von Templates, Feldern und Regelwerk kannst Du durch sprechende Namen, Beschreibungen, Filter die nur passende Kombinationen erlauben sowie weitere ähnliche Maßnahmen das Risiko für logische Fehler weiter senken.

Hostansicht im Icinga DirectorsAuf der Trennung von Templates und Objekten baut auch das Rechtesystem des Directors auf, denn der Zwang zur Erstellung von Templates bereitet auch eine entsprechende Rollentrennung vor. So soll gewährleistet werden, dass ein Monitoring-Administrator ganz leicht Vorgaben machen kann und beispielsweise der Linux-Administrator anschließend einfach seine Hosts einpflegen braucht. Wer darauf geachtet hat, dem ist hier mein zögerliches Zugestehen aufgefallen. Denn ein Nachteil, den ich nicht verschweigen möchte, ist leider die Dokumentation des Directors. Alles Grundsätzliche ist in der Dokumentation durchaus enthalten. Manche Details jedoch werden erst durch Ausprobieren klar und Best Practices kristallisieren sich erst mit einiger Erfahrung heraus.

Was erklärt Dir die Dokumentation gut? Komfortfunktionen wie die, dass Du über ein Attribut den Host zu einem Icinga Agenten erklären kannst, finden sich relativ einfach. Die Erklärung, dass es uns Arbeit abnimmt, nochmal separat Endpoint- und Zonen-Objekte für jeden Host zu definieren, findet sich auch. Ebenso ein Hinweis auf die Installations- und Konfigurationshilfe, die sich hinter einem neuen Tab verbirgt. Anderes ist meines Erachtens weniger optimal dokumentiert. Wie ich Checks auf einem anderen Agenten ausführe und was es für das Feature bedeutet, ist dann außer für den erfahrenen Benutzer schwer ersichtlich. Ähnlich geht es mir auch mit anderen Features wie Choices oder Datenfeldkategorien. Diese sind sicher alle optional, dienen jedoch die Benutzerführung zu verbessern und wie bereits angemerkt Fehleranfälligkeiten zu reduzieren.

Auch wenn es nicht ganz offensichtlich ist und die Möglichkeit erst einmal einschränkend wirkt, können mit dem Icinga Director sogar bei Argumenten von Check-Kommandos komplexere Konstrukte mit der Icinga DSL eingebaut werden. Das bedeutet, dass auch das Beispiel mit zeitgesteuerten Schwellwerten möglich ist. Nur muss es halt etwas anders gelöst werden.

Erwähnt werden wollen noch die integrierte CLI und API. Solche Schnittstellen sehe ich immer als Plus. Sie ermöglichen hilfreiche zusätzliche Arbeitsweisen. Die ein oder andere schnelle Schleife über die CLI hat mir schon einiges an Klick-Arbeit gespart.

Zwischenfazit

Für meine eigene kleine Instanz wären wohl Konfigurationsdateien meine erste Wahl, denn ich bin ziemlich schnell im VIM unterwegs, kenne die Icinga DSL doch ganz gut und vor allem bin dann auch nur ich auf dem System unterwegs.

Ansonsten möchte ich Dir aber den Icinga Director ans Herz legen! Mit entsprechender Vorbereitung durch einen erfahrenen Admin oder wenn Du selbst Dir die Zeit nehmen kannst, Dich einzuarbeiten, kannst Du aus dem Director einiges rausholen. Ein großer Vorteil: Du kannst im Director die Arbeit leicht auf mehrere Personen verteilen, ohne dass alle ganz tief in die Materie einsteigen müssen. Das erlaubt es euch, leicht im Team zusammenzuarbeiten und die Abhängigkeit von einzelnen Personen zu reduzieren. Auch die Qualität des Monitorings wird in der Regel besser, wenn Administratoren das Monitoring eigenverantwortlich für ihre Systeme und Dienste pflegen können. Dazu tragen auch die erwähnten Komfortfunktionen und Möglichkeiten zum Aufhübschen bei, denn zumindest ein Umdenken erfordert der Director: Weg von der einfachen Konfiguration, die das primäre Ziel verfolgt,möglichst schnell etwas zu konfigurieren, hin zu einer möglichst übersichtlichen Konfiguration, die leicht zu verstehen und damit auch zu pflegen ist!

Nun fragt sich der eine oder die andere vielleicht, ob er oder sie mit einer Mischung aus beidem nicht die Vorteile beider Welten bekommen kann. Davon möchte ich jedoch abraten! Es ist zwar theoretisch und auch praktisch möglich, erfordert aber definitiv ein sehr tiefes Verständnis. Spätestens bei der Fehlersuche kann dies zum Verhängnis werden. Zudem schränkt es die Möglichkeiten des Directors ein, Objekte aus den Konfigurationsdateien zu verwalten. Du hast beispielsweise nicht mehr die Möglichkeit, wenn Du einen Check-Command importierst, alle Eigenschaften zu pflegen. Gerne behalte die Option im Hinterkopf und denke daran, wenn Du zum Beispiel Check-Kommandos als Konfigurationsdatei beim Plugin mitgeliefert bekommst. Aber bitte plane nicht damit! Daher auch hier meine übliche Empfehlung, dass Du Dich direkt zu Beginn für einen der beiden Wege entscheidest. So ersparst Du Dir später eine Migration und damit einhergehendes Umdenken.

Möglichkeiten der Automatisierung

Automatisierung mit Jobs im Icinga DirectorsFür mich ist schlussendlich meistens nicht entscheidend, wie einzelne Objekte konfiguriert werden können, da ich im Idealfall das Monitoring gar nicht manuell pflegen möchte. Und hier kommt eine der größten Stärken des Directors zum tragen: Der Director bietet die Möglichkeit, Daten aus einer Datenquelle zu importieren und aus diesen Daten dann Monitoring-Objekte zu erzeugen. Dabei können sogar noch Modifikatoren genutzt werden, um die Daten für den Verwendungszweck anzupassen.

Als erstes einfaches Beispiel möchte ich skizzieren, wie ein Import von Benutzern aussehen könnte. Die gleiche LDAP-Ressource, die für die Authentifizierung hergenommen wird, kann im Director als Importquelle verwendet werden. Ich gehe üblicherweise her und erstelle eine erste Import-Regel, die Gruppen importiert, und da hier meist keine Anpassungen nötig sind, kann ich sie direkt zu Usergroups für Icinga synchronisieren.Als zweites erstelle ich eine Import-Regel, die Benutzer importiert, dabei die Gruppenmitgliedschaften filtert und in ein passendes Format bringt, bevor über die Synchronisation daraus User-Objekte werden. Und schon muss ich für Benachrichtigungen nur noch benötigte Templates und die eigentlichen Benachrichtigungen pflegen. Das Management der hierfür benötigten Benutzer und ihrer Gruppen übernimmt das Active Directory, egal ob neue Kolleg:innen, Namensänderungen, Team-Wechsel oder was auch immer anstehen.

Das zweite Beispiel ist in der Praxis oftmals komplizierter. Denn um das Management der Hosts zu automatisieren, braucht es eine geeignete Quelle. Gibt es eine gut gepflegte CMDB (Configuration Management Database) oder Asset Management (oder wie auch immer es im jeweiligen Unternehmen genannt wird)? Perfekt! Eventuell stellst Du fest, dass die Datenqualität nicht so hoch ist, wie Du dies gerne hättest. Und auch hier kommen Modifikatoren zum Einsatz und schaffen Abhilfe. So können etwa alle Hostnamen zum FQDN ergänzt, die Schreibweise beispielsweise des Betriebssystems vereinheitlicht, die fehlende IP-Adresse durch DNS-Abfragen herausgefunden werden oder was sonst noch nötig ist.

Falls Daten fehlen, kannst Du sie aus einer anderen Quelle beziehen, denn viele weitere Module liefern Import-Quellen für den Director. Du kannst Dir etwa Systeminformationen aus dem Konfigurationsmanagement mit Hilfe der PuppetDB oder aus der zugrunde liegenden Plattform wie VMware vSphere oder AWS holen. Und der Vorteil ist: die Daten sind garantiert richtig! Sollten immer noch Daten fehlen, kannst Du diese mit einer eigenen Quelle anreichern. Vielleicht ist die Information schon in einem Excel-Dokument gepflegt oder Du kannst Dir schnell eine CSV-Datei bauen, denn beide Möglichkeiten bringt der Fileshipper. Letzteres nutze ich so regelmäßig, um Standortinformationen anzureichern, dass diese Option sogar als Beispiel in die Schulung Icinga 2 Advanced eingeflossen ist.

Je nachdem wie sehr man dem Automatismus dann vertraut, lässt der Director sich noch weiter automatisieren, so dass Import, Synchronisation und sogar das anschließende Deployment vollautomatisch passiert. Wer im Fehlerfall nicht nachts raus geklingelt werden möchte, kann auch gerne einstellen, dass dies nur während der Arbeitszeit passiert! 😉

Fazit

Mein Zwischenfazit hat ja bereits gezeigt, dass ich zum Director tendiere, selbst wenn es nur um manuelle Konfiguration geht. Aber auch wenn Importe natürlich individuell sind und man sich Konfigurationsdateien anders auch automatisch erstellen kann: hier trumpft der Director wirklich auf! Nicht nur der Workflow ist gut gedacht und vorbereitet, sondern durch die Möglichkeit mit weiteren spezialisierten Modulen, die Zahl der Importquellen und Modifikatoren zu erweitern. Das ist bei Bedarf sogar selbst in wenigen Zeilen zu erreichen. Damit wird der Icinga Director zum ganz klaren Sieger!

Falls Du Dir nun Hilfe bei der Einrichtung des Directors wünscht oder Unterstützung bei der Automatisierung suchst, aber auch wenn Du trotz meiner Ausführungen noch nicht entscheiden kannst, was für Dich der richtige Ansatz ist, 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.

Dirk Götz
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.

Icinga Installationsmethoden (und Wissenswertes zu Komponenten und Subscription)

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
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.

Icinga – so wählst du Plattform und Betriebssystem

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

Aus zahlreichen Kundenprojekten, die ich im Laufe meiner Zeit bei NETWAYS durchgeführt habe, haben sich für mich einige Best Practices bei der Einrichtung und Konfiguration von Icinga ergeben. Um diese state-of-the-art Icinga-Installation zu beschreiben, dachte ich mir, ich gehe hier im Blog so vor wie ich es im Consulting auch würde. Das heißt, als Erstes gehe ich auf die richtige Plattform ein also primär das Betriebssystem, aber auch ob Hardware, virtuelle Maschine oder gar Container.
Um den Rahmen nicht zu sprengen wird es einen zweiten Teil geben, in dem ich ich dann die Frage „Pet or Cattle“ beantworte, darauf eingehe, welche Icinga-Komponenten für mich einfach dazu gehören und nebenbei beantworte ich hoffentlich noch die Frage nach der Icinga-Repository-Subscription.

Hardware, virtuelle Maschine oder gar Container?

Starten wir also einmal ganz am Anfang und überlegen uns, welche Vor- und Nachteile wir von einer Hardware-Lösung hätten. Für mich gibt es hier immer noch einen großen Vorteil und zwar, dass man mit Hardware eine Icinga-Monitoring-Lösung aufbauen kann, die unabhängig von der zu überwachenden Umgebung ist. Leider ist dies in der Praxis in den meisten Fällen nicht so gegeben, wie man sich das als Consultant erhofft. Oder es ist mit viel Planung und weiteren Komponenten verbunden. Denn schon allein so etwas wie der Alarmierungsweg per Mail verkompliziert dies ungemein.
Daher überwiegen für mich in den meisten Fällen die Vorteile virtueller Maschinen und die damit verbundenen komfortablen Managementmöglichkeiten. Man muss sich nur bewusst machen, wovon dann das Monitoring abhängt, was davon vielleicht zu kompensieren ist und was einen Ausfall auslöst, der im schlimmsten Fall einen Blindflug bedeutet.
Wenn virtuelle Maschinen aus meiner Sicht die meisten Vorteile bieten, sind Container dann der nächste logische Schritt? Das Icinga-Projekt bietet auf jeden Fall eigene Container an, hat den Icinga-Prozess container-freundlich gebaut und einige Kunden laufen sehr erfolgreich mit diesem Konzept. Aber wenn ich mir die Plugin-Fähigkeit von Icinga und Modularität von Icinga Web so anschaue, so stehen diese Eigenschaften, die ich als Vorteile ansehe, dem Container-Ansatz doch etwas im Weg. Vor allem wenn dann ein Plugin durch ein Icinga-Web-Modul zur Verfügung gestellt wird, welches ohne Agent im Container nicht aufrufbar ist.

Wahl des Betriebssystems

Bei der Wahl des Betriebssystems bin ich ein großer Fan davon, auf bereits bestehendes Know-how zu setzen. Daher rate ich meinen Kunden Icinga auf der gewohnten Linux-Plattform zu installieren. Da aber jede Distribution ihre Eigenheiten sowie Vor- und Nachteile hat, müssen wir das Thema Betriebssystem etwas detaillierter betrachten. Und da sie direkt mit der Wahl der Distribution zusammenhängen, gibt es einen kleinen Exkurs in Richtung Monitoring-Plugins.

Debian-Familie

Hier ist es relativ einfach, denn für Debian und Ubuntu stellt das Icinga-Projekt Pakete frei zur Verfügung. Diese gibt es für jede bekannte Version, auch für einen ARM-Build in Raspberry Pi OS ist gesorgt.
Einzige kleine Einschränkung: Support gibt es im Falle von Ubuntu nur für LTS-Releases.
Damit Icinga nicht nur schön aussieht, sondern auch die gewünschte Überwachung liefert, werden Plugins benötigt. Monitoring-Plugins ist in der Debian-Familie die Quelle für die gleichnamigen Pakete. Hier bekommen wir eine paketierte und gut supportete Standard-Plugin-Sammlung, die zudem noch einfach zu installieren und gut gepflegt ist.
Etwas verwirrend ist der Benutzer „nagios„, der im weiteren Verlauf von den Icinga-Paketen weiterverwendet wird, die Nagios-/Icinga-1-Konfiguration, die durch die Plugins abgelegt wird, und die grobe Aufteilung auf Pakete.
Dass hier statt mit setuid mit Filesystem-Capability gearbeitet wird, finde ich persönlich sehr gut. Heißt, wir haben bei den Check Plugins Vor- und Nachteile, die aber vor allem dann eine Rolle spielen, wenn wir verschiedene Distributionen im Einsatz haben.
Einzig meine persönlichen teils negativen Erfahrungen mit Ubuntu lassen mich eher ein Debian empfehlen, Stichwort „Sonderwege“.

Red-Hat-Familie

Bei der Red-Hat-Familie wird es aus meiner Sicht komplizierter. Fangen wir mit Red Hat Enterprise Linux (RHEL) an. Hier gibt es die Pakete vom Icinga-Projekt auf Basis einer Repository-Subscription. Nachdem hier explizit auf RHEL gebaut wird, Partnerverträge bestehen etc. finde ich das ein berechtigtes Vorgehen!
Nächste in der Familie wären eigentlich CentOS Linux bzw. CentOS Stream. Ich sage hier eigentlich, denn CentOS Stream wird zukünftig nicht mehr aktiv unterstützt. Was heißt das für aktuelle Nutzer von CentOS? Es wird (Stand heute) keine Pakete für CentOS Stream 8 und 9 geben. Da es sich bei diesen Distributionen um den Upstream zu RHEL handelt, könnten theoretisch die RHEL-Pakete genutzt werden.
Leider werden auch die RHEL-Derivate Rocky Linux, AlmaLinux und Oracle Linux nicht aktiv als Icinga-Systeme unterstützt. Hier findet sich auf der Icinga-Homepage jedoch der Hinweis, dass die RHEL-Pakete bei Systemen, die zu 100-Prozent binär-kompatibel sind, genutzt werden können. Das ist zumindest bei Rocky Linux und AlmaLinux der Fall. Ob es sich dabei um eine gute Lösung für den Einzelfall handelt, muss man selbst entscheiden.
Erfreulicher sieht es dahingehend bei Amazon Linux aus. Im Rahmen der Icinga-Subscription bekommt man Zugriff auf die entsprechenden Pakete.
Alternativ kann mit Fedora auf Community-Support gesetzt werden.

Kommen wir zu den Check Plugins für Red-Hat. Hier befinden sich die Nagios-Plugins in einem zusätzlichen Repository, den „Extra Packages for Enterprise Linux“ oder im Fall von Fedora in den normalen Repos des Fedora-Projekts. Es handelt sich also um eine andere Quelle als diejenige, die bei Debian-basierten Systemen zum Einsatz kommt. Wie bei Debian wird aus „historischen Gründen“ die Gruppe „nagios“ verwendet und mit setgid gearbeitet, um Plugins höhere Rechte zu geben.
Man merkt, dass die Situation bei Red-Hat-Derivaten deutlich komplexer ist als bei Debian. Und besonders CentOS-Nutzer müssen sich aktuell nach Alternativen umsehen, was innerhalb der Community zu der einen oder anderen kritischen Stimme geführt hat.

Um der Komplexität etwas entgegenzuwirken, bauen wir bei NETWAYS wieder selbst Pakete. Unsere Buildplattform orientiert sich am Icinga-Projekt, daher bauen wir auf CentOS Linux 7, RHEL 8 und 9. Unsere Buildziele orientieren sich an unseren Kunden. Wir bauen und testen also für CentOS und RHEL, gehen von Funktion auf Rocky Linux und AlmaLinux aus, aber betrachten nicht Fedora, Oracle Linux und Amazon Linux.

SUSE-Familie

Bleibt noch SUSE Linux Enterprise Server (SLES). Diese Pakete sind ebenfalls nur für Subscription-Kunden zugänglich. Eine Alternative für alle SUSE-Fans wäre openSUSE, welches ich persönlich ebenso wie Fedora normalerweise nicht in einem Unternehmensumfeld sehe. Es soll jedoch ab 15 SP 3 zu 100-Prozent binär-kompatibel mit SLES sein, wodurch es vielleicht für den einen oder anderen in Frage kommt. Hier gibt es direkt Monitoring-Plugins über das Packagehub-Repository und da wir als NETWAYS bisher wenig Anfragen in dem Bereich hatten, bauen wir aktuell noch nicht standardmäßig für SLES.

Andere Systeme kommen nicht als Plattform für das zentrale System infrage, aber als Agent wird auch noch Windows supportet und bauen lässt sich die Software selbst auf weiteren Plattformen. Im Fall von FreeBSD und Alpine Linux werden sogar Pakete von der Community bereitgestellt.

Zusammenfassung

Welche Distribution kann ich nun empfehlen?
Debian ist sinnvoll für all diejenigen, denen der Community-Support ausreicht. Wer eh schon auf Enterprise-Support beim Betriebssystem setzt, für den lohnen sich die RHEL-Pakete, auch wenn diese mit einer Icinga-Subscription verbunden sind. Alle anderen Optionen sind auch valide, aber fühlen sich einfach nicht optimal an.
Wer eine heterogene Umgebung zu überwachen hat, findet im Icinga-Umfeld neben der Verfügbarkeit, wie man oben raus lesen konnte, ein paar kleinere Baustellen, die mit Erfahrung aber leicht zu handhaben sind. Für diese kann aber das Icinga-Projekt recht wenig, denn auch wenn man versucht hat, in der Vergangenheit in Zusammenarbeit mit allen Distributionen einen gemeinsamen Kurs zu finden, ist dies leider nicht immer gelungen.

Damit sind wir am Ende des ersten Teils meiner Vorstellung meiner persönlichen state-of-the-art Icinga-Installation. Ich hoffe Dir damit weiterhelfen zu können!
Falls Du bereits jetzt 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
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.