pixel
Seite wählen

NETWAYS Blog

Icinga for Windows v1.6.0 – Einfacher. Zentraler. Sicherer.

Die Kollegen von Icinga haben letzte Woche Icinga for Windows in Version v1.6.0 veröffentlicht. Auch wenn diese Version keine neuen Plugins für die Überwachung bietet, hat sich im Bereich des Icinga PowerShell Frameworks einiges getan. Dadurch ist die Lösung nicht nur einfacher zu verwenden, sondern auch noch zentraler verwaltbar und sicherer.

Dürfen wir vorstellen: Die IMC

Die IMC (Icinga Management Console) wurde im Rahmen vergangener Icinga for Windows als experimental eingeführt. Ziel war es, ein einfaches Management zu schaffen, um die meisten Funktionalitäten über eine UI abbilden zu können. Dadurch ist es nicht mehr notwendig, sich alle Befehle von Icinga for Windows zu merken oder diese zu kennen – sondern die Konfiguration erfolgt direkt darüber.

Im Zuge der Einführung der IMC, wurde ebenfalls ein neuer Setup Wizard generiert, welcher nicht nur einfacher und intuitiver ist als der alte, sondern auch noch über eine Hilfe verfügt, welche einem erklärt, welche Eingaben im jeweiligen Bereich notwendig sind und was diese bedeuten. Die Konfiguration ist hierbei im nicht-advanced Modus auf die absoluten Grundlagen beschränkt, um schnell ans Ziel zu kommen. Die restlichen Einstellungen im advanced Teil, können simpel eingesehen und geändert werden, wurden jedoch so ausgewählt, dass man in vielen Umgebungen auf eine Änderung sogar verzichten könnte.

Zentrale Verwaltung mit Repositories

Einer der großen Kritikpunkte an Icinga for Windows war die Komponenten Installation. Bisher musste jede Komponente einzeln heruntergeladen und mit einem Pfad bei der Installation hinterlegt werden. Mit Icinga for Windows v1.6.0 wurde nun ein Repository-Management hinzugefügt. Hierdurch können direkt entweder die offiziellen Repositories von Icinga for Windows auf packages.icinga.com angebunden werden oder ein eigenes, zentrales. Icinga for Windows bietet dabei die Möglichkeit, vorhandene Repositories zu synchronisieren, um diese in seiner lokalen Umgebung zu spiegeln. Dadurch kann die Installation von Systemen, welche nicht in das Internet können, deutlich vereinfacht werden. Ein Beispiel wäre hier, die offiziellen Icinga Repositories auf seinen Icinga 2 Master zu synchronisieren, um dort ein Repository für alle Systeme bereitzustellen.

Im Falle von DMZ Systemen kann das Repository wiederum von zentralen Icinga 2 Master auf Icinga Satellitensysteme synchronisiert oder aber auf zentrale File-Shares abgelegt werden, um von dort die Komponenten zu installieren. Für das Update von Repositories gibt es ebenfalls Kommandos, die eine Aktualisierung ermöglichen.

Der Vorteil des Repositories liegt darin, dass direkt die aktuellen Versionen der jeweiligen Komponenten installiert oder mit einem simplen Befehl die gesamte Umgebung aktualisiert werden kann. Sollte es aus bestimmen Gründen notwendig sein, kann die Version von einzelnen Komponenten auch gelockt werden. Das bedeutet, sofern eine ältere Version installiert ist, wird bis zur gelockten Version aktualisiert. Ist bereits die gelockte Version installiert und eine neue verfügbar, wird diese übersprungen.

Weitere Details hierzu gibt es direkt in der Icinga for Windows Repository Dokumentation.

Mehr Sicherheit durch JEA

JEA steht für Just-Enough-Administration und ist eine Lösung von Microsoft für PowerShell. Durch JEA können einzelne Benutzer, welche keine Administratoren sind, Befehle mit erhöhten Rechten im System Kontext ausführen. Die Funktionalität ist dabei ähnlich wie sudo auf Linux.

In der Vergangenheit gab es des Öfteren Probleme, das diverse Überwachungsmöglichkeiten nicht genutzt werden können, da der Benutzer beispielsweise nicht in der Hyper-V Administrator Gruppe ist und deshalb den Status der virtuellen Maschinen nicht abfragen kann. Ein weiteres Problem ergibt sich auch, wenn man diverse Services oder Tasks überwachen möchte, welchen mit einem normalen Standardbenutzer nicht eingesehen werden können.

Durch ein JEA-Profil wird es erlaubt, dass ein bestimmter Benutzer diese Plugins nun im Systemkontext mit erhöhten Rechten ausführt. Dabei wird von Icinga for Windows ein Profil basierend auf allen installierten Komponenten erstellt. Dieses Profil deckt jedoch nur die notwendigen Befehle zum Ausführen von Plugins und Komponenten ab. Für Icinga for Windows notwendigen Befehle für das Management der Umgebung, werden dabei nicht berücksichtigt.

Um das ganze abzurunden und die Trennung perfekt zu machen, bietet Icinga for Windows die Möglichkeit an, einen Managed User mit dem Namen icinga anzulegen. Dieser Benutzer ist ein lokaler Benutzer auf dem System, ohne Berechtigungen sich lokal oder per RDP anzumelden. Der einzige Zweck ist, dass er als Service Benutzer fungiert und den Icinga Agent sowie den Icinga for Windows Dienst startet. Im Zusammenspiel mit dem von Icinga for Windows generierten JEA-Profil, kann dann das System vollständig überwacht werden. Die Verwaltung des Benutzers obliegt dabei vollständig Icinga for Windows und im Rahmen der Erstellung des Benutzers oder bei diversen Änderungen an den Services während der Icinga for Windows Installation oder Updates, wird jedes Mal ein neues, zufälliges 60-stelliges Password generiert und dem Benutzer zugewiesen. Dieses Password wird nach Ende der jeweiligen Installationsschritte intern wieder verworfen und wird nirgends abgelegt. Hierdurch wird eine Kompromittierung des Systems ohne bereits vorhandene Administratorrechte deutlich erschwert.

Weitere Details sowie Anforderungen, finden sich direkt in der Icinga for Windows JEA Dokumentation.

Performance Gewinn durch API-Check Forwarder

Ein weiteres Thema welches mit Icinga for Windows v1.6.0 von experimental als stabil gilt, ist der API-Check Forwarder, welcher in vergangenen Versionen eingeführt wurde. Hintergrund dieser Lösung ist, dass das Starten sowie die Ausführung von PowerShell Befehlen innerhalb der von Icinga 2 gestarteten Shells vor allem bei Systemen mit weniger Kernen eine erhöhte Systemlast verursachen. Durch den API-Check Forwarder wird zumindest der Ausführungsteil ausgelagert, da alle Befehle für die Plugin-Ausführung innerhalb des Icinga for Windows Dienstes durchgeführt und lediglich das Ergebnis an die lokale Shell weitergereicht wird.

Für diese Lösung werden zwei zusätzliche von Icinga bereitgestellte Komponenten benötigt, um eine REST-Api bereitzustellen sowie die Checks per API auszuführen. Beides kann direkt über die neuen Icinga Repositories installiert werden. Für eine sichere Verbindung werden direkt die Zertifikate des Icinga Agent verwendet. Nach Bedarf können jedoch auch eigene Zertifikate verwendet werden. Wichtig dabei ist, dass eine Erstellung des REST-Api Sockets ohne ein TLS Zertifikat nicht möglich ist.

In der zugehörigen Dokumentation zum API-Check Forwarder von Icinga for Windows gibt es weitere Details.

Was bringt die Zukunft?

Die nächste Version von Icinga for Windows v1.7.0 ist bereits zur diesjährigen OSMC eingeplant. Hier werden wir noch weiter den Schwerpunkt auf Performance sowie eine Vielzahl von Optimierungen für Entwickler legen, um es noch einfacher zu machen eigene Plugins und Komponenten zu entwickeln. Ein entsprechender Talk ist ebenfalls eingereicht.

Wir freuen uns auf eine rege Teilnahme und wünschen bis dahin alles Gute!

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

Meerkat (Dashboard für Icinga 2)

Was ist Meerkat? Wie kann man Meerkat installieren, und konfigurieren?

Meerkat ist ein Dienstprogramm, geschrieben in go und javascript, und nicht nur zum Erstellen und Teilen von Dashboards für Icinga 2 geeignet, sondern auch leicht zu installieren und bedienen. Meerkat hat ein Web-Interface, in dem man Dashboards mit beliebigem Hintergrund und Elemente festlegt und aktualisiert, wobei das Meerkat-Backend Abfragen an die Icinga-2-Api zur Darstellung des Status schickt. Hier werden wir Meerkat installieren und konfigurieren und zudem auch Dashboards – als Beispiel für die verschiedenen Visualisierungen und darstellbaren Objekte – bauen.

  • Hier wird Meerkat  mittels Docker als Container installiert, wofür die Installation von docker und docker-compose erforderlich ist.
  • Es gibt auch die Möglichkeit, Meerkat ohne Docker zu installieren.
  • Meerkat wird auf Centos7 mit aktiviertem SELinux installiert, weshalb die SELinux-Berechtigungen für Schreiben und Lesen bei den ContainerVolumes zu beachten sind.

 

Installation

Wir laden zuerst die Meerkat-Repository runter und passen die Konfiguration-Datei docker-compose.yml an, wobei hier nur die Mount-Option Z gesetzt wird, damit das SELInux-Label für private Volumes gesetzt werden und die Volumes lesbar und beschreibbar eingehängt werden können.

Zunächst wird der Meerkat-Zugriff auf das Icinga-2-System konfiguriert – wie vorhin erwähnt, erfolgt dieser über API-Anfragen. Dafür legen wir eine API-User auf dem Icinga-2-System an und starten den Icinga2-Service neu. Danach muss die Datei meerkat.toml auf dem Meerkat-System angepasst werden. Im Anschluss können wir den Meerkat-Container starten!

 

Auf dem Host für den Meerkat-Container:
$ git clone https://gitlab.sol1.net/oss/meerkat.git
$ vim ~centos/meerkat/docker-compose.yml
...
    volumes:
      - ./config:/meerkat/config:Z
      - ./dashboards:/meerkat/dashboards:Z
      - ./dashboards-data:/meerkat/dashboards-data:Z
...
 
 
Auf dem Icinga-2-System:
$ vim cd /etc/icinga2/conf.d/api-user.conf
object ApiUser "meerkat" {
  password = "meerkatpassword"
permissions = [ "objects/query/Host""objects/query/Service"
"objects/query/ServiceGroup""objects/query/HostGroup" ]
}
$ systemctl restart icinga2.service
Auf dem Host für den Meerkat-Container:
$ cd ~centos/meerkat/config
$ cp meerkat.toml.example meerkat.toml
$ vim meerkat.toml
 
HTTPAddr = "[::]:8585"
IcingaURL      = "https://icinga.example.com:5665"
IcingaUsername = "meerkat"
IcingaPassword = "meerkatpassword"
IcingaInsecureTLS = true
 
$ cd ~centos/meerkat
$ docker-compose up
Zunächst loggen wir uns in den Container ein, um herauszufinden, welcher User der Besitzer von dem meerkat-Prozess im Container ist. Anhand der User-ID legen wir einen User auf dem Host-System an und berechtigen ihn Zugang zu den Verzeichnissen, um darunter neue Dashboards anlegen zu können.
$ docker exec -it meerkat_app_1 /bin/sh
/meerkat $ ps -ef
PID   USER     TIME  COMMAND
1 9001      0:00 /meerkat/meerkat -config /meerkat/config/meerkat.toml
27 9001      0:00 /bin/sh
33 9001      0:00 ps -ef
$ sudo useradd -u 9001 meerkat 
$ sudo chown meerkat:meerkat dashboards/ dashboards-data/

 

Meerkat Web-Interface

Nachdem der Meerkat-Container installiert und aktiviert ist, rufen wir das Meerkat-Webinterface auf. Hier habe ich ein paar Dashboards zum Testen gebaut.

  • Create New Dashboard: Dashboardsname eingeben.
  • Background Image: Hintergrund hochladen – hier kann man jedes Bild-Format hochladen, welches im Browser angezeigt werden kann. Getestet wurden die Formate PNP,JPEG,WebP und GIF.
  • Global Status Alerts: Hier kann man den status-alert festlegen – Meerkat bietet neben Visual-Aufbau auch die Möglichkeit, einen status-alert-sound für verschiedene Status festzulegen. In diesem Projekt habe ich diese auf Mute eingestellt.
  • Element: Hier werden die ElementEigenschaften festgelegt, wie Visual-Type (also in welcher Form das Element auf dem Hintergrund angezeigt werden soll) und Element-Type (für Host, Service, Groups oder Filter).
  • Linking URL: Man kann das Element zu einer URL linken.
  • Performance Data: Es gibt die Möglichkeit, Abfragen, die einen Performance-Wert haben, anzeigen zu lassen.

 

Icinga SVG (für Hosts)

 

Icinga Card (für Hosts und Services)

Icinga Image, static Image und Text, Icinga Line

Im folgenden Beispiel sieht man die restlichen Element-Typen wie Icinga-Image (Status-Element für Hosts), static-Image (Logo), static-Text (IP-Adressen) und Icinga-Line (SSh-Verbindung Status).

Saeid Hassan-Abadi
Saeid Hassan-Abadi
Junior Consultant

Saeid hat im September 2019 seine Ausbildung zum Fachinformatiker im Bereich Systemintegration gestartet. Der gebürtige Perser hat in seinem Heimatland Iran Wirtschaftsindustrie-Ingenieurwesen studiert. Er arbeitet leidenschaftlich gerne am Computer und eignet sich gerne neues Wissen an. Seine Hobbys sind Musik hören, Sport treiben und mit seinen Freunden Zeit verbringen.

Icinga Installation mit Director in 10 Minuten

Herausforderung angenommen. Helfen wird mir der Icinga-Installer und das Director-Installations-Paket aus unserem Extras-Repository. Das hier folgende Beispiel werde ich auf einem RHEL8 durchführen, ist aber auch für Debian und Ubuntu zu adaptieren, da der Installer als auch der Director als Pakete zur Verfügung stehen.

Neben dem angesprochen Extras-Repository für Icinga-Addons wird ein Puppet-Agent benötigt, der Installer ist Puppet-basiert und benötigt keinen zentralen Puppet-Server.


$ dnf install -y https://yum.puppet.com/puppet6/puppet6-release-el-8.noarch.rpm
$ dnf install -y https://packages.netways.de/extras/epel/8/noarch/netways-extras-release/netways-extras-release-8-1.el8.netways.noarch.rpm
$ dnf install -y icinga-installer

Der Installer kann nun out-of-a-box verwendet werden, er installiert einen Icinga-Server inkl. Icinga Web 2 mit Apache und FPM, der benötigten Datenbanken des gewählten Typs und das Business-Prozess-Modul.


$ icinga-installer -S server-ido-mysql

Soll anstatt MariaDB ein PostgreSQL zum Einsatz kommen, ist als Szenario (Option -S) server-ido-pgsql anzugeben. Jetzt wird die Installation und Konfiguration je nach Internetanbindung einige Zeit in Anspruch nehmen. Zuerst werden automatisch zusätzlich das Icinga- und das NETWAYS-Plugins-Repository eingebunden, auf RHEL-basierten Systemen auch noch EPEL. Aus diesen werden alle benötigten Pakete bezogen.

Der Installer wäre auch in der Lage eigene, lokale oder generell alternative Repositories anzusteuern, spränge aber den Rahmen dieses Posts. Es sei nur verraten, mit der Option -i wechselt man für den Installer in den interaktiven Modus.

Nach Abschluss kann Icinga wie üblich mittels /icingaweb2 auf Port 80 (HTTP) erreicht werden. Der initial eingerichtet Admin-Account ist der Benutzer icingaadmin mit dem Password icinga.

Der Director muss z.Z. noch per Hand installiert und konfiguriert werden. Eine Integration in den Installer ist für die kommende Version geplant. Somit muss auch die Datenbank, hier MySQL, per Hand angelegt werden.


$ dnf install -y icingaweb2-module-director
$ mysql -e "CREATE DATABASE director CHARACTER SET 'utf8';
CREATE USER director@localhost IDENTIFIED BY 'some-password';
GRANT ALL ON director.* TO director@localhost;"

Abschließend ist dann nur noch der schon aktivierte Director in der Weboberfläche wie gehabt zu konfigurieren und für den Director erforderliche Daemon icinga-director zu starten. Fertig.


$ systemctl start icinga-director
$ systemctl enable icinga-director

Plugins sind gesondert zu installieren. Eine kleine Vielzahl kann zusätzlich zu den Standard-Monitoring-Plugins über das bereits eingebunden Plugins-Repo installiert werden. Diese Plugins tragen alle netways als Präfix im Paketnamen.

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.

Icinga Plugins in Golang

Golang ist an sich noch eine relativ junge Programmiersprache, ist jedoch bei vielen Entwicklern und Firmen gut angekommen und ist die Basis von vielen modernen Software Tools, von Docker bis Kubernetes.

Für die Entwicklung von Icinga Plugins bringt die Sprache einige hilfreiche Konzepte mit. Golang baut fertige Binaries, Plugins können also zentral kompiliert und ohne große Abhängigkeiten verteilt werden. Alle Abhängigkeiten werden im Rahmen vom Bauprozess abgedeckt, die einzige Unterscheidung liegt in der Ziel Architektur, also Linux, Windows, Mac oder ähnliches, sowie ob 32 oder 64 bit.

Viele Funktionen und Packages (vergleichbar mit Libraries) kommen entweder direkt mit Golang mit oder können leicht aus der Open Source Community verwendet werden. Mit dem Package go-check von uns haben wir eine kleine Basis geschaffen, um leichter Plugins schreiben zu können, ohne sich zu sehr im Code wiederholen zu müssen.

Als ganz einfaches Go Plugin hier ein Beispiel eine “main.go” Datei:

package main

import (
	"github.com/NETWAYS/go-check"
)

func main() {
	config := check.NewConfig()
	config.Name = "check_test"
	config.Readme = `Test Plugin`
	config.Version = "1.0.0"

	_ = config.FlagSet.StringP("hostname", "H", "localhost", "Hostname to check")

	config.ParseArguments()

	// Some checking should be done here, when --help is not passed

	check.Exitf(check.OK, "Everything is fine - answer=%d", 42)
}

Alles was man noch tun muss, ist das Plugin zu kompilieren oder direkt auszuführen:

go build -o check_test main.go && ./check_test --help
go run main.go

Ein guter Einstieg in Go findet man über die Dokumentation, die Tour und vor allem in dem man sich umschaut, was die Community an Packages zu bieten hat.

Natürlich bleibt die Frage, wie überwache ich das Ding was mir wichtig ist, wofür es aber noch kein Plugin gibt. Gerade dort helfen wir von NETWAYS mit unseren Consulting und Entwicklungsleistungen.  Beispiele unserer Go Plugins findet man auf GitHub unter der NETWAYS Organisation.

 

Markus Frosch
Markus Frosch
Principal Consultant

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

Dynamische Formulare in Icinga Web 2

In meinem letzten internen Projekt der NETWAYS durfte ich ein Icinga Web 2 Module bauen, welches ein dynamisches Formular verwenden soll. Konkret sollte es mehrere Dropdown-Menüs geben, welche den Wert des vorherigen Dropdown-Menü evaluiert und anhand dessen, ein neues Dropdown befüllt. Dabei kann man zwei Herangehensweisen benutzen, welche ich im Folgenden erläutere.

Die klassische (schlechte) Herangehensweise

Die erste Möglichkeit, die mir in den Sinn kommt, ist, dass man sich über AJAX verschiedene Actions in Icinga Web 2 aufruft. Diese wiederum besitzen einen Code, der den Wert des zuvor ausgewählten Wertes evaluiert und das weitere Dropdown befüllt. Da Icinga Web 2 einem MVC (Modell, View, Controller) Muster folgt, wird ein Controller- für die Steuerung und ein View-Script für die Darstellung benötigt. Des Weiteren wird für den AJAX Request eine eigene module.js Datei benötigt, in der der JavaScript Code hinterlegt ist. Darüber hinaus müsste man noch CSS einbinden, damit das Formular auch noch schön dargestellt wird.

Alles im Allem, eine sehr sehr aufwendige Herangehensweise!

Die richtige Herangehensweise

Wie oben erwähnt, handelt es sich bei Icinga Web 2 um ein MVC, somit ist es auch möglich, bestimmte “ConfigForm-Views” zu erstellen, die bereits alle benötigten Sachen zur Verfügung stellen: CSS, JavaScript und HTML. Das beste daran ist, dass dies super einfach zu implementieren ist und das Framework die ganze Arbeit von der “schlechten Herangehensweise” übernimmt.
Man kann einer Configform die Klasse autosubmit mitgeben, dadurch erhält man ein Verhalten wie ein AJAX-Request. Im Folgenden ein kleiner Ausschnitt eines solchen ConfigControllers:

<?php
    namespace Icinga\Module\Testmodule\Forms\Test;
    use Icinga\Web\Form;
 
    class TestForm extends Form 
    {
      public function init()
      {
        $this->setName('form_test_form');
        $this->setSubmitLabel('Save Changes');
      }

      public function createElements(array $formData)
      {
          // Load cars
          $this->addElement(
              'select',
              'car',
              array(
                  'label' => $this->translate('Car'),
                  'multiOptions' => [
                      '' => '(select option)',
                      'audi' => 'Audi',
                      'vw' => 'VW'
                  ],
                  // 'autosubmit' acts like an AJAX-Request
                  'class' => 'autosubmit'
              )
          );

          // Select model
          if (isset($formData['car']) && $formData['car'] === 'audi') {
              $this->addElement(
                  'select',
                  'model',
                  array(
                      'label' => $this->translate('Model'),
                      'multiOptions' => [
                          '' => '(select model)',
                          'A1',
                          'A6'
                      ],
                      'required' => true,
                  )
              );
          } elseif (isset($formData['car']) && $formData['car'] === 'vw') {
              $this->addElement(
                  'select',
                  'model',
                  array(
                      'label' => $this->translate('Model'),
                      'multiOptions' => [
                          '' => '(select model)',
                          'Golf',
                          'Polo'
                      ],
                      'required' => true,
                  )
              );
          }
      }  
    }

Wenn man nun noch das View-Script einbindet erhält man eine Form, die wie folgt aussieht:



Durch das Framework von Icinga Web 2 ist es möglich, sehr schnell ein Modul nach eigenen Wünschen zu erstellen. Wem ich damit nun Lust auf ein bisschen Programmierung gemacht habe, dem kann ich die bereits vorhandenen Trainingsunterlagen auf Github empfehlen! Oder Ihr besucht eine unserer verschiedenen Konferenzen, bei der man auch mal detailliertere Einblicke wie z.B. Icinga Web 2 Modul Programmierung erhält.

Philipp Dorschner
Philipp Dorschner
Developer

Philipp hat im Jahr 2017 die Ausbildung zum Fachinformatiker – Systemintegration bei NETWAYS Professional Services begonnen. Während der Ausbildung bekam er ein immer größeres Interesse am Programmieren. Das führte dazu, dass Philipp nach erfolgreich bestandener Ausbildung die Kollegen aus Professional Services nicht nur als Consultant sondern auch als Entwickler tatkräftig unterstützt. Neben seinem Interesse an der Informationstechnologie, macht er Sport im Freien oder liest bei schlechtem Wetter auch gerne mal ein Buch zu Hause.

Trainings

Web Services

Events