pixel
Seite wählen

NETWAYS Blog

Icinga for Windows: Tools, Wrapper, Management

Immer wieder Mal lasse ich hier ein paar Worte zum Thema PowerShell und Icinga for Windows fallen und so ist es auch dieses Mal wieder. In meinem letzten Blogpost Plugins, Provider, PowerShell habe ich schon ein bisschen ein Blick in die einzelnen Repositories im Zusammenhang mit Icinga for Windows gegeben.

Dieses Mal betrachten wir das Framework, beziehungsweise dessen Komponenten und Tools, welche wichtig oder praktisch für Plugin-Entwicklung und Troubleshooting sind.

Tools

Mit den Tools des Frameworks lässt sich einiges an Arbeit sparen, diese befinden sich im icinga-powershell-framework repository unter /lib/core/tools. Natürlich können diese Tools auch außerhalb des Icinga-Kosmoses Anwendung finden.

Unter den Tools finden sich die verschiedenste Module, wie zum Beispiel Convert-Bytes, dessen Aufgabe es ist die Einheit entsprechender Byte Werte umzurechnen. Während der Anwendungsfall von Convert-Bytes sehr offensichtlich ist, gibt es ebenso Tools, welche Nischen bedienen, wie zum Beispiel ConvertTo-IcingaIPBinaryString, welches in der Bestimmung des Network-Interfaces mittels Get-IcingaNetworkInterface eine Rolle spielt.

Genauso wie im Developer-Guide beschrieben, sollten Custom-Plugins, sowie Tools, die von euch selbst geschrieben werden in ein separates Modul gespeichert werden. Falls der bisherige Funktionsumfang eines Tools nicht ausreichend ist für ein Custom Plugin oder Provider, dann sollte wenn möglich auf der Basis des Tools weiterentwickelt werden, wenn das möglich ist – aber natürlich innerhalb eines separaten Moduls.

Wie immer sind Pull-Request und Feature-Anfragen auch für Tools des Frameworks mehr als willkommen.

Wrapper

Um nicht willkürlich unterschiedliche Funktionen zu nutzen und eine grundsätzliche Einheitlichkeit in der Entwicklung von Plugins und Modulen im Framework zu habe werden Wrapper genutzt. Es ist also zielführender, wenn man sich im Voraus erkundigt, ob bestehende PowerShell-Kommandos in einem Wrapper mit gegebenenfalls erweiterter Logik bereits genutzt werden. Um ein paar Beispiele hierfür zu nennen, Restart-IcingaService ist im eigentlichen ein Wrapper für das PowerShell-Kommando Restart-Service. Dabei nutzt Restart-IcingaService aber Module, wie zum Beispiel Write-IcingaConsoleNotice oder Write-IcingaConsoleWarning, die dann entsprechend dafür sorgen, dass via Write-IcingaConsoleOutput entsprechende Informationen in einheitlicher Formatierung ausgegeben werden.

Ein ähnliches Szenario liegt auch vor für Start-IcingaService, Stop-IcingaService für Start-Service und Stop-Service. Im Falle dieser drei Wrapper wurde das Error-Handling im Icinga-Kontext verbessert im Vergleich zu den einzelnen zugrunde liegenden Kommandos.

Prominentestes Beispiel für die Plugin-Entwicklung jedoch ist wahrscheinlich Get-IcingaWindowsInformation, mehr oder weniger ein Wrapper für Get-WmiObject und Get-CimInstance. Get-IcingaWindowsinformation hilft hierbei nur WmiObjects aufzurufen, welche vom Framework unterstützt werden, beziehungsweise weißt es auf fehlende Berechtigungen hin und beschreibt eventuelle Fehler genauer bei der Plugin-Entwicklung. Sollten also in einem Provider CimObjects oder WimObjects benötigt werden, dann sollten diese mittels Get-IcingaWindowsInformation aufgerufen werden.

Selbiges wie bei den Tools gilt natürlich auch hier. Wenn Kommandos mit logischen Strukturen für das icinga-powershell-framework verbessert werden können, zum Beispiel in Form eines Wrappers, dann sind Vorschläge stets erwünscht.

Management

Hier ein kleiner Einblick in ein bisher noch experimentelles Feature und zwar die Management-Konsole. Die Funktion Invoke-IcingaCommand oder gemeinhin eher icinga, sollte bekannt sein, aber nichts desto trotz hier noch einmal. Der icinga Befehl ist grundsätzlich dafür da um Framework-Befehle in einer neuen PowerShell-Instanz auszuführen, was das Testen von neuen Plugins schnell und angenehm gestaltet.

Als Beispiel kann somit direkt durch geschweifte Klammern ein Skriptblock übergeben werden:
PS> icinga { Get-IcingaCPUs }               
Name             Value                      
----             -----                      
0                {specs, errors, metadata}  

Alternativ kann ohne Parameter, beziehungsweise Klammern, eine Icinga-Konsole aufgerufen werden, die wie beim gebrauch von Use-Icinga die Framework-Funktionalitäten lädt:
PS> icinga                                  
********************************************
**       Icinga for Windows v1.5.0        **
**  Copyright (c) 2021 Icinga GmbH | MIT  **
**       User environment Test\Test       **
********************************************
icinga> Get-IcingaCPUs                      
Name             Value                      
----             -----                      
0                {specs, errors, metadata} 

Jetzt aber zur Management-Konsole, die wird aufgerufen durch das Benutzen von icinga -Manage. Es ist notwendig den Befehl auf einer Administrator-Shell auszuführen, ansonsten stehen nicht alle Funktionalitäten zur Verfügung. Durch das Ausführen des Befehls landet man in einem Interaktiven Menü, mit den folgenden Punkten und Aktionsmöglichkeiten:
[0] Installation                       
[1] Update environment                 
[2] Manage environment                 
[3] Remove components                  
[x] Exit Continue [h] Help [m] Main
Input (Default 0 and c):               

Abhängig von der Installation der Umgebung sind Punkte abgeschaltet und aus gegraut. Die Hilfe gibt zu jeden einzelnen Punkt und Schritt in den jeweiligen Untermenüs Informationen. Dadurch dass die vielen Untermenüs und Schritte zahlreich sind, sollte sich das jeder selbst genauer anschauen, beispielsweise ähnelt der erste Punkt, der der Installation sehr dem Interaktiven-Menü des Kickstarts-Skripts. Während die anderen Punkte, wie Update, und Manage environment es einen Nutzer erlauben auch mit geringen Kenntnisstand über Framework-Funktionen, die Funktionalitäten auszukosten. Wer also kein Freund von Befehlen wie Invoke-IcingaFrameworkUpdate oder Install-IcingaFrameworkComponent ist, kann die Sache hiermit unter einem Hut einfach zusammenfassen. Genau das Gleiche gilt auch für Befehle wie Uninstall-IcingaFrameworkComponent mit Punkt 3.

Wir würden uns wirklich sehr darüber freuen, wenn ihr das experimentelle Feature ausprobieren könntet und uns dazu Feedback zu kommen lassen würdet.

Icinga PowerShell Management Console

Alexander Stoll
Alexander Stoll
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

Lessons learned: Das nehme ich mit ins neue Jahr

Dieses Jahr war wieder ein aufregendes Jahr aus den verschiedensten Gründen, wie sich viele von euch vorstellen können. Insbesondere für mich, als Auszubildender. Ich durfte mich mit den unterschiedlichsten Dingen auseinandersetzen, einen kleinen Einblick habt ihr ja schon Anfang des Jahres erhalten.

Ich hätte niemals gedacht, dass ich in diesem Jahr so viel Abwechslung erfahren würde, Schulungen, Weiterbildungen, Evaluationen, Kundentermine, Remote-Arbeit und noch viele weitere Projekte.

Support

Ein großer Zeitraum in diesem Jahr war geprägt durch die Arbeit im Support, welche ich ja bereits hier angekündigt habe. Der Sinn dahinter Auszubildende in den Support zu stecken ist Erfahrungen zu sammeln. Derartige Erfahrungen, wie man sie im Support macht, helfen einem Consultant später Vorort oder wie ich später im Jahr auch lernen sollte, bei der Remote-Arbeit, enorm weiter. Nicht zu vergessen arbeitet man im Support immer im Team und als Team, hat Kollegen die einen jederzeit unterstützen können und ihr Wissen teilen.

Webentwicklung

Zwar hat das Thema Webentwicklung für mich und als Consultant keinen direkten hohen Stellenwert, aber es war für mich ein persönliches Highlight dieses Jahr und auch als Consultant kann ich bestimmte Aspekte davon ganz gut gebrauchen.

Im Icinga-Kontext oder speziell Icinga Web 2 sind Kenntnisse in PHP nicht zu unterschätzen, wenn es darum geht Troubleshooting zu betreiben. Immer wieder mal sich mit PHP, HTML, CSS auseinanderzusetzen macht durchaus Spaß und demnächst dürft ihr euch auf die Früchte eines kleinen Projektes von mir freuen, wenn es um Icinga Web 2 Themes geht.

Mein Schlusswort zu 2020

Ich habe hier eigentlich nur Positives zu sagen, auch wenn für viele das Jahr 2020 mit Schicksalsschlägen und der derzeitigen weltweiten Situation behangen ist kann ich sagen, dass es mir gut geht. Wenn mir das Jahr 2020 aus persönlicher Sicht etwas beigebracht hat, dann ist es bescheidener zu sein und mich für meine guten Position dankbar zu zeigen. 

Persönlich glaube ich fest daran, dass das nächste Jahr besser wird und selbst wenn nicht, dann mach ich für mich persönlich das Beste daraus, was mir möglich ist.

Ich wünsche euch allen schöne Feiertage und ein gesundes neues besseres Jahr!

 

Alexander Stoll
Alexander Stoll
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

Windows: One Framework to Monitor them all by Christian Stein | OSMC 2019

This entry is part 4 of 4 in the series OSMC 2019 | Recap

At the Open Source Monitoring Conference (OSMC) 2019 in Nuremberg, Christian Stein captivated the entire conference room with his presentation “Windows: One Framework to Monitor them all”. His demo was the highlight of his presentation, which ended up with enthusiastic applause. You have missed him speaking? We have got something for you: Watch the video of Christian’s presentation and read a short summary (below).

At OSMC international monitoring experts meet annually to set and discuss future trends and objectives. Since 2006 the event takes place every autumn in Nuremberg, Germany. Leading specialists present the full scope of Open Source monitoring and are ready to answer your hardest questions. Discuss with top developers, exchange knowledge and learn wen techniques.

You want more? In-depth workshops the day prior to the conference and a Hackathon provide further possibilities to extend your skills and deepen your knowledge in IT monitoring and management.

The next OSMC takes place in 2021 in Nuremberg.

More information and tickets at osmc.de.


Windows: One Framework to Monitor them all

Christian Stein signed up with a talk titled “Windows: One Framework to Monitor them all” and the intention to turn the Windows side of Icinga upside down. After giving a short run down of the the current issue with “Icinga for Windows” and his attempts at fixing them, we get to the good stuff.

An Icinga PowerShell Framework supported by Powershell 4.0 or higher, but let‘s get into the juicy details: The framework comes with a lot of features, to easily extend it within your environment and to simplify monitoring on Windows as well. Additionally, there is a dev-toolkit, which offers plenty of possibilities for developers to give the framework their own tweak. As of now, there are four repositories beyond the framework itself. Up first and most important to mention is icinga-powershell-kickstart, which provides a basic PowerShell script to interactively install the framework. Also rather essential for the framework is the icinga-powershell-plugins repository, which provides a collection of Windows check plugins.

Want to run the framework as a service? Glad you asked. There is a repository for that as well. It’s also covered by the kickstart wizard. Check icinga-powershell-service to find out more or to give some feedback. If you’ve always asked yourself why you should run appliances as a service, there are several benefits. Like the service running before a user logs on and continuing to run, without a logged on user.

Last but not least, even most essential, the framework itself. If we look at the current ways to make Icinga work on windows, they are good, but not great. The icinga-monitoring-framework provides tools and configuration to make icinga monitoring on windows possible, almost natively, except for said repositories.

Having said all that and more, Christian went on with a live demo of the Framework, gave some installation advice and by that I mean, delved deeper into the kickstart script. He also showed off some features and gave some best practice advice. So, all that was left to say is… whats next?

Christian announced, that it will be available on PowerShell Gallery, which will not only help the project grow, but make it even more available as is. And of course, there will be more plugins. For those eagerly waiting for one of these, the next release hopefully provides MSSQL, Active-Directory, Exchange and Hyper-V plugins.

The community’s and the customer’s interest in better windows monitoring is undeniable, but we depend on your feedback and support on this, the respective repository is the place to be, and if you can’t figure, which one it fits, just post your issue at: https://github.com/Icinga/icinga-powershell-framework/issues

Alexander Stoll
Alexander Stoll
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

Plugins, Provider, PowerShell

Im Icinga-Windows-Kosmos passiert in letzter Zeit sehr viel, vor allem durch das Zauberwort PowerShell. Framework, Plugins, Kickstart und Service, das alles hört man recht oft und auch neue Releases sind da oder stehen an. Doch wie schreibe ich meine eigenen Checks beziehungsweise Plugins? Gibt es Vorschriften an die ich mich halten sollte? Und kann ich mich auch an dem Projekt beteiligen?

Plugins und Provider

Als das Projekt gestartet worden ist, war es bereits angedacht, dass Plugins individuell anpassbar sein sollten. Um dies zu gewährleisten, war es wichtig die Daten, die zur Prüfung genutzt werden in einer normierten Form gesammelt zurückzugeben und hier kommen die Provider ins Spiel.

Was ist ein Provider?

Ein Provider sammelt Daten vom System und stellt sie zur Verfügung um in Plugins genutzt zu werden. Sehen wir uns das ganze im icinga-powershell-plugins repository an:
└── provider
├── bios
├── cpu
├── directory
├── disks
├── enums
├── eventlog
├── memory
├── process
├── services
├── updates
├── users
└── windows

Innerhalb dieser Verzeichnisse befinden sich in der Regel zwei Dateien. Im Falle von CPU wären das Icinga_ProviderCpu.psm1 und Show-IcingaCpuData.psm1. Respektive Dateien existieren auch in allen anderen Verzeichnissen.

Mit dem gleichnamigen Befehl Show-IcingaCpuData kann man nun alle generischen Daten zur Thematik CPU abfragen. Während die Datei Icinga_ProviderCpu.psm1 verschiedene Funktionen enthält um spezifische Daten anzufordern. Darunter zum Beispiel folgende Funktionen: Get-IcingaCPUArchitecture, Get-IcingaCPUArchitecture.

Im Falle von Get-IcingaCPUs könnte der Output beziehungsweise die bezogenen Daten, wie folgt aussehen – gekürzt und in JSON konvertiert:
{
"specs":  {
"L3CacheSize":  0,
"CurrentClockSpeed":  2100,
"VoltageCaps":  0,
"L2CacheSpeed":  null,
"ThreadCount":  1,
"CurrentVoltage":  null,
"LoadPercentage":  7,
"L2CacheSize":  null
},
"errors":  {
"ErrorDescription":  null,
"ErrorCleared":  null,
"ConfigManagerErrorCode":  {
"value":  "This device is working properly.",
"raw":  0
},
"LastErrorCode":  null
},
"metadata":  {
"ProcessorType":  {
"value":  "Central Processor",
"raw":  3
},
...
"SocketDesignation":  "CPU 1",
"ProcessorID":  "078BFBFF000306A9",
"NumberOfCores":  1,
"SerialNumber":  "",
"Architecture":  {
"value":  "x64",
"raw":  9
},
"Availability":  {

},
"AddressWidth":  64,
"Status":  "OK",
"StatusInfo":  {
"value":  "Enabled",
"raw":  3
},

}

Auf diese Daten können wir nun Aufbauen. Ob die Daten direkt zuträglich sind oder ausreichend für unsere Anwendung ist individuell.

Bevor ich ein Plugin schreibe!

Bevor es dazu kommt, dass man ein Plugin schreibt und Unmengen an Cmdlets benutzt und die Daten normiert, sollte man sich darüber im Klaren sein, was es alles für Provider gibt und vorher überprüfen, ob die Daten nicht in der ein oder anderen Form bereits vorhanden sind.

Gefällt mir etwas am Invoke-IcingaCheckCPUs Check nicht, dann ist es sinnig, zumindest zunächst den Provider des Check-Plugins zu betrachten und zu prüfen ob man nicht die Informationen die der Check erhält anders nutzen kann.

Falls das nicht der Fall ist, sollte man seinen eigenen Provider schreiben oder einen vorhanden ergänzen und uns vielleicht mit einen Pull-Request überraschen.

Aber wohin das Ganze?

Damit nicht alles verloren ist beim nächsten Update oder Konflikte auftreten, gibt es im Icinga-PowerShell-Framework ein Custom-Verzeichnis. Dieses unterteilt sich wiederum in /lib und /plugins. In das plugins-Verzeichnis kommen folgerichtig natürlich die Plugins, die ihr für euch individuell anlegt und die nicht oder noch nicht Teil des Repositorys sind.

Das Gleiche gilt natürlich auf für das Library-Verzeichnis. Wenn ihr das Rad neu erfinden wollt und ein Custom-Module baut für Test-Numeric oder euch das Ausgabeformat von Convert-Bytes stört, dann sind eure Tools hier sicher. Und natürlich auch da freuen wir uns über einen Pull-Request.

Wir halten fest, wenn man also ein Plugin baut, dann sollte man ein eigenes PowerShell Modul bauen und sich dabei weitestgehend zunächst an den vorhandenen Plugins orientieren und aufpassen, wo was hingehört.

Fazit

Wer es richtig machen will, fängt langsam an und baut vor allem modular. Erst der Provider, dann das eigentliche Check-Plugin. Desto größer der Provider, desto einfacher das Bauen der Check-Plugins, weil mit bereits vorhanden Informationen ist die Logik, der Check-Prüfung das wenigste Problem.

Wem das alles noch nicht genug ist, der kann auch mal auf unserem Youtube-Channel vorbei schauen, wo wir im Umfang unserer Webinare mit unter Custom Plugin Development und Custom Daemon Development besprochen haben.

Seit in jeden Fall gespannt wie es mit dem Projekt weitergeht und für noch mehr zum Thema Plugin schreiben schaut euch den Developer-Guide an.

Alexander Stoll
Alexander Stoll
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

Evolution of a Microservice-Infrastructure by Jan Martens | OSDC 2019

This entry is part 2 of 6 in the series OSDC 2019 | Recap

 

At the Open Source Data Center Conference (OSDC) 2019 in Berlin, Jan Martens invited to audience to travel with him in his talk „Evolution of a Microservice-Infrastructure”. You have missed him speaking? We got something for you: See the video of Jan‘s presentation and read a summary (below).

The former OSDC will be held for the first time in 2020 under the new name stackconf. With the changes in modern IT in recent years, the focus of the conference has increasingly shifted from a mainly static infrastructure approach to a broader spectrum that includes agile methods, continuous integration, container, hybrid and cloud solutions. This development is taken into account by changing the name of the conference and opening the topic area for further innovations.

Due to concerns around the coronavirus (COVID-19), the decision was made to hold stackconf 2020 as an online conference. The online event will now take place from June 16 to 18, 2020. Join us, live online! Save your ticket now at: stackconf.eu/ticket/


 

Evolution of a Microservice-Infrastructure

Jan Martens signed up with a talk titled “Evolution of a Microservice Infrastructure” and why should I summarize his talk if he had done that himself perfectly: “This talk is about our journey from Ngnix & Docker Swarm to Traefik & Nomad.”

But before we start getting more in depth with this talk, there is one more thing to know about it. This is more or less a sequel to “From Monolith to Microservices” by Paul Puschmann a colleague of Jan Martens, but it’s not absolutely necessary to watch them in order or both.

 

So there will be a bunch of questions answered by Jan during the talk, regarding their environment, like: “How do we do deployments? How do we do request routing? What problems did we encounter, during our infrastructural growth and how did we address them?”

After giving some quick insight in the scale he has to deal with, that being 345.000 employees and 15.000 shops, he goes on with the history of their infrastructure.

Jan works at REWE Digital, which is responsible for the infrastructure around services, like delivery of groceries. They started off with the takeover of an existing monolithic infrastructure, not very attractive huh? They confronted themselves with the question: “How can we scale this delivery service?” and the solution they came up with was a micro service environment. Important to point out here, would be the use of Docker/Swarm for the deployment of micro services.

Let’s skip ahead a bit and take a look at the state of 2018 REWE Digital. Well there operating custom Docker-Environment consists of: Docker, Consul, Elastic Stack, ngnix, dnsmasq and debian

Jan goes into explaining his infrastructure more and more and how the different applications work with each other, but let’s just say: Everything was fine and peaceful until the size of the environment grew to a certain point. And at that point problems with nginx were starting to surface, like requests which never reached their destination or keepalive connections, which dropped after a short time. The reason? Consul-template would reload all ngnix instances at the same time. The solution? Well they looked for a different reverse proxy, which is able to reload configuration dynamically and best case that new reverse proxy is even able to be configured dynamically.

The three being deemed fitting for that job were envoy, Fabio and traefik, but I have already spoiled their decision, its treafik. The points Jan mentioned, which had them decide on traefik were that it is dynamically configurable and is able to reload configuration live. That’s obviously not all, lots of metrics, a web ui, which was deemed nice by Jan and a single go binary, might have made the difference.

Jan drops a few words on how migration is done and then invests some time in talking about the benefits of traefik, well the most important benefit for us to know is, that the issues that existed with ngnix are gone now.

Well now that the environment was changed, there were also changes coming for swarm, acting on its own. The problems Jan addresses are a poor container spread, no self-healing, and more. You should be able to see where this is going. Well the candidates besides Docker Swarm are Rancher, Kubernetes and Nomad. Well, this one was spoiled by me as well.

The reasons to use nomad in this infrastructure might be pretty obvious, but I will list them anyway. Firstly, seamless consul integration, well both are by HashiCorp, who would have guessed. Nomad is able to selfheal and comes in a single go binary, just like traefik. Jan also claims it has a nice web UI, we have to take his word on that one.

Jan goes into the benefits of using Nomad, just like he went into the benefits of ngnix and shows how their work processes have changed with the change of their environment.

This post doesn’t give enough credit to how much information Jan has shared during his talk. Maybe roughly twenty percent of his talk are covered here. You should definitely check it out the full video to catch all the deeper more insightful topics about the infrastructure and how the applications work with each other.

Alexander Stoll
Alexander Stoll
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.