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.
