Monitoring Powershell scripts with Icinga 2


The need to to monitor arbitrary Powershell scripts comes up now and then and often there are some workarounds or alternatives, NSClient for example, named. However in order to have something I can link refer people to when the topic comes up again, I’ll try to provide a quick and simple to adapt solution. Keep in mind that this assumes you have Icinga 2 up and running on your Windows host, Powershell installed and are reasonably sane.

First the the check script I used for demonstration purposes in this case, all it does is check whether a process is running and returning OK or CRITICAL based on that.

if ($args.Length -lt 1) {
	Write-Output "Script requires one argument (Process)"
	Exit(3)
}

$proc=$args[0]

$state = Get-Process $proc -ErrorAction SilentlyContinue
if ($state) {
	Write-Output "PROCESS OK '$proc' is running"
	Exit(0)
} else {
	Write-Output "PROCESS CRITICAL '$proc' is not running"
	Exit(2)
}

Safe it as check_proccess.ps1 somewhere you can find it again. In this case I put next to the other check plugins.

The following are the check_command object and Service apply. And as it turns out it’s not that easy of a task as I thought, it’s mostly Windows fault really… Getting the exit code of a script from Powershell returned to icinga2 required some trickery (credit goes to NSClient for that one). The result is a bit of weird CheckCommand, which can and should be improved.

object CheckCommand "powershell" {
    import "plugin-check-command"
    command = [ "cmd" ]
    arguments = { 
        "Weird command" = { 
            value = "/c echo $powershell_script$ $powershell_args$ ; exit ($$lastexitcode) | powershell.exe -command -"
            description = "This is needed because powershell would not tell us the exit code otherwise"
            skip_key = true
        }
    }   
}

apply Service "check_powerpoint" {
    import "generic-service"
    check_command = "powershell"
    vars.powershell_script = PLUGIN_DIR + "\check_process.ps1"
    vars.powershell_args = "POWERPNT"
    assign where host.vars.os == "Windows"
}
Jean-Marcel Flach

Autor: Jean-Marcel Flach

Auch wenn man Anderes vermuten möchte: Jean ist nicht unser französischer Austauschazubi, sondern waschechter Bamberger. Die Uni war ihm zu langweilig, deshalb knöpft er sich nun im Development gleich die kniffligsten Aufgaben vor.

Alt, aber bewährt

Immer wieder geht es in der IT um Vergleiche,  z.B. bei der Web-Entwicklung (NodeJS vs. PHP), der Datenhaltung (MongoDB vs. SQL-Datenbanken) oder auch scheinbaren Kleinigkeiten wie das Einlesen einer Datei in den Arbeitsspeicher.

Letztgenannter Vorgang würde bspw. in der Programmiersprache C unter Linux und anderen POSIX-Systemen wie folgt aussehen (Prüfungen auf Fehler habe ich der Übersichtlichkeit halber weggelassen):

void* read_file(char const *path, size_t *length) {
    int fd;
    struct stat stats;
    void *buf, *pos;
    ssize_t current_read;
    size_t remain;
    
    fd = open(path, O_RDONLY);
    fstat(fd, &stats);
    buf = malloc(stats.st_size);
 
    pos = buf;
    remain = stats.st_size;
    for (;;) {
        current_read = read(fd, pos, remain);        
        if (current_read == 0) {
            break;
        }
 
        *(char**)&pos += current_read;
        remain -= (size_t)current_read;
    }
    
    close(fd);
    *length = stats.st_size;
    return buf;
}

Die Alternative dazu wäre die Verwendung von mmap():

void* read_file_via_mmap(char const *path, size_t *length) {
    int fd;
    struct stat stats;
    void *addr, *buf;
    
    fd = open(path, O_RDONLY);
    fstat(fd, &stats);
    addr = mmap(NULL, stats.st_size, PROT_READ, MAP_SHARED, fd, 0);
    buf = malloc(stats.st_size);
 
    memcpy(buf, addr, stats.st_size);
 
    munmap(addr, stats.st_size);
    close(fd);
    *length = stats.st_size;
    return buf;
}

Deren Verfechter werben damit, dass die Anzahl der Systemaufrufe pro Datei konstant ist. Dem kann ich nicht widersprechen – die Datei wird mit open() geöffnet und mit mmap() in den Adressbereich integriert. Damit kann auf den Inhalt zugegriffen werden als befände er sich im Arbeitsspeicher. Das ermöglicht das anschließende Kopieren mit Hilfe von memcpy().

Aber das hilft einem nur weiter, wenn das auch tatsächlich messbar Zeit spart – dies ist definitiv nicht der Fall:

aklimov@ws-aklimov:~$ time ./read garbage

real    0m8.108s
user    0m0.000s
sys     0m3.664s
aklimov@ws-aklimov:~$ time ./mmap garbage

real    0m8.099s
user    0m0.652s
sys     0m3.000s
aklimov@ws-aklimov:~$

Das Lesen einer Datei (3 GB) hat im konkreten Fall nicht viel weniger Zeit in Anspruch genommen. Die Verwendung von mmap() hat lediglich ca. 660 Millisekunden von der linken in die rechte Tasche transferiert. Um genau zu sein – die Systemaufrufe der konventionellen Methode (strace):

open("garbage", O_RDONLY)               = 3                                                                                                                                                  
read(3, "\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0"..., 3221225472) = 2147479552                                                      
read(3, "\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0\377\0"..., 1073745920) = 1073745920                                                      
read(3, "", 0)                          = 0
close(3)                                = 0

… vs. mmap():

open("garbage", O_RDONLY)               = 3
mmap(NULL, 3221225472, PROT_READ, MAP_SHARED, 3, 0) = 0x7ff5423c6000
munmap(0x7ff5423c6000, 3221225472)      = 0
close(3)                                = 0

Zwar benötigt die konventionelle Methode im konkreten Fall einen Systemaufruf mehr, aber angesichts der Dateigröße ist das meiner Meinung nach trotzdem vergleichsweise effizient.

Fazit

Nicht alles was glänzt ist auch Gold. Und mit Kaffeesatzlesen ist niemandem geholfen.

Alexander Klimov

Autor: Alexander Klimov

Alexander hat Ende 2013 mit einem Praktikum bei NETWAYS gestartet. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 und seiner Ausbildung bei uns friedliche Wege.

Monitoring-Projekt bei der htp GmbH

Die htp GmbH ist ein Provider im Bereich Telefon und Internet im Großraum Hannover und Braunschweig für geschäfts- und Privatkunden. Seit einiger Zeit unterstützen wir htp bei der Migration auf Icinga 2. Im Zuge dieses Umzuges wurde die neue Monitoring-Plattform verteilt mit einem mehrstufigen Satellitenkonzept realisiert. Herzstück sind zwei Satelliten an zwei unterschiedlichen Standorten der eigene RZ-Umgebung. Die beiden zu HA zusammengeschalteten Icinga 2 Instanzen sind je mit einem Braintower SMS Gateway gekoppelt, die das Mail-Benachrichtigungssystem um den Versand von SMS erweitern.

Diese beiden Knoten, die an den Icinga Master inklusive Icinga Web 2 angeschlossen sind, dienen ihrerseits als Kommunikationspartner für weitere Icinga 2 Satelliten zur Überwachung eigner Systeme oder dedizierten Kundenumgebungen.

Lennart Betz

Autor: Lennart Betz

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.

RIP Ubuntu 12.04 LTS

An era is coming to an end. Ubuntu 12.04 LTS was released in the spring of 2012. At the 28th of April 2017 the support for this Ubuntu Version will comming to a close.
Each user now has the task to upgrade to a newer version of Ubuntu.
As a hoster with the mission to take care of the systems of our customers, we have a scarily high number of servers we have to take care of. Even if we are up to this task, we still need the cooperation of our customers, as we have to prevent possible failures. And a few of our customers, don’t see the the problems, that we are up to in the future.

As i mentioned above, our mission is to keep the systems up and running, including new updates and the task of ensuring the security. But if we are not able to perform the upgrades, we won’t be able to ensure the security or to keep the system up to date.

A similar case will come up with Debian in May 2018. Debian 7,8 are available as LTS, which are maintained by the community (volunteers and companies, which are interested in it – but not by the Debian Security Team). Anyway, Debian 7 will be end of life at the 31st of May 2018.
So we will have to get trough the same topic again.

When the end of life of a distributions version approaches, it doesn’t mean that there won’t be any updates for the packages you have installed, but there won’t be any updates to keep your systems safe. And that is, what you should keep in mind.

The next releases of Ubuntu and wether they will be LTS, you can see in the diagram below. Ubuntu 14.04 will be supported until April 2019, so there will be enough time to think about a good strategy for upgrading.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Icinga 2 – Monitoring automatisiert mit Puppet Teil 1: Installation

Der erste Release vom Rewrite des Puppetmoduls zu Icinga 2 liegt nun auch schon einige Monate zurück und somit wird es Zeit sich im Zuge einer Blog-Serie genauer damit zu befassen. Zu beziehen ist das Module entweder über die Puppet Forge oder via GitHub.

Zu Beginn steht natürlich immer erstmal die “Installation” bzw. weil Puppet deklarativ arbeitet, die Beschreibung installiert zu sein. Schon hier zeigt sich das Modul flexibel und kann vom Benutzer angepasst benutzt werden. So greift puppet bei einer einfachen Deklaration ohne Parameter auf die auf dem System konfigurierten Repositories zurück. Es bietet jedoch auch die Möglichkeit für die unterstützten Plattformen RedHat, Debian, Ubuntu und Suse, die automatisch Einbindung der offiziellen Icinga-Repositories auf packages.icinga.com.

class { '::icinga2':
  manage_repo => true,
}

Betreibt man selbst ein internes Repository, z.B. als Spiegel des offiziellen, muss dieses vor der Deklaration der Klasse ::icinga2 erfolgen. Beispielhaft hier für RedHat-Systeme:

yumrepo { 'ICINGA-release':
  descr => 'ICINGA (stable release for epel)',
  baseurl => 'http://packages.icinga.org/epel/$releasever/release/',
  failovermethod => 'priority',
  enabled => '1',
  gpgcheck => '1',
  gpgkey => 'http://packages.icinga.org/icinga.key',
}
->
class { '::icinga2': }

Ein Problem beim Einsatz in verteilten Umgebungen und vor allem durch die Benutzung von Icinga als Agent ist die Software-Verwaltung. So sollte keine Instanzen miteinander kommunizieren die zwei Major Releases auseinander liegen, z.B. 2.6.x mit 2.5.x sollte noch ok sein, 2.6er mit 2.4.x und früher jedoch nicht. Besser ist jedoch die Benutzung ausschließlich von 2.6er Versionen. Setzt man hierfür kein Software-Management-Tool ein, kann Puppet helfen. Voraussetzung sollte jedoch ein Repository-Spiegel sein, den man nur zu gegebenen Zeitpunkten synchronisiert.

package { 'icinga2':
  ensure => latest,
}
->
class { '::icinga2':
  manage_package => false,
}

Damit wird bei jedem Puppetlauf dafür gesorgt, das die neuste Version installiert ist. Welche das ist, steuert man über den “händischen” Repo-Sync. Sind für einzelne Features zusätzliche Pakte erforderlich, müssen dann auch diese durch eigene Package-Resources verwaltet werden. Betroffen sind hier außer auf Windows oder FreeBSD die Features idomysql und idopgsql.
Auch das Handling des Icinga Services kann angeschaltet werden. Standardmäßig zieht jede Änderung an einer mit Puppet verwalteten Konfigurationsdatei einen Reload des icinga-Prozesses nach sich. Vor Version 1.2.0 von puppet-icinga2 wird allerdings noch ein Neustart ausgelöst. Für den Fall, dass lediglich zu bestimmten Zeiten eine neue Konfiguration eingelesen werden soll, kann man wie folgt vorgehen:

schedule { 'everyday':
  range  => '2 - 4',
  period => daily,
  repeat => 1,
}

class { '::icinga2':
  manage_service => false,
}
~>
service { 'icinga2':
  ensure => running,
  enable => true,
  schedule => 'everyday',
}

Zu bedenken ist hier nur der Nachteil, dass auch nur zwischen 2 und 4 nachts der Dienst wieder gestartet wird, falls er nicht laufen sollte. Aber dafür gibt es ja das Monitoring. Abschließend für Heute kann nicht unerwähnt bleiben, auch um benötigte Plugins darf sich der Benutzer selbst kümmern. Hierbei ist die Reihenfolge, ob erst die Plugins und dann Icinga oder umgekehrt, unerheblich.

Lennart Betz

Autor: Lennart Betz

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.

Location-Aware Settings With ControlPlane

Part of my “arriving at the office in the morning” ritual involves quitting all my personal applications (e.g. Sonos), re-enabling my work e-mail account and a whole slew of other tiny changes that differentiate my work environment from my home environment. While in itself this isn’t too much of a hassle it does get rather tedious after a while. Especially so if I forget to start certain apps like my Jabber client and don’t realize that until much later.

The ControlPlane application promises to solve this exact problem by running specific actions whenever it detects a location change.

In order to do this you first have to set up “contexts”: These are essentially the locations you want ControlPlane to be aware of. As a starting point I’ve created two contexts “Home” and “Work” for my most-frequently used locations:

The next step involves telling ControlPlane what kind of information it should use to determine where you are. ControlPlane supports a wide variety of so-called evidence sources for this, some of which include:

  • IP address range, nearby WiFi networks
  • Attached devices (screens, USB and bluetooth devices)
  • Bonjour services (e.g. AppleTV)

Once you’ve made up your mind about which evidence sources to use you need to actually configure rules for these sources. An example would be “If my laptop can see the WiFi network ‘netways’ I’m in the ‘Work’ environment.” You also get to choose a confidence rating for each of those rules. This is useful if some of your rules could potentially also match in other, unrelated environments – for example because the IP address range you’re using at work is also commonly used by other companies.

Once you’re sufficiently confident that your location detection rules are working reliably you can set up actions which ControlPlane automatically performs whenever you enter or leave a certain location:

For my personal use I’ve found the built-in library of actions to be quite useful. However, there are a few things that even ControlPlane doesn’t support out of the box – like disabling specific e-mail and Jabber accounts. Luckily it does let you can run arbitrary external applications, including ones you’ve built with macOS’s Script Editor application:

Gunnar Beutner

Autor: Gunnar Beutner

Vor seinem Eintritt bei NETWAYS arbeitete Gunnar bei einem großen deutschen Hostingprovider, wo er bereits viel Erfahrung in der Softwareentwicklung für das Servermanagement sammeln konnte. Bei uns kümmert er sich vor allem um verschiedene Kundenprojekte, aber auch eigene Tools wie inGraph oder Icinga2.