Ergebnis sind zahlreiche Optimierungen und Erweiterungen der in den öffentlichen Repositories verfügbaren Icinga-Plugins. Ziel war und ist es dabei, die Monitoring-Qualität zu verbessern. Mit den amasol Erweiterungen werden Fehler und Probleme identifiziert und zum Teil behoben, die beim Einsatz der Standardversion überhaupt nicht auffallen. Darüber hinaus entwickelte amasol eigene Plugins.
Die nachfolgenden Beispiele vermitteln einen Überblick über das Icinga Tuning powered bei amasol.
Beispiel 1: Icinga-Agenten auf Linux-Servern
In der Praxis tritt immer wieder das Problem auf, dass Icinga-Agenten auf Linux Servern „hängen“ bleiben. Das Identifizieren und Neustarten der betroffenen Agenten war bisher ziemlich aufwändig und zeitintensiv. Ein von amasol entwickeltes Skript
- Identifiziert über die CLI-Command Console von Icinga2 die entsprechenden Agenten,
- ermittelt den dazugehörigen Servernamen und
- führt per SSH einen Neustart der Agenten durch.
All dies erfolgt ohne jegliche Nutzerinteraktion, da das Skript per cronjob (den Linux Scheduler) täglich automatisch gestartet wird und sich dann um die Agenten-Neustarts kümmert. Es werden dabei auch unterschiedliche Netzwerkzonen berücksichtigt, für die SSH-Verbindung kommen Sprungserver zum Einsatz.
Ergebnis: Die Uptime der Icinga Agenten wird erhöht, ohne dass sich jemand manuell darum kümmern muss.
Beispiel 2: Erweiterung der Icinga Anbindung an CA SOI für dynamische Alarm-Titel
Ursprünglich konnten Alarmmeldungen von Icinga an CA SOI nur einen festen String als Alarm-Titel/ -Summary enthalten, der dann als Incident-Titel verwendet wird. Dieser Titel war – unabhängig von der Priorität des Alarms – starr vorgegeben und erwies sich dadurch teilweise als nicht aussagekräftig genug.
Beispiel: Ein Service im Status „Warning“ für ein Filesystem mit Auslastung von 81% hätte als Titel „Filesystem /xy is full“ oder „Filesystem /xy is running full“
amasol erkannte das Optimierungspotenzial, wenn durch Verwendung des Outputs der Icinga-Plugins auch die tatsächlichen Messwerte in den Alarm-Titel übernommen werden. Allerdings ist dies nicht bei jedem Icinga Service möglich, da die Ausgabe einiger Plugins nicht den Ansprüchen an einen Alarmtitel entspricht. Die von amasol entwickelten Plugins sind jedoch allesamt darauf ausgelegt, eine ausführliche und nützliche Ausgabe zu liefern, die als Alarm- und Incident-Titel geeignet ist.
amasol entwickelte daraufhin einen Schalter im Icinga-Service (und somit für jeden Service individuell konfigurierbar) für ein Umschalten der Titel-Anzeige. Es wird weiterhin ein starrer und vordefinierter Alarm-Titel an CA SOI gesendet oder die erste Zeile vom Plugin-Output.
Ein weiterentwickeltes Notification-Skript verwendet bei aktiviertem Schalter die erste Zeile des Plugin-Outputs und entfernt dabei die Statusangabe („Warning: “, „WARNING - ", „Critical: ", …). Damit wird dann die bereinigte „Event Message“ an die Alarmkonsole als Alarm-Titel gesendet.
Bei allen von amasol entwickelten Plugins ist es möglich, diese Option zu aktivieren und damit – wenn vom Kunden gewünscht – stets hilfreiche und präzise Alarm-Titel zu übermitteln
Beispiel:
Filesystem utilization too high! 81% on /xy
Process ‘sapwebdisp’ of Instance ‘20‘ not running properly (GRAY)
Beispiel 3: Erweiterung der Anbindung von Icinga an CA SOI für variable CIs
Ursprünglich wurden Alarmmeldungen mit festen, im Icinga-Service konfigurierten CIs an SOI gesendet. Für verschiedene Anwendungsfälle ist dieses Konstrukt jedoch zu starr. So hat beispielsweise beim Basismonitoring von Webservern jeder Webserver auf jedem Server ein eigenes CI. Deshalb müsste für jeden Webserver auf jedem Server auch ein eigener Icinga-Service eingerichtet werden. Ein anderes Beispiel ist das SAP-Monitoring: jede SAP-Komponente hat ein eigenes CI, aufgrund der Komplexität der SAP-Umgebung würde man aber nicht jede SAP-Komponente auf einem Server einzeln über einen entsprechenden Service überwachen - und das auch noch für jeden SAP-Server.
Die benötigte Flexibilität wird erreicht, indem man das CI durch das Monitoring-Plugin auf dem Server ermitteln lässt und in der Notification als CI mitsendet.
Für solche Sonderfälle entwickelt amasol Icinga Plugins, die das CI auf dem jeweiligen Host ermitteln und es im Plugin-Output in einem vorher fest definierten Format ausgeben.
Darüber hinaus wurde das Notification-Skript und der Icinga-Service um einen weiteren Schalter erweitert, um zusätzlich das CI aus dem Plugin-Output auszulesen und dieses anstatt des im Service fest definierten CIs an CA SOI zu senden.
Beispiel (erste Zeile eines Plugin-Output):
Critical - HRP_ASCS_20@sapserver123 ### Process ‘sapwebdisp’ of Instance ‘20’ not running properly (GRAY).
Warning – EPL_AP@apacheserver123 ### Filesystem utilization too high! 83% on /var/www/docs
Erweiterung der Icinga Anbindung an CA SOI: Eigene Alarmmeldung für unterschiedliche Status-Levels (Warning vs. Critical)
Wechselt ein Service in Icinga den Status (von „Warning“ zu „Critical“ oder von „Critical“ zu „Warning“) wird dieser in CA SOI aktualisiert und ändert auch in SOI seinen Status.
Die Anbindung von CA SOI an das Incident Management System erlaubt (korrekterweise) aber keine Aktualisierung der aus den Alarmmeldungen erzeugten Incidents. Zum Problem wird, dass Alarme, für die das Operating einen Incident geöffnet hat, in CA SOI acknowledged und mit der Ticketnummer angereichert werden und damit für das Operating als abgearbeitet gelten. Eine Änderung der Kritikalität des Alarms durch eine Aktualisierung durch Icinga fällt nicht mehr auf. Ein plötzlich kritischer Zustand bleibt damit unerkannt.
amasol hat nun die Icinga-Services und das Notification-Skript um einen Schalter erweitert, der steuert, ob für jede Kritikalität ein eigenständiger Alarm in CA SOI erzeugt wird und damit – wenn sich die Kritikalität in Icinga verändert - ein zusätzlicher Alarm in der Alarmkonsole entsteht, der für das Operating sichtbar ist und deshalb auch bearbeitet werden kann.
Custom-Plugins (basierend auf eigenem Framework für Bash-basierte Plugins)
Wie eingangs erwähnt hat amasol eine ganze Reihe von eigenen Plugins für Icinga entwickelt, die unter Linux, AIX, HP-UX und SunOS lauffähig sind. Bei allen diesen Plugins wurde der Plugin-Output mit System-/ Meta-Informationen angereichert.
Alle Plugins können per Flag-Dateien in einen „Maintenance“-Mode versetzt werden (weiterhin aktive Überwachung, aber deaktivierte Alarmierung/ Notification). Darüber hinaus können Alarmmeldungen per Schalter für niedrige Stages (z.B. Stage „Test“) deaktiviert werden. Dies ist unabhängig davon möglich, wo der Service läuft: das Plugin kümmert sich darum.
Die Plugins sind „Cluster-aware“ d.h. es erfolgt keine Alarmierung auf inaktiven Cluster-Nodes.
Außerdem erfolgt ein Überwachen aufgerufener Programme (z.B. df) und „Killen“ der hängenden Prozesse (außer per sudo gestartete Prozesse) nach Erreichen eines konfigurierbaren Timeouts. Damit wird sichergestellt, dass der Timeout der Icinga-Services keine Prozesse (orphans) auf dem System zurücklässt und nach gewisser Zeit das System seiner Ressourcen beraubt. Über hängende Prozesse, die per sudo gestartet wurden, wird informiert
Beispiele:
- SAP-Plugin (über 4000 Zeilen)
- config-basiertes Filesystem-Monitoring-Plugin (nur Filesysteme, die auf dem Server tatsächlich existieren, werden gemäß Schwellwerte und Filterkriterien (wie Stage und Meta-Flags) aus der config überwacht)
- ulimit-Überwachung (nproc und nofile) für vorgegebene User
- Pacemaker-Cluster-Monitoring
Falls Sie an weiteren Informationen zu den amasol Icinga-Entwicklungs- und Optimierungsarbeiten interessiert sind, wenden Sie sich bitte an Ihren Ansprechpartner bei amasol.