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
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.

Die Out of the Box Experience

Hallo!

Ich würde gern ein aktuelles Thema aufgreifen, das in letzter Zeit viele Leute beschäftigt. Da aus aktuellem Anlass viele Leute ins Homeoffice gehen mussten und nun von dort ihre Arbeit verrichten, haben viele neue Monitore, Rechner, Mikros und Software erhalten, um dies zu bewältigen.

Nun gibt es aber die schon oben beschriebene Erfahrung, die aus rein subjektiver Sicht entscheidet, ob man mit dem neuen Produkt zufrieden ist oder es gleich wieder einpacken und zurückschicken will.

Das Feld ‘Videokonferenzen’ will ich hier gar nicht betreten. Da hat jeder andere Präferenzen.

Mir geht es in dem Blogpost eher um die “Experience”, ein tolles Marketing-Buzzword, bei dem sich am liebsten jeder unter der Couch verstecken möchte. Die Erfahrung, die man mit dem jeweiligen Produkt direkt nach dem Auspacken macht, ist sehr variabel.

Nehmen wir mal als Beispiel einen neuen Firmenlaptop. Wir haben ihn aus der Verpackung gepult und drücken auf den Powerknopf und unsere neue Kiste mit SSD und mehr Speicher & CPU Kraft aller Großrechner in den 80zigern dümpelt 5 Minuten in einem Regenbogenfarbenen Waiting Screen von Windows umher in dem uns mitgeteilt wird das wir uns freuen dürfen das ‘now’ etwas für uns passiert.

NOT!!!! Jemanden warten zu lassen ist keine ‘Gute’ Out of the Box Erfahrung. Auch 4-5 Sicherheitsfragen welche sowas lustiges wissen wollen wie “Was war ihr erstes Haustier” … sind eher Anti Security .. Rein statistisch hat man hier schon in den USA mit sowas wie ‘Spot’ einen Treffer um in einen Benutzeraccount rein zu kommen.

Idealerweise sollte man nicht warten müssen . NEVER make your Customer wait.

Das wussten selbst Betriebssysteme aus der prähistorischen Ära. Einschalten, Loslegen. C64 => Einschalten und READY.
Selbst die Amiga Workbench war nach dem Starten direkt verfügbar und auch Atari TOS auf dem ST. Nun sind wir im Jahr 2020 AD.

Aus Sicht eines Endbenutzers ist das keine gute Erfahrung (Warten, abgreifen personenbezogener Daten für Marketing-Zwecke, Sicherheitsexploit-Fragen) und zum goldenen Abschluss, nachdem man die ganze Prozedur hinter sich hat, kommt noch ein haufen Autoupdates, die noch installiert werden müssen, bevor man effektiv anfangen kann zu arbeiten.

Selbst bei Konsolen ist die Out of the Box Erfahrung … inzwischen hundsmiserabel.
Früher: SNES Spiel in die Konsole stecken und läuft. Heute: Mindestens 2 Anmeldungen. Einmal Hersteller spezifisch XBox Account/STEAM Account/PSX Account und dann gegebenenfalls nochmal die des Spieleherstellers und dessen Plattform inkl. Werbung.

Das künstliche Gold der Marketing/Wertschöpfungskette von Daten, die nur um deren Selbstwillen für User Tracking generiert werden, ist bis in das einfachste Produkt vorgedrungen. Selbst meine Bose Wireless Kopfhörer wollen meinen Alex Account Zugriff um mir ‘Mehr Info’ liefern zu können.

Da ich nun sehr abgedriftet bin von der Thematik: Die “Auspack und sofort Loslegen Erfahrung” ist sehr “Simplismus” geprägt, man findet die “Out of the Box” Erfahrung am idealsten, wenn man direkt loslegen kann.
Kein wenn und kein aber.
Zu einem späteren Zeitpunkt können die Settings des Produktes verfeinert werden. Also ggf. einen Account anlegen, höhere Security Settings setzen und andere Einstellungen vornehmen.

Aber die Defaults sollten IMMER zu einem produktiven Ergebnis führen.

Software ist auch ein Werkzeug wie ein Schraubenzieher. Der will auch nicht, dass ich bei ‘Binford’ einen Account anlege. bevor ich die erste Schraube in das Holzbrett drehe. Software & Betriebssysteme sollten allgemein wieder auf Funktionalität ausgelegt werden anstelle von Subscription ‘featureitis’ …

Das baut nur unnötige Hürden und Fehlerquellen auf und dient nur dem Selbstzweck.
Einstecken, Einschalten & Loslegen war mal die Devise – ich hoffe, dass nach all den bitteren Erfahrungen der letzten Zeit wieder auf diese Out of the Box Erfahrung Wert gelegt wird.

In dem Sinne ‘Good Luck and Good Night’

Bis zum nächsten Mal

David

Das Nette Katzenfoto wurde bereitgestellt von

Photo by DNK.PHOTO on Unsplash.

David Okon
David Okon
Support Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

Icinga for Windows – Webinar Kalender

Im Februar hat das Icinga-Team sehr erfolgreich die neue Lösung zur Überwachung von Windows-Systemen veröffentlicht. Hierbei handelt es sich um ein auf PowerShell-Basis bereitgestelltes Framework inklusive Plugins, welches individuell erweitert werden kann. Um den Einstieg zu erleichtern haben wir eine Reihe von Webinaren geplant, um sowohl die Installation und Grundeinrichtung aber auch die Entwicklung von eigenen Plugins und Modulen zu veranschaulichen.

Starten werden wir direkt am Mittwoch, den 11. März 2020 um 10:30 mit dem Webinar “Icinga for Windows – Einstieg”. Eine kostenfreie Registrierung und Teilnahme ist wie immer möglich. Anschließend werden wir das Webinar auf unserem YouTube-Kanal online stellen.

Darüber hinaus haben wir noch weitere Themen wie ein Webinar zur Plugin-Entwicklung und Daemon-Entwicklung geplant. Eine vollständige Übersicht stellen wir natürlich auch bereit:

Thema Datum Anmeldung
Icinga for Windows – Einstieg 11. März 2020 – 10:30 Uhr Anmeldung
Icinga for Windows – Custom Plugin Development 01. April 2020 – 10:30 Uhr Anmeldung
Icinga for Windows – Custom Daemon Development 06. Mai 2020 – 10:30 Uhr Anmeldung

Auf weitere Themen gehen wir gerne ein – Vorschläge können dabei direkt an uns übermittelt werden. Wer Unterstützung bei der Einrichtung, Erweiterung und dem Roll-Out benötigt, kann hierfür ebenfalls auf uns zukommen.
Eine Anfrage kann direkt über unser Kontaktformular eingekippt werden.

Wir freuen uns auf die Teilnahme sowie zahlreiches Feedback!

Christian Stein
Christian Stein
Lead Senior 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 1.0 – Eine neue Ära

Seit heute ist der erste offizielle, stabile Release des Icinga für Windows Pakets in Version 1.0 verfügbar. Das Paket besteht aus drei individuellen Komponenten – dem Icinga PowerShell Framework, dem Icinga PowerShell Service und den Icinga PowerShell Plugins. In Kombination bilden sie den Grundbaustein für die künftige Überwachung von Windows Systemen – inklusive Software, Hardware und alles was dazugehört.

Neben der klassischen Überwachung der Windows Systeme geht das Framework aber noch einen Schritt weiter: Mit über 200 Cmdlets wird nicht nur das Monitoring an sich sichergestellt, sondern auch das Deployment der einzelnen Komponenten inklusive Icinga 2 Agent. Darüber hinaus wird die Verwaltung des Agents, die Konfiguration, aber auch das Troubleshooting auf Windows System deutlich vereinfacht: Für die gängigsten Befehle wurden Wrapper-Cmdlets entwickelt, mit denen neben dem Logfile-Tracing auch Features aktiviert und deaktiviert werden können, Icinga 2 Objects auslesbar und durchsuchbar gemacht wurden oder die Funktionsfähigkeit der Icinga 2 Installation auf dem lokalen System überprüft werden kann.

Vereinfachte Installation

Folgt man der Installationsanleitung, dann stellt man fest, dass die meisten Schritte vereinfacht über einen Installations-Wizard durchgeführt werden können. Der große Vorteil dabei ist, dass die Grundinstallation nur auf einem System vollständig manuell durchgeführt werden muss. Ist der Wizard erst einmal durchgeklickt, erhält man einen Konfigurations-String, der auf einem anderen System einfach ausgeführt werden kann, nachdem dort das Framework über den Kickstart installiert worden ist. Somit ist der künftige Rollout der Systeme einfacher denn je.

Standardisiertes Monitoring

Plugins bieten die Möglichkeit, schnell und effizient einzelne Komponenten zu überwachen. Die Schwierigkeit liegt darin, den Output der Plugins richtig zusammen zu bauen und Performance-Metriken sauber zu kapseln. Zum Schluss bleibt dann nur noch das Einpassen in das standardisierte Threshold-Verhalten der Icinga Plugins sowie die Ausführung der bekannten Prüfung, ob ein Wert nun Ok, Warning, Critical oder vielleicht doch Unknown ist.

All das wird mit dem Icinga PowerShell Framework deutlich vereinfacht, denn es werden einige Funktionen bereitgestellt, die sich genau um diese Tasks kümmern. Am Ende des Tages holt man sich einfache seine Daten über PowerShell Cmdlets und packt diese in ein Icinga Check-Objekt. Mit den Informationen, die das Objekt erhält, kann anschließend geprüft werden, welchen Status das Objekt hat und mittels einem Check-Result Objekt in ein gültiges Icinga 2 Format gebracht werden. Der Output ist anschließend für alle Plugins standardisiert.

Zeitintervall-Metriken

In der Vergangenheit lag der große Vorteil von Lösungen wie NSClient++ darin, dass diese als Dienst gestartet werden konnten und dabei Metriken gesammelt haben. Hierdurch konnte man auch auf Windows beispielsweise die CPU-Load in Intervallen von 1, 3, 5 und 15 Minuten in den Performance-Daten abbilden. Installiert man das PowerShell Framework als Dienst, ist dieser Zustand für jedes Plugin ebenfalls abbildbar. Hierfür ist lediglich der Background-Daemon für den Service Check mittels

Register-IcingaBackgroundDaemon -Command ‘Start-IcingaServiceCheckDaemon’

zu registrieren. Anschließend können einzelne Service-Checks für die regelmäßige Ausführung konfiguriert werden. Möchte man für die CPU-Load alle 30 Sekunden Metriken für die Intervalle 1, 3, 5 und 15 Minuten sammeln, registriert man den Service-Check entsprechend

Register-IcingaServiceCheck -CheckCommand ‘Invoke-IcingaCheckCPU’ -Interval 30 -TimeIndexes 1, 3, 5, 15;

Anschließend startet man den PowerShell Dienst neu und erhält alle Metriken in den gewünschten Intervallen:

Administrationsunterstützung

Wer den Icinga 2 Agent auf Windows administriert, muss auch hier öfter einmal die Konsole zur Hand nehmen und das Icinga 2 Binary mit diversen Befehlen starten. Das PowerShell Framework bietet auch hierfür einige Lösungen, da – wie bereits erwähnt – gängige Befehle in einem Wrapper-Cmdlet hinterlegt sind. Ein einfaches Parsen und stetiges Lesen der Logfiles erfolgt damit über einen einzigen Befehl – ohne am Ende in das Icinga Verzeichnis navigieren oder die Logdatei suchen zu müssen:

PS> Use-Icinga; Read-IcingaAgentLogFile
[2020-02-19 14:40:31 +0100] information/RemoteCheckQueue: items: 0, rate: 0/s (6/min 30/5min 90/15min);
[2020-02-19 14:40:41 +0100] information/RemoteCheckQueue: items: 0, rate: 0/s (12/min 60/5min 180/15min);

Sucht man mittels icinga2 object list nach bestimmten Check-Commands oder generellen Einträgen, gibt es auch hierfür eine elegante Lösung:

PS> Use-Icinga; Find-IcingaAgentObjects -Find ‘*CheckMemory*’
Line #4948 => “Object ‘Invoke-IcingaCheckMemory’ of type ‘CheckCommand’:”
Line #4950 => ” * __name = “Invoke-IcingaCheckMemory””
Line #4955 => ” * value = “Use-Icinga; exit Invoke-IcingaCheckMemory””
Line #4958 => ” * value = “$IcingaCheckMemory_String_CriticalBytes$””
Line #4961 => ” * value = “$IcingaCheckMemory_Object_CriticalPercent$””
Line #4964 => ” * set_if = “$IcingaCheckMemory_Switchparameter_NoPerfData$””
Line #4967 => ” * value = “$IcingaCheckMemory_Int32_Verbosity$””
Line #4970 => ” * value = “$IcingaCheckMemory_String_WarningBytes$””
Line #4973 => ” * value = “$IcingaCheckMemory_Object_WarningPercent$””
Line #4986 => ” * name = “Invoke-IcingaCheckMemory””
Line #4994 => ” * templates = [ “Invoke-IcingaCheckMemory”, “plugin-check-command”, “PowerShell Base”, “plugin-check-command”, “plugin-check-command” ]”

Damit wird die generelle Administration nicht nur einfacher, sondern mittels PowerShell Remote-Execution können auch mehrere Systeme gleichzeitg abgefragt und Statusinformationen eingesammelt werden.

Um sicherzustellen, dass der Agent korrekt ausgeführt wird, der Dienst gestartet werden kann und alle notwendigen Komponenten vefügbar sind, gibt es einen simplen Test, der alle Funktionalitäten überprüft:

Einfache Erweiterbarkeit

Alles in allem ist das Framework so gebaut, dass es eine solide Basis für weitere Entwicklungen bietet – sei es direkt von Seiten Icinga, NETWAYS oder aus der Community. Der Developer Guide bietet schon jetzt grundlegende Erklärungen und Erläuterungen und wird in den nächsten Wochen noch erweitert. Wer sein eigenes PowerShell Modul entwickeln möchte, um Plugins für die Überwachung oder eigene Background-Daemons bereitzustellen, der findet mit diesem Framework das nötige Werkzeug.

Live Webinar

Wer sich einen eigenen Eindruck über das Icinga PowerShell Framework und dessen zahlreiche Möglichkeiten machen möchte, der sei herzlich zu unserem Icinga for Windows – Einstieg” Webinar am 11. März 2020 um 10:30 Uhr eingeladen. Wir freuen uns wie immer auf eine rege Teilnahme.

Wer Unterstützung bei der Installation und Konfiguration oder bei der Entwicklung eigener Plugins benötigt, kann natürlich gerne Kontakt mit uns aufnehmen. Ansonsten freuen wir uns natürlich über Feedback und breite Unterstützung aus der Community!

Christian Stein
Christian Stein
Lead Senior 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".

Sommerhitze & Powershell 3 kleine Tipps

Hallo Netways Follower,

Ich melde mich dies mal mit einem kurzen aber meist vergessenen Thema nämlich wie kriegt man unter Windows diese vermaledeiten Powershell Skripts korrekt zum laufen.

Wenn man bei einem normalen Icinga2 Windows Agenten diese in ‘Betrieb’ nehmen will benötigt es etwas Handarbeit und Schweiß bei diesen Sommertagen um dies zu bewerkstelligen.

Trotzdem hier ein paar Tipps:

1) Tipp “Powershell Skripte sollten ausführbar sein”

Nachdem der Windows Agent installiert und funktional ist sollte man sich auf der Windows Maschine wo man das Powershell Skript ausführen möchte in die Powershell (nicht vergessen mit Administrativer Berechtigung) begeben.

Um Powershell Skripts ausführen zu können muss dies erst aktiviert werden dazu gibt es das folgende Kommando

Set-ExecutionPolicy Unrestricted
Set-ExecutionPolicy RemoteSigned
Set-ExecutionPolicy Restricted

Hier sollte zumeist RemoteSigned ausreichend sein, aber es kommt wie immer auf den Anwendungsfall an. More Info here.

Nach der Aktivierung kann man nun überprüfen ob man Powershell Skripts ausführen kann.
Hierzu verwende ich meist das Notepad um folgendes zu schreiben um anschließend zu prüfen ob das oben aktivierte auch klappt.

Also ein leeres Windows Notepad mit dem folgenden befüllen:

Write-Host "Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul. "

Das ganze dann als ‘test.ps1’ speichern.

Nun wieder in die Powershell zurück und an dem Platz wo man das Powershell Skript gespeichert hat es mit dem folgenden Kommando aufrufen.
PS C:\Users\dave\Desktop> & .\test.ps1
Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.

Sollte als Ergebnis angezeigt werden damit Powershell Skripts ausführbar sind.

2) Tipp “Das Icinga2 Agent Plugin Verzeichnis”

In der Windows Version unseres Icinga2 Agents ist das standard Plugin Verzeichnis folgendes:
PS C:\Program Files\ICINGA2\sbin>

Hier liegen auch die Windows Check Executables.. und ‘.ps1’ Skripte welche auf dem Host ausgeführt werden sollten/müssen auch hier liegen.

3) Tipp “Powershell 32Bit & 64Bit”

Wenn ein Skript relevante 64Bit Sachen erledigen muss kann auch die 64er Version explizit verwendet werden in den Check aufrufen.

Das heißt wenn man den object CheckCommand “Mein Toller Check” definiert kann man in dem Setting:

command = [ "C:\\Windows\\sysnative\\WindowsPowerShell\\v1.0\\powershell.exe" ] //als 64 Bit angeben und
command = [ "C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe" ] // als 32Bit.

Hoffe die drei kleinen Tipps erleichtern das Windows Monitoring mit Powershell Skripts.
Wenn hierzu noch Fragen aufkommen kann ich unser Community Forum empfehlen und den ‘kleinen’ Guide von unserem Kollegen Michael. Icinga Community Forums

Ich sag Ciao bis zum nächsten Mal.

David Okon
David Okon
Support Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

Terraform Changes

Hallo!

Was vielen von unseren Lesern entgeht, ist das wir auch in unserem Alltag zwischen der ganzen Softwareschreiber- und Kompilier- Tätigkeiten auch ganz viele virtuelle Maschinen und Container zum testen selbiger Software rauf und runter installieren müssen, und das Tag für Tag.

Deshalb versuchen wir uns das Leben mit dafür erstellter Software und deren arbeitserleichternden Funktionen leichter zu machen. Wie mein Kollege schon in seinem Blogpost im März mir vorgegriffen hat, benutzen wir bei der Netways Terraform. Achim wird in weiteren Artikeln darauf eingehen wie man Openstack per Terraform nach seiner Pfeife tanzen lassen kann und Ich möchte mich heute auf ein anderes Terraform Thema beziehen, nämlich dem nahen Release von Terraform 0.12.

Zu dem Zeitpunkt wo ich diese Zeilen niederschreibe, ist auf der aktuellen Website von Hashicorp noch die Aktuelle Version 0.11.13 zu finden.

Aber Terraform hat uns schon vielversprechendes gezeigt mit dem 0.12.0-beta1 pre-release.

Damit kann man schon die vielen Erleichterungen, welche der neue Terraform Release mit sich bringt erahnen und auch schon antesten. Ich versuche die Änderungen Anhand eines kleinen Beispiels zu erläutern.
Vielleicht kann ich den einen oder anderen IaaS Codeschreiber, welcher sich hierfür interessiert, etwas auf den Geschmack zu bringen schon etwas zu testen mit der neuen Version.

Hier der Unterschied zwischen einer (aktuell 0.11.13) alten Terraform Version und einer neuen Version in Terraform 0.12 durch eine Gegenüberstellung.

main.tf (Random Tiernamen Beispiel)

variable "count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "zoo_enabled" { default = "0" } variable "prefix_liste" { default = [] } resource "random_pet" "my_pet" { count = "${var.count}" prefix = "${var.zoo_enabled == "0" ? var.default_prefix : element(concat(var.prefix_liste, list (""), count.index)}" }

main.tf HCL2 Version(Random Tiernamen Beispiel)

variable "pet_count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "prefix_list" { default = [] } resource "random_pet" "my_pet" { count = var.pet_count prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix }

Die Unterschiede fallen zuerst etwas weniger ins Auge, sind aber dafür meines Erachtens tiefgreifender für Leute, die IaaS Code schreiben müssen und dienen der Lesbarkeit des Codes.

Vorteil Nummer 1:
Im alten Beispiel musste noch mit “${var.count}” von einem String zu einer Number evaluiert werden. Mit der neuen HCL2 Schreibweise entfällt das, und es kann mit var.pet_count direkt der korrekte String oder Number Wert adressiert werden.

Vorteil Nummer 2:
Auch die Evaluierung der Liste prefix = “${var.zoo_enabled == “0” ? var.default_prefix : element(concat(var.prefix_liste, list (“”), count.index)}”  wird mit der neuen Notation der HCL2 wesentlich eingängiger. prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix ist prägnanter. Es entfällt auch die element(concat(x), list(“”), x ) Hack-Situation, um aus einer leeren Liste auch eine Liste mit einem NULL Element zum machen.

Weitere Vorteile: es gibt viel mehr was geändert worden ist, if you want to know more, klick here.

Ich hoffe ich habe euch nicht zu sehr gelangweilt mit C.O.D.E. kurz vor dem Wochenende.

Gruß David

 

David Okon
David Okon
Support Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...