pixel
Select Page

NETWAYS Blog

Icinga for Windows Preview: Visualisiert eure Metriken!

Icinga hat in seinem Blogpost mitgeteilt, dass es mit Icinga for Windows v1.10.0 einige Änderungen an den Performance Metriken geben wird. Hier wollen wir einmal grob zusammenfassen, worum es geht und welche Auswirkungen diese Änderungen haben. Für alle Details ist der Original-Post aber sehr zu empfehlen!

Das Label-Problem

Ein grundlegendes Problem in aktuellen Icinga for Windows Versionen ist die Tatsache, dass die Labels für Performance Metriken zwar automatisch vom Icinga PowerShell Framework generiert werden, jedoch eine Filterung auf diese Werte innerhalb von Grafana nicht so einfach möglich ist. Nimmt man sich einmal das Partition-Space Plugin zur Hand, sehen die Metriken wie folgt aus:

‘free_space_partition_c’=10328260000B;;;0;491811100000

‘used_space_partition_c’=481483000000B;;;0;491811100000

Das Label ändert sich dabei, je nachdem ob das Plugin den Free- oder Used-Space der Partitionen überwacht. An sich wäre das nicht schlimm, da Grafana ja das Filtern über mehrere Metriken hinweg erlaubt. Jedoch ergeben sich Probleme bei komplexen Plugins oder wenn verschiedene Plugins eine ähnliche Struktur der Performance Metriken liefern – dann ist nicht mehr abzugrenzen, woher eine Metrik kommt.

Check_Multi Label

Um diesem Problem entgegenzuwirken, gibt es mit Icinga for Windows v1.10.0 im August einen Breaking Change: Alle Performance Metriken werden künftig im check_multi Format geschrieben. Dadurch ergeben sich eine Vielzahl von Vorteilen, da im Vorfeld schon während der Label Generierung ein Index, ein Template sowie ein Metrik Name definiert werden kann. Im Beispiel der oberen Performance Werte, sieht das Ergebnis dann wie folgt aus:

‘c::ifw_partitionspace::used’=480627800000B;;;0;491811100000

‘c::ifw_partitionspace::free’=11178000000B;;;0;491811100000

In diesem Beispiel wäre der Index unsere Partition c, das Template für die Visualisierung ifw_partitionspace und der Name der Metrik used oder free. Sowohl der Index als auch der Metrik Name müssen innerhalb der Plugins mittels der Funktion New-IcingaCheck gesetzt werden. Hierfür gibt es dann neue Argument, -MetricIndex und -MetricName. Das Template, in unserem Beispiel ifw_partitionspace, wird dabei automatisch je nach Name des Check-Plugins gesetzt.

Natürlich ergibt sich hierdurch ein kleiner Mehraufwand für Entwickler während des Bauens der Plugins, jedoch sind die Daten in der Regel sowieso vorhanden und werden in bisherige Labels eingearbeitet, weshalb dieser überschaubar ist.

Metriken Visualisieren

Da es sich hierbei um einen Breaking Change handelt und deshalb vorhandene Grafana Dashboards nicht mehr funktionieren, gibt es eine gute Nachricht: Icinga liefert ab Tag 1 der Icinga for Windows v1.10.0 für alle Plugins Grafana Dashboards aus!

Aufgrund technischer Gründe ist ein Parallelbetrieb von alten und neuen Performance Metriken nicht möglich, daher wurde dies zum Anlass genommen, standardisierte und von Icinga gepflegte Dashboards bereitzustellen. Hierfür wird lediglich InfluxDB 2 sowie Grafana benötigt. Wer bereits eigene Dashboards erstellt hat, kann sich die vorgefertigten Dashboards als Basis hernehmen und seine Ansichten anpassen, während neue User sich direkt aus dem Portfolio bedienen können.

Icinga Web 2 CPU Metriken

Icinga Web 2 Disk Metriken

Grafana Basis-Dashboard für Icinga for Windows

 

Wir freuen uns bereits sehr auf den Release von Icinga for Windows v1.10.0 im August und helfen gerne beim Update, der Implementierung oder Erweiterung. Hierzu könnt Ihr gerne mit uns Kontakt aufnehmen!

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".

Aus Graylog ENTERPRISE wird Graylog Operations

Wie im Blogpost von Graylog bekannt gegeben, wurde die Lösung Graylog ENTERPRISE umbenannt in Graylog Operations. Der neue Name spiegelt dabei das Ziel von Graylog wider, sich verstärkt in den operational Bereich einzugliedern und Herausforderungen, die sich aus diesem ergeben, anzugehen.

Graylog Operations ist eine mächtige und dabei einfach zu bedienende Lösung, um Loginformationen und Ereignisse zu sammeln, zu korrelieren, aufzubereiten und visuell darzustellen. Dadurch werden mögliche Schwachstellen, Bottlenecks und zu verbessernde IT-Prozesse aufgezeigt und erlaubt es den Nutzern, mit diesen Reports die interne Infrastruktur weiter zu optimieren.

Graylog Security

Neben dem neuen Namen Graylog Operations und der daraus resultierenden Mission, ist Graylog Security nun ebenfalls flächendeckend verfügbar. Das Ziel von Graylog Security ist es, die interne IT auf mögliche Bedrohungen hin zu analysieren, schadhaftes Verhalten aufzudecken und die Cyberabwehr zu stärken.

Dabei hilft die kosteneffiziente Lösung, alle Informationen nicht nur zu sammeln, sondern auch auszuwerten, grafisch darzustellen und mithilfe der Reporting Funktion automatisiert detaillierte Reports über den aktuellen Status der Umgebung zu erstellen. Der Vorteil von Graylog Security ist dabei, dass die Informationen einfach eingesammelt und dargestellt werden können, ohne auf komplexe SIEM Lösungen zurückgreifen zu müssen.

 

Wir haben euer Interesse geweckt? Dann nehmt doch einfach Kontakt mit uns auf. Wir stehen bei Rückfragen und Informationen rund um Graylog Operations und Graylog Security gerne zur Verfügung!

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".

NETWAYS wird Puppet Authorized Reseller

Seit vielen Jahren unterstützt NETWAYS bereits erfolgreich Kunden bei der Konzeptionierung, dem Aufbau, der Erweiterung sowie der Migration von Puppet Umgebungen. Dabei lag der Schwerpunkt bislang auf der Open Source Variante, obwohl es im Puppet ENTERPRISE Segment viele interessante und hilfreiche Erweiterungen gibt, die wir im Rahmen der Dienstleistung nicht direkt anbieten konnten.

Diesen Zustand wollten wir ändern! Wir freuen wir uns, dass wir seit Kurzem offizieller Authorized Reseller von Puppet sind. Für unsere Kunden ändert sich an unseren bestehenden Leistungen dadurch nichts. Wir bieten weiterhin die professionellen Dienstleistungen im Open Source Bereich an, die sie von uns gewohnt sind. Der Vorteil dieser Partnerschaft ist eine Erweiterung unseres Portfolios. Anforderungen unserer Kunden können wir jetzt noch besser umsetzen, da wir nun in der Lage sind, ENTERPRISE Lizenzen selbst anzubieten und sämtliche Leistungen damit direkt von uns beziehbar sind.

Puppet als starker Partner

Für unsere Kunden ergibt sich aus dieser Partnerschaft zudem ein zusätzlicher deutlicher Vorteil: Neben den Open Source Themen können wir nun nicht nur die ENTERPRISE Lösungen anbieten, sondern auch mit Puppet und unseren Kunden gemeinsam in den Dialog treten können, um das Configuration Management passgenau beim Kunden zu installieren und zu konfigurieren.

Durch das breite Partner Netzwerk von Puppet können wir auf bisherige Erfahrungen von Puppet in ähnlichen Umgebungen zurückgreifen und mögliche Herausforderungen sowie Anforderungen frühzeitig identifizieren.

Nächster Halt: Solution Provider

Als nächster Schritt steht bei uns jetzt noch aus, dass wir Puppet Solution Provider werden. Damit ergibt sich für unsere Kunden noch eine Vielzahl an weiteren Vorteilen, da unsere Kollegen in diesem Fall offiziell von Puppet zertifiziert werden und somit auch ein Nachweis darüber vorhanden ist. Hierdurch können wir dann auch unser langjähriges Engagement und Know-How, das wir mit Puppet gesammelt haben, schriftlich unter Beweis stellen.

Habt Ihr Interesse an unseren Puppet Dienstleistungen oder Puppet ENTERPRISE? Dann nutzt doch einfach unser Kontaktformular und nehmt Kontakt mit uns auf! Wir freuen uns auf eure Anfragen!

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".

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".

NETWAYS Webinar Plan 2022 – Phase 2

Das Jahr ist in vollem Gange und ein paar unserer bisher geplanten Webinare konnten erfolgreich umgesetzt werden. Umso mehr freut es uns, dass wir den weiteren Plan für dieses vorlegen können. Neben den bereits bekannten und geplanten Themen zu Icinga for Windows

freuen wir uns über eine Vielzahl von Elastic Webinaren! Ziel soll es hier sein, einen rudimentären Überblick zu erlangen, was der Elastic Stack ist und welche Vorteile er bietet, aber natürlich auch, wie man diesen installiert, konfiguriert und erweitert. Aus diesem Grund haben wir ganze fünf Webinare eingeplant, um darüber zu sprechen! Damit haben wir eine sehr gute Abdeckung über die Basisthemen und können künftig weiter darauf aufbauen und gezielter auf Spezialthemen eingehen.

Neben diesen ganzen Themen freuen wir uns natürlich auch bereits auf Phase 3 und Phase 4 unserer Webinare in 2022. Phase 3 wird dabei verstärkt den Fokus auf Graylog legen, während Phase 4 einige allgemeine Icinga Themen mit aufnehmen wird.

Wer direkt über Neuigkeiten informiert werden möchte, sollte unseren YouTube Kanal abonnieren um nichts zu verpassen! Wir freuen uns, gemeinsam mit allen zuschauern diese Themen durchgehen zu 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".