Services und Support rund um Open Source Monitoring Lösungen ist ein großer Teil unserer täglichen Arbeit hier bei NETWAYS. Sei es nun die Analyse einer bestehenden Umgebung, Erstellung von Konzepten oder auch die Implementierung neuer Monitoringarchitekturen. Dabei greifen wir natürlich auf unsere Addons und Plugins, aber auch die Tools der Community zurück um unsere Kunden im Open-Source-Style zu beglücken. Dabei hat sich die Art, aber vor allem auch die Stellung der Systeme in den letzten Jahre deutlich verändert.
Waren die Systeme noch vor wenigen Jahren unabhängige Insellösungen, die quasi nebenbei betrieben worden sind, sind daraus heute wichtige Infrastrukturkomponenten geworden. Die Gründe dafür sind vielfältig, aber der zunehmende Anspruch Geschäftsprozesse zu überwachen und zu reporten hat auch die Bereitschaft verändert, notwendige Ressourcen zu investieren. Neben damit einhergehenden Veränderungen im Projektablauf sind jedoch vor allem der technischen Anforderungen vollkommen andere geworden.
Heute hier, morgen dort
“Ich brauch nur schnell eine virtuelle Maschine”. Wenn ich das höre, könnte ich schon aus dem Fenster springen. Durch die Art von Anforderungsdefinition ist schon die Hälfte im hoffentlich existierenden Prozess kaputt gegangen und nur durch Glück (als ich den Satz gestern Abend gesagt habe, saß Achim daneben), landet das ganze dann noch im Monitoring. Das Gefühl für Kosten und damit einhergehendes Lifecycle-Management ist durch Virtualisierung in vielen Firmen komplett vor die Hunde gegangen. Die Aussage “Kost ja nichts”, stimmt aber leider nicht und die Meldung, dass ein System nicht mehr gebraucht erfolgt leider nur in seltenen Fällen. „Wer Zahlt das eigentlich“ schoss einem bei Bare-Metal Systemen automatisch in den Kopf, wenn man wieder nach freien HEs gesucht hat.
Solche Veränderungen haben natürlich erheblichen Einfluss auf Monitoring-Systeme, da statische Definitionsarbeit und auch Auto-Discovery die mit der Veränderung kommenden Herausforderungen nicht lösen. Zugegeben sind die Talente von Nagios und Icinga in Bezug auf Auto-Discovery ziemlich lausig. Zwar lassen sich mit einigen Addons lokale Service erkennen und identifizieren, aber was kommt dann?
Was ist mit den 10 Debian Servern und den darauf installierten DB-Servern die gerade erkannt wurden? Braucht die jemand? Wer weiß es, Wer weiß es?
Die Bewertung der fachlichen Notwendigkeit können Tools (noch) nicht übernehmen und als Konsequenz alerten die Dinger heiter vor sich hin, werden in eine ewige Downtime gesetzt oder einfach ignoriert. Die Outlook-Regel löst dann die verbliebenen Restprobleme um fehlerhafte Alarmierungen ins Nirvana zu befördern.
Automatisierung ist alles!
Der ein oder andere Leser wird vermutlich die nun kommende Puppet-Keule (natürlich will ich Euch als Kunden haben!) befürchten, aber es geht mir viel mehr um die Sache als das Tool. Wir investieren bei uns gerade viel Zeit und Energie, um Maschinen automatisch anzulegen, zu installieren, Software zu konfigurieren und dann im letzten Schritt noch die entsprechenden Monitoring regeln zu erstellen. Wir verwenden Puppet, Foreman und OpenNebula um uns den Anforderungen zu stellen, aber schon heute würden wir ohne eine Vielzahl an automatisierten Prozessen im 24×7 Betrieb arbeiten müssen um der Geschwindigkeit stand zu halten.
So wird sich auch die Konfiguration des Monitorings verändern und hoffentlich müssen in einer modernen IT-Infrastruktur in naher Zukunft keine Host- und Service-Definitions angelegt werden, sondern landen dort dann automatisch. In einigen Kunden-Umgebungen pushen wir schon heute Veränderungen aus der CMDB automatisch in LConf und exportieren die Definitionen dann wieder voll automatisch in Richtung Icinga.
Als Ergebnis wird so aus meiner Sicht aber auch die Bedeutung des Tools in naher Zukunft eher in den Hintergrund rücken und die Integration in die vorhandenen Prozesse und Automatisierung der bisher manuellen Arbeit werden über Erfolg und Misserfolg eines Projekts entscheiden. Ob dann nun Nagios oder Icinga (natürlich die mit absoluter Sicherheit bessere Wahl) verwendet wird, ist wesentlich unwichtiger als deren Steuerung und Fähigkeit sich an die dynamischen Veränderungen anzupassen. Im Team Icinga läuft die Arbeit an Icinga2 und vielen spannenden anderen Dingen auf hochtouren, damit wir genau für das gewappnet sind. Das Schwierigste dabei wird sein, dass der Bruch zur Vergangenheit nicht zu groß ist, wenn alte Zöpfe abgeschnitten werden. Nichts desto trotz, was sein muss, muss sein und zur Not gibt es ja Extensions.
0 Comments