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

Ansible – AWX|Tower State handling on Workflows

The Ansible Tower or its upstream AWX provides an easy to use GUI to handle Ansible tasks and schedules. Playbooks are configured as templates and as the name suggests, they can be modified to the needs, extended by variables, a survey or tags.

Furthermore those templates can be logically grouped, connected and visualised in Workflows.

The downside to those Workflows, all playbooks affected by this are executed separately and can’t access each others variables. On first glance we maybe only spot that we can define variables for the whole workflow but those are not changeable throughout the flow.

But there is a solution, which is the module set_stats. This module allows to save or accumulate variables and make them available for other playbooks within the workflow.

As an example we could use the monitoring environment when setting downtimes.

workflow

As a downtime is created before a maintenance and should be gone when the maintenance is done. This creates a dependency on the first task, which can be solved as we save the result of the first tasks with the set_stats module.


      - name: schedule downtimes
        icinga2_downtimes:
          state: "{{ downtime_icinga_state | default('present') }}"
          host: ***
          author: "{{ icinga2_downtimes_author | default('ansible_downtime') }}"
          comment: "{{ icinga2_downtimes_comment | default('Downtime scheduled by Ansible') }}"
          duration: "{{ icinga2_downtimes_duration | default(omit) }}"
        register: content
 
      - set_stats:
          data:
            downtime: "{{ content }}"

The content of the data will be now available to all playbooks included by the workflow. The variable is also shown as artefacts in the GUI.

artefacts

Keep in mind that the variable will be part of the extra variables for all other playbooks. As covered in the variable precedence it will overwrite any other variable named the same.

With this module you can reorganise your playbooks and connect them in workflows. This allows you to have a more flexible automation than before.

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening
Thilo Wening
Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

Ein simpler Installer für Icinga

Aus der anstehenden Überarbeitung des Icinga-Buchs habe ich mit dem Icinga-Installer ein Projekt gestartet, um Icinga in seiner Gesamtheit als Stack bestehend aus Icinga 2, Icinga Web 2, MariaDB oder PostgreSQL und Apache leicht und einfach zu installieren.

Der Installer basiert auf den Icinga-Puppet-Modulen und setzt auf das von The Foreman gepflegte Kafo Ruby-Gem-Projekt, das auch beim Foreman-Installer zum Einsatz kommt. Neben dem Puppet-Agent ist nur noch das Paket icinga-installer aus dem neuen Software-Repository https://packages.netways.de/extras erforderlich. Dort liegen Pakete für RHEL, Ubuntu und Debian bereit. Zur Zeit stehen Szenarien zur Installation eines Servers mit Icinga Web 2, Datenbank und Apache zur Verfügung, sowie zur Installation und Konfiguration eines Workers aka Satellit und als Agent.


$ icinga-installer -S server | worker | agent [-i] [--help]

Mit der Option -i kann der interaktive Modus gestartet werden, dort lassen sich dann Installations-Parameter ändern. Dort ist z.B. auch möglich von MariaDB auf PostgreSQL umzuschalten, das Logging anzupassen oder für den Fall eines dedizierten Datenbankservers die nötigen Anpassungen vorzunehmen. Alle diese Konfigurationen können ebenfalls über Optionen eingestellt werden, –help verrät mehr.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Monitoring-Plugins Software-Repository von NETWAYS

Ab sofort bieten wir unter https://packages.netways.de/plugins, die von uns meist genutzten Monitoring-Plugins als Pakete für RHEL 8 und 7, Debian Buster und Stretch, sowie Ubuntu Bionic Beaver und Focal Fossa zum Download an.

Zur Zeit überwiegen die RPM Pakete in der Anzahl, wir hoffen dies in den kommenden Wochen auszugleichen. Wir werden auch bemüht sein, das Angebot in den kommenden Wochen sukzessive zu erweitern. Gerne verfolgen wir dies auch innerhalb von Kundenprojekten, um diesen und allen anderen einen Zugang zu regelmäßig aktualisierten Plugin-Paketen anzubieten.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Icinga2 und Influx2: So bringen wir beide zum reden

Influxdata LogoAuch wenn die Überschrift es vermuten lässt. Das hier ist kein Clickbait sondern eine Kurzanleitung zum Thema.

Das Problem: Seitdem die time series database influxdb in der Version 2.0 erschienen es kann man das icinga2 influx feature nicht mehr ohne weiteres nutzen. Ein Grund ist, es gibt keine influx database und keine influx retention policy mehr. Beides ist konzeptuell jetzt in sogenannten buckets zusammengefasst. Damit nicht genug. Man greift nicht mehr mit einem user/password auf influx zu, sondern mit Hilfe eines Tokens

Die Lösung: Es gibt den v1 compatibility mode. So legt man einen bucket mit einer retention policy von 14 Tagen an und nutzt ihn.

$ influx bucket create --name icinga2 --org myCompany --retention 336h
$ influx bucket list
ID Name Retention Organization ID
9be740dd7f1e5dd0 _monitoring 168h0m0s e3010cef6e5b64bf
d6e0a548f3ea1451 _tasks 72h0m0s e3010cef6e5b64bf
4d59849554d88e25 icinga2 336h0m0s e3010cef6e5b64bf
$ influx v1 auth create --username icinga2 --write-bucket 4d59849554d88e25
$ influx v1 dbrp create --bucket-id 4d59849554d88e25 --db icinga2 --rp 14Tage

Das ganze lässt sich jetzt einfach auf Seiten Icinga nutzen:

$ cat /etc/icinga2/features-enabled/influxdb.conf

object InfluxdbWriter “influxdb” {
host = “127.0.0.1”
port = 8086
database = “icinga2”
flush_threshold = 1024
flush_interval = 10s
username = “icinga2”
password = “password”
enable_send_thresholds = true
enable_send_metadata = true
[…]
}

Nach einem icinga restart kann man im influx Frontend sehen, dass Informationen eingehen. Um mehr über influx und grafana zu lernen bietet Netways eine 2-tägige InfluxDB Schulung  an.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Veranstaltungen

Mi 16

stackconf online

Juni 15 - Juni 17
Di 29

Foreman Training | Nürnberg

Juni 29 @ 09:00 - Juni 30 @ 17:00
NETWAYS Headquarter | Nürnberg
Jul 01
Jul 06

Icinga 2 Advanced Training | Online

Juli 6 @ 09:00 - Juli 8 @ 17:00
Jul 13

GitLab Advanced | Online

Juli 13 @ 09:00 - Juli 15 @ 17:00