pixel
Select Page

NETWAYS Blog

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 des Beispiels auch beleuchten was ich so unter Hilfe zu Selbsthilfe verstehe. Daher will ich etwas weiter ausholen bevor der erste Code-Schnipsel kommt, wer also schon weiß was Modifier sind, wie man sie nutzt und warum man vielleicht Bedarf nach einem eigenen hat, darf gerne die Einleitung überspringen.

Modifier im Director ermöglichen es Daten aus der Import-Quelle anzupassen oder auch anzureichern, sprich es erlaubt der Monitoring-Administration auszubügeln was in der Datenquelle nicht passt oder auch einfach nicht für das geplante Regelwerk in Icinga 2 geeignet ist. Einfache Stringoperationen ermöglichen es bereits aus Hostnamen einen FQDN zu machen oder diesen aus möglicherweise getrenntem Hostnamen und Domäne zu kombinieren, komplexere Modifier machen beispielsweise einen DNS-Lookup um Icinga 2 zur Laufzeit vom DNS unabhängig zu machen. Bereits an den Beispielen sieht man hoffentlich, wie hilfreich diese Optionen sein können, und wenn damit dann Icinga 2 voll automatisiert mit Tausenden von Hosts befüllt wird, wird hoffentlich klar wie kritisch die Funktion ist. Nun gibt es natürlich trotzdem Bugs, einen hat Tom mit dem Release 1.9.1 gefixt und zwar dass bei Stringoperationen aus NULL-Werten ein leerer String wurde. Nachdem dieses Verhalten nun bereits länger so war, hat vielleicht der ein oder andere sich darauf verlassen, so dass es nun statt eines lang ersehnten Bug-Fix wie für mich, für diese Nutzer wie ein Bug erscheinen mag. Der Supportkunde der nun bei Patrick aufgeschlagen war, da dieser gerade wieder im Rahmen der Ausbildung das Operations-Team verstärkt, hatte zum Glück Verständnis für den Bug-Fix, aber trotzdem war nun sein Workflow kaputt. Als ein Beispiel wurde genannt, dass sie aktuell einen DNS-Lookup als Modifier nutzen, der gegebenenfalls wenn ein Name nicht auflösbar ist einen NULL-Wert zurückgibt, im nächsten Schritt wurde daraus ein leerer String und dann wurde der leere String durch einen regulären Ausdruck zum String “Unknown”. Von Patrick um eine kurze Einschätzung gebeten, sagte ich ihm er soll mal schauen ob der Modifier statt einem NULL-Wert direkt einen leeren String zurückgeben kann oder ein anderer Modifier genutzt werden kann um NULL-Werte zu befüllen. Nachdem diese Suche erfolglos geblieben war, hat er das Ticket in Richtung Icinga eskaliert, da das Kundenproblem nicht ohne Software-Änderung zu lösen war.

Nun hätten wir es darauf beruhen lassen können, da ich aber bei meinen Auszubildenden den Drang fördere, eine Lösung zu suchen statt das Problem nur jemand anders zuzuschieben und Patrick auch von Natur aus nicht zufrieden ist wenn er ungelöste Probleme vor sich hat, kam er erneut auf mich zu. Mit meiner Antwort, dass so ein Modifier in etwa 10 Minuten geschrieben sei, und dass er dies doch übernehmen könne, war er natürlich nicht ganz zufrieden bis ich ihm dafür meine Unterstützung angeboten habe. Da ich hier schon entsprechendes beigetragen habe, konnte ich ihm direkt sagen was zu tun ist und es kam dabei der Commit 4692b28 für den Director heraus. Dieser fügt einen Modifier hinzu der es erlaubt NULL-Werte direkt durch einen angegebenen String zu ersetzen, heißt der Kunde kann wieder seinen Workflow bauen und dieser dürfte sogar einfacher sein.

Modifier: Replace null value with String

Wenn man sich den Commit nun anschaut sind es nur zwei veränderte Dateien, zum einen der neu erstellte Modifier und zum anderen ist eine Registrierung notwendig. Der Modifier selbst besteht quasi aus einem Rumpf aus Namespace, verwendeten Klassen und seiner eigenen Klasse als Implementierung der Basisklasse sowie drei Funktionen in der Datei library/Director/PropertyModifier/PropertyModifierReplaceNull.php. Die Funktion getName() erlaubt es eine Beschreibung für das Auswahlfeld der Modifier zurückzugeben, addSettingsFormFields(QuickForm $form) erlaubt es zusätzliche, für den Modifier benötigte Eingabefelder zu definieren und transform($value) ist dann die eigentliche Modifikation, also bei einem NULL-Wert den eingegebenen String zurückzugeben ansonsten den ursprünglichen Wert. Entstanden ist das Ganze durch Kopieren und Anpassen eines ähnlichen Modifiers in 5 Minuten Arbeitszeit und 30 Minuten Erklärung.

<?php

namespace Icinga\Module\Director\PropertyModifier;

use Icinga\Module\Director\Hook\PropertyModifierHook;
use Icinga\Module\Director\Web\Form\QuickForm;

class PropertyModifierReplaceNull extends PropertyModifierHook
{

    public function getName()
    {
        return 'Replace null value with String';
    }

    public static function addSettingsFormFields(QuickForm $form)
    {
        $form->addElement('text', 'string', array(
            'label'       => 'Replacement String',
            'description' => $form->translate('Your replacement string'),
            'required'    => true,
        ));
    }

    public function transform($value)
    {
        if ($value === null) {
            return $this->getSetting('string');
        } else {
	    return $value;
	}  
    }
}

Zusätzlich muss der Modifier noch in register-hooks.php registriert werden, dazu benötigt es zwei Einträge. Zum einen muss der Modifier an sich bekannt gemacht werden und zum anderen dann noch als Umsetzung des Hook angeboten werden was der Director über eine Iteration durch ein mehrdimensionales Array löst, so dass der Modifier nur an entsprechender Stelle dem Array hinzugefügt werden muss. Dabei der Ordnung halber an die alphabetische Reihe gehalten und schon ist es auch hübsch. Dafür nehmen wir mal 1 Minute Arbeitszeit und 5 Minuten erklären an.

...
use Icinga\Module\Director\PropertyModifier\PropertyModifierReplaceNull;
...
        PropertyModifierReplaceNull::class,
...

Noch mal den Git-Workflow erklärt, den Commit in Patrick’s Fork gepusht, auf seinem Testsystem ausgecheckt, getestet und für gut befunden, Pull-Request erstellt, macht weitere 5 Minuten Arbeitszeit und 5 Minuten Erklärung, wobei ich mir diese hier spare und stattdessen auf einen älteren Blogpost verweise, den zusammen mit Kollegen geschrieben hatte. In Summe macht das in etwa eine Stunde aufgewandte Zeit, aber ich habe nun einen Auszubildenden, der beim nächsten Mal ein ähnliches Problem besser verstehen wird, es direkt lösen kann und als Bonus neben dem Erfolgserlebnis auch als Contributor beim Director auftaucht. Patrick hat sein Wissen erweitert, den Icinga-Kollegen Arbeit abgenommen und dem Kunden ohne lange Wartezeit eine Lösung geliefert, von der auch andere zukünftig profitieren werden. Beim nächsten Mal sind es dann vermutlich wirklich 10 Minuten Arbeit für Patrick! 😉

Was aber nun wenn man einen so speziellen Modifier benötigt, dass es keinen Sinn macht diesen dem Director und damit der Allgemeinheit zur Verfügung zu stellen? Durch den modularen Aufbau von Icinga Web 2 lassen sich Modifier als Hook auch aus einem eigenen Modul anbieten. Heißt wenn der Modifier speziell für eine bestimmte Import-Quelle benötigt wird, kann der Modifier im gleichen Modul eingebaut werden. Ist er dagegen nur für die eigene Umgebung relevant kann man ihn in ein separates Modul packen oder vielleicht mit in das Modul für das Theme des Unternehmens. Dafür müssten nur ein paar Kleinigkeiten angepasst werden. Der Modifier wäre dann im Modul an der Stelle library/MODULENAME/ProvidedHook/Director/PropertyModifier/ abzulegen, dementsprechend wäre der Namespace Icinga\Module\MODULENAME\ProvidedHook\Director\PropertyModifier und statt einer register-hooks.php erstellt man eine run.php mit folgendem Inhalt:

<?php

use Icinga\Module\MODULENAME\ProvidedHook\Director\PropertyModifier\PropertyModifierMODIFIERNAME;

$this->provideHook('director/PropertyModifier', PropertyModifierMODIFIERNAME::class);

Ich hoffe das Beispiel und die Erklärungen helfen demjenigen, der einen eigenen Modifier braucht, und ich konnte auch zeigen warum ich so ein großer Fan von Hilfe zur Selbsthilfe bin. Wer noch gar nichts mit den Import-Möglichkeiten des Directors anfangen kann, ist in der überarbeiteten Schulung Icinga 2 Advanced willkommen. Das Kapitel zu Import kommt aus meiner Feder und erklärt ausführlich und anhand von Übungen wie man Daten mittels SQL aus einer Datenbank importiert und mit dem Inhalt einer CSV-Datei ergänzt um Hosts anzulegen und aus einem LDAP-Verzeichnisdienst Benutzer und Gruppen zieht. Wer dagegen jemanden kennt, der ein bisschen Hilfe zur Selbsthilfe bekommen will, wir haben noch Ausbildungsplätze bei uns im Professional Services frei! Ich verspreche aber auch allen anderen Kollegen zu helfen, wenn sich jemand für eine der anderen Stellen interessiert! 😉

Das Beitragsbild kombiniert den Director von rones auf Openclipart mit dem Icinga-Logo.

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 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 Icinga Agenten als auch der PowerShell oder generell der Plugins zurückzuführen ist.

Warum ist die Performance “schlecht”?

Der große flexible Ansatz von Icinga erlaubt es, beliebige Plugins in einer Vielzahl von Programmier- oder Skriptsprachen auszuführen – unter anderem auch PowerShell. Das bedeutet jedoch, dass Icinga sich keine Libraries, Inhalte oder sonstigen Informationen merkt. Stattdessen ist – im Beispiel von PowerShell – für jeden einzelnen Aufruf eine PowerShell zu starten. Hierfür müssten dann zuerst die notwendigen Bibliotheken geladen werden und gegebenenfalls umgebungsspezifische Informationen.

Zu guter letzt muss dann noch Icinga for Windows geladen werden, also das Framework und die Plugins, welche wir ausführen wollen. Das kostet nicht nur Zeit, sondern auch CPU-Ressourcen. Bis zu diesem Punkt haben wir aber auch das Plugin noch nicht ausgeführt – je nach Plugin, kommen dann noch WMI Handler und sonstige Themen hinzu, welche das Plugin abfragen und laden muss, bis man schließlich sein Ergebnis erhält.

Gibt es Lösungsansätze für dieses Problem?

Über paar Jahre in welchen Icinga for Windows entwickelt wurde, gab es mehrschichtige Ansätze, um die Performance zu verbessern. Zum einen wird von Icinga for Windows ein Cache-File für alle Komponenten des Frameworks angelegt und als “ein großes Modul” geladen. Dadurch entfallen Lade- und CPU-Zeiten für das Einbinden von Sub-Modulen oder Skripten.

Der größte und wichtigste Ansatz ist jedoch die Nutzung des Icinga for Windows Service. Dieses kleine Service Binary erlaubt es, eine PowerShell im Hintergrund über die Windows Dienste zu starten und zu verwalten. Dadurch können über das Icinga PowerShell Framework dann sogenannte Background Daemons registriert werden, welche im Hintergrund Ihren Dienst verrichten.

Einer dieser Background Daemons, welche normalerweise als separate Komponenten installiert werden, ist in den letzten Versionen direkt in das Icinga PowerShell Framework eingezogen: Die REST-Api

Eine REST-Api für Plugin Ausführung

Mittels der REST-Api und einer entsprechenden Funktion im Icinga PowerShell Framework können Plugin-Ausführungen über die REST-Api innerhalb des Icinga for Windows Dienstes ausgeführt werden. Das hat mehrere Vorteile, da man zum einen andere Wege finden könnte, seine Plugins auszuführen, zum anderen aber die Last von Icinga for Windows komplett anders verteilt wird.

Zwar startet der Icinga Agent im Standardverhalten zwar weiterhin eine PowerShell, diese führt aber den eigentlichen Plugin Code nicht mehr aus, sondern prüft, ob die REST-Api sowie das entsprechende Feature aktiviert sind. Falls ja, wird ein Versuch gestartet, den Plugin Aufruf über die REST-Api einzustellen. Das bedeutet, dass innerhalb der Daemons und der REST-Api zwar auch Bibliotheken geladen werden müssen, diese aber persistent verfügbar und beim erneuten Aufruf des Plugins bereits vorhanden sind. Das bringt nicht nur einen Performance-Boost für die Ausführungszeit, sondern reduziert auch die CPU last deutlich.

Am Ende wird nur das Ergebnis zurückgegeben, von unserem Plugin-Handler ausgewertet und an den Icinga Agent weitergereicht. Sollte in diesem Prozess etwas schief gehen, gibt es immer noch den Fallback auf die automatische lokale Ausführung. Im EventLog von Icinga for Windows sind dann einige Details zu finden: Ob es ein Fehler bei der Ausführung des Plugins war oder ob die Ausführung zu lange gedauert hat und deshalb auf lokale Ausführung zurückgegriffen wurde.

Kann man dieses Feature einfach aktivieren?

Ja! Die einzigen Voraussetzungen für dieses Feature sind das Icinga for Windows Service Binary und der installierte Icinga Agent mit einem Zertifikat, das von der Icinga CA signiert wurde. Anschließend kann man das Feature über die IMC einfach aktivieren. Da wir nur einen HTTPS Socket anbieten, der per Default auf localhost läuft, ist weder eine externe Kommunikation möglich noch eine Nutzung der REST-Api ohne TLS.

Zuerst müssten wir den Icinga for Windows Service installieren, sofern nicht vorhanden:

Install-IcingaComponent -Name ‘service’ -Confirm;

Anschließend öffnen wir die Icinga Management Console mittels dem Befehl icinga in einer administrativen PowerShell und navigieren zu folgenden Punkten:

* [2] Settings
* [6] Icinga for Windows Features
* [0] Api-Check Forwarder

Mittels der IMC kann das Api-Check Forwarder Feature dann einfach aktiviert oder deaktiviert werden. Der jeweilige Status ist direkt neben dem Eintrag zu finden. Wenn alles aktiviert ist, starten wir zur Sicherheit noch den Icinga Agent sowie Icinga for Windows Dienst neu und alles sollte funktionieren!

Restart-Service -Name ‘icinga2’;
Restart-IcingaWindowsService;

Und jetzt?

Wenn die Ausführungszeit der Plugins von Icinga Seite schneller und die Last auf dem System reduziert ist, sollte alles funktionieren. Natürlich kann man jetzt noch das EventLog parallel beobachten, während man Checks ausführt, ob im Icinga for Windows EventLog Probleme auftreten:

Read-IcingaForWindowsLog;

Sofern Fragen hierzu sind, es Probleme gibt oder wir bei der Einrichtung helfen können, freuen wir uns natürlich über eure Kontaktaufnahme!

Viel Spaß mit Icinga for Windows und der neu gewonnenen Performance!

Christian Stein
Christian Stein
Lead Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

IDO-Snap: war vorher wirklich alles besser?

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.

Offizielle Icinga Pakete für RHEL, SuSe und Amazon Linux 2

Icinga stellt für viele Betriebssysteme fertige Builds auf der Icinga Download Seite bereit. Darüber hinaus hat Icinga eine tolle Community, die Icinga für weitere Umgebungen baut.

Um auch für Enterprise Linux Distributionen weiterhin zuverlässige Icinga Installationen möglich zu machen, hat Icinga für Red Hat Enterprise Linux (RHEL), Amazon Linux 2 und SUSE Linux Enterprise Server (SLES) eigene Pakete veröffentlicht. Diese speziellen Builds werden über ein Subscription Modell angeboten, die Community Pakete und die Icinga Builds für die weiteren Linux Distributionen bleiben frei verfügbar.

Wie komme ich an die Subscription?

Ihr könnt euch hier direkt an uns wenden, wir als Icinga Partner bieten die Subscription gerne an. Diese enthält den Zugriff auf alle Enterprise Pakete, es reicht also eine Subscription für alle Pakete.

Tipp: Wer einen Icinga Supportvertrag hat, kann sich zurücklehnen, hier ist der Zugang bereits enthalten. Bitte meldet euch einfach bei uns, wir stellen die Zugangsdaten gerne zur Verfügung bzw. wir melden uns bei euch in den nächsten Tagen.

Was geschieht mit laufenden Installationen?

Alle bestehenden Umgebungen laufen natürlich weiter. Die Umstellung betrifft nur neue Installationen und zukünftige Updates bestehender Setups.

Kann ich die Subscription testen?

Wenn ihr noch keinen Supportvertrag habt, könnt ihr die Icinga Enterprise Linux Pakete 60 Tage kostenfrei testen. Kurze Nachricht an uns und wir machen den Zugang möglich.

Martin Krodel
Martin Krodel
Head of Sales

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

NETWAYS Webinar Plan 2022 – Phase 1

Es ist wieder soweit: In 2022 starten wir wieder voll durch mit neuen Webinaren rund um unsere angebotenen Dienstleistungen von Icinga, über Graylog bis hin zu Elastic. Den Fokus legen wir dabei auch wie üblich auf einen einfachen Einstieg und im späteren Verlauf auf komplexere Themen.

Anfangen werden wir mit einigen Webinaren für Icinga for Windows – die Lösung von Icinga, um Windows Systeme und Microsoft Produkte zu überwachen. Die folgenden Termine stehen dabei schon fest:

Für Icinga selbst werden im Laufe des Jahres dann noch eigene Webinare zum Icinga Director, der vSphereDB sowie dem Reporting Modul folgen – daher am besten direkt unseren YouTube Kanal abonnieren und die Glocke aktivieren.

Darüber hinaus, haben wir noch eine Webinar-Serie zu jeweils Elastic und Graylog geplant, welche die Grundfunktionalitäten sowie Erstinstallation, aber auch spätere Integrationen, Dashboard Erstellung und Auswertungen aufzeigt. Hierzu folgen in den nächsten Wochen weitere Informationen.

Wie immer freuen wir uns über eine rege Teilnahme sowie Input für Themen, welche wir vorstellen können!

Christian Stein
Christian Stein
Lead Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".