pixel
Seite wählen

IDO-Snap: war vorher wirklich alles besser?

von | Mrz 10, 2022 | Icinga

Kürzlich entstand im Rahmen eines Kundenprojektes ein nettes kleines Icinga-Modul, welches ich hier vorstellen möchte.

Ein Monitoring-System ist abgesehen vom Desasterfall immer dann gefragt, wenn man Änderungen an seiner IT-Umgebung vornimmt. Firmware- oder Betriebssystemupgrades, Ausrollen von Patches, Änderungen an Sicherheitsrichtlinien – es gibt ja immer was zu tun.

Von seinem Monitoring-System möchte man dann wissen, ob hinterher alles noch so schön grün ist wie vorher. Das klappt aber nur, wenn man eine überschaubare, liebevoll gehegte und gepflegte Umgebung hat.

Die Realität sieht meist ganz anders aus. Je größer die Umgebung, desto mehr Objekte sind ständig bunt. In das schöne Grün mischt sich das kritische Rot, das meist vernachlässigte Gelb der Warnings oder das nervige Lila der Objekte mit unbekanntem Zustand.

Dann hat man noch Teams, die das Monitoring zwar mit nutzen – Instrumente wie Acknowledgements und Downtimes aber nicht einsetzen. Schließlich wissen sie ja, was gerade rot sein darf. Dies erschwert dann leider die Arbeit anderer Teams, welche plattformübergreifend Änderungen an den Systemen ausrollen müssen. Woher sollen sie wissen, welche der unbestätigten Probleme nach dem Change denn vorher schon da waren? Klar, die Historie verrät es. Aber spätestens da wird die Arbeit mühsam.

In hoch automatisierten Umgebungen ist es zudem gang und gäbe, dass deprovisionierte Systeme auch automatisiert aus dem Monitoring fallen. Wie soll man dann aber noch überprüfen können, ob denn auch wirklich die richtigen verschwunden sind? Und nicht am Ende ein paar Server zu viel, für die es dann dank Automatisierung schlimmstenfalls keine Alarmierung mehr gibt?

Diese und ähnliche Fragen stellten sich auch besagtem Kunden. Als Lösung dafür konnte ein nützliches kleines Modul entwickelt werden: IDO Status Snapshots (idosnap)

Damit lässt sich jederzeit der Status sämtlicher Objekte, die von Icinga überwacht werden, sichern. Neben dem aktuellen Zustand wird auch vermerkt, ob sich das Objekt gerade in einer Downtime befand, und im Falle eines Problems, ob dieses bereits bestätigt worden ist (Acknowledgement).

Zusätzlich lässt sich das Modul so konfigurieren, dass vor jedem Deployment aus dem Director automatisch ein Snapshot erstellt wird. Und das unabhängig davon, ob dieses Deployment manuell oder automatisiert erfolgt. Denn oft bemerkt man erst im Nachhinein, dass ein vorheriger Snapshot praktisch gewesen wäre.

Weitere Details finden sich in der Dokumentation des Moduls, viel Spaß!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.
Mehr Beiträge zum Thema Icinga

ServiceNow Data Asset Import mit dem Director

Hallo Liebe Leser dieses Blogs, nach einer weile der Abwesenheit hab ich heute die Freude ihnen etwas näher bringen zu dürfen. Da viele unserer Kunden inzwischen auch ServiceNow verwenden und diese auch als Assetmanagement / CMDB verwenden. Kommt doch die Frage auf...

Modifier im Icinga-Director selbstgemacht

Ich bin sowohl als Consultant als auch als Ausbilder ein großer Fan von Hilfe zur Selbsthilfe. Der Blogpost wird also zum einen dem geneigten Leser hoffentlich helfen sich bei Bedarf seine eigenen Modifier für den Icinga-Director zu bauen, zum anderen will ich anhand...

Icinga for Windows – Performance Boost mittels REST-Api

Seit dem ersten Release von Icinga for Windows hat sich eine Menge getan, um sowohl die Funktionalitäten, die Usability als auch die Sicherheit der Lösung zu erhöhen. Ein großer Fokus lag parallel jedoch auch immer auf der Performance, was sowohl auf den Aufbau des...