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.

Wird auch mal Zeit, dass einer reagiert…

Dass unsere Gesellschaft es sich gut und gerne möglichst bequem macht hat Bernd schon hinreichend ausgeführt.

Dies gilt allerdings nicht nur im politischen Kontext, sondern auch im IT-Kontext.

Paradebeispiel

M$ Windows gehört aktuell der Löwenanteil des Desktop-PC-Marktes – aber nicht unbedingt der Qualität wegen, sondern u.a. aus folgendem Grund:

Einige (vor allem im gewerblichen Bereich) häufig unumgängliche “Killer-Apps” wie M$ Office oder Adobe Photoshop laufen schlichtweg nur auf Windows (oder Mac OS).

Um von diesem hoch unsicheren, kostenpflichtigen, spionierenden und nicht-quelloffenen Betriebssystem wegzukommen, muss der Benutzer zumindest folgende Hürden überwinden:

  • (darauf kommen, dass überhaupt ein Betriebssystem außer Windows und Mac OS existiert)
  • bspw. GNU/Linux herunterladen und auf CD/DVD/USB-Stick brennen
  • davon booten und das System installieren
  • sich in das System und die Unterschiede zu Windows einarbeiten
  • Alternativen für ihre Killer-Apps suchen (sofern überhaupt vorhanden!)
  • sich in letztgenannte einarbeiten…

In solchen Fällen habe ich volles Verständnis für den Sieg der Faulheit. Henry Ford hat mal gesagt:

Denken ist die schwerste Arbeit, die es gibt. Das ist wahrscheinlich auch der Grund, warum sich so wenige Leute damit beschäftigen.

Aber das geht auch viel einfacher – ohne als böser Raubkopierer vom rechten Weg abzukommen – mit …

ReactOS

ReactOS ist keine GNU/Linux-Distribution, die es sich zur Aufgabe gemacht hat, Windows äußerlich möglichst ähnlich zu sehen.

Es ist ein eigenständiges, von Grund auf geschriebenes Betriebssystem, dessen Ziel es ist, möglichst vollständig zu Windows kompatibel zu sein.

Ich selbst habe ReactOS ausprobiert und teile meine Erfahrungen hier mit euch…

Ran an die Buletten!

Wie üblich habe ich das OS in einer virtuellen Maschine ausprobiert – konkret mit VirtualBox. Nachdem ich das ISO-Abbild heruntergeladen habe erstellte ich eine neue virtuelle Maschine…

Es ist wichtig, dass das Modell der (virtuellen) Netzwerkkarte mit dem von mir gewählten übereinstimmt (3. Bild) – sonst kann es passieren, dass das Netzwerk überhaupt nicht funktioniert.

Sobald der Bootvorgang abgeschlossen war, fand ich einen Windows-XP-ähnlichen Assistenten vor – mit dem Unterschied, dass ich die Sprache frei wählen konnte. (Pfeiltasten oben/unten, dann Eingabetaste)

Sobald das vollbracht ist, muss eigentlich nur noch die Eingabetaste malträtiert werden, bis dieser Assistent durch ist…

Dann gilt es einen Neustart abzuwarten. Beim darauf folgenden Assistenten muss man fast genau so wenig den Kopf anstrengen.

Ich habe zwar Name und Organisation angegeben, hätte aber auch genau so gut immer nur direkt “weiter” drücken können…

Nachdem einem weiteren Neustart kann man auch schon loslegen. Fehlermeldungen wie diese habe ich für meinen Teil bedenkenlos weggeklickt:

Aber…

Da war noch was…

Ein gesunder Geist in einem gesunden Körper. Und ein guter Web-Browser auf einem guten Betriebssystem.

Ich habe die Firefox-Versionen 3.6, 28 und 45 aus dem ReactOS-Paketmanager (Ja, Paketmanager! 😀 ) ausprobiert und meine, dass 28 aktuell der beste Kompromiss aus Funktionalität und Stabilität ist…

Fazit

Ist ReactOS nun für den Produktivbetrieb zu empfehlen?

Meiner Meinung nach noch definitiv nicht.

Neben der o.g. mangelhaften Unterstützung von Netzwerkkarten ist das System (… wie sagt man da noch gleich politisch korrekt …) leicht absturzgefährdet.

Konkret habe ich versucht, mir Visual Studio 2015 Community herunterzuladen (erstmal nur herunterzuladen!) …

(-.-“)

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.

Icinga 2 Best Practice Teil 2: Konfiguration synchronisieren

Im heutigen Teil 2 dieser Serie, befassen wir uns mit Konfiguration und deren Synchronisation zwischen Icinga 2 Instanzen in verteilten Umgebungen. Hierbei ist eine solche verteilte Umgebung schon gegeben, wenn der Agent zum Einsatz kommt, also immer wenn Endpoints und Zones beteiligt sind. In Teil 1 wurde Tipps zur Konfiguration der Verbindungsdaten gegeben, heute vertiefen wir, was auf dem Agenten passiert und was dort zusätzlich zum Icinga 2 Core benötigt wird.
Zuerst werden die jeweiligen Plugins auf den Agenten benötigt, seien es für Linux die Monitoring-Plugins oder auf der Windows-Seite die nativen aus dem Icinga-Projekt oder die Plugins vom NSClient++. Bei Icinga, auch in der neuen Version 2, ist das Objekt vom Typ CheckCommand das Bindeglied zwischen Host- bzw. Service-Objekt und dem konfigurierten Plugin, was zur Statusermittlung aufzurufen ist. Wobei ein lokal auszuführender Host-Check üblicherweise nicht Praxisrelevant ist. Das CheckCommand beschreibt wie das Plugin aufzurufen ist, den Ort im Dateisystem wie auch mit welchen Optionen das Plugin ausgeführt wird.

object CheckCommand "mem" {
  command = [ PluginContribDir + "/check_mem.pl" ]

  arguments = {
    "-u" = {
      set_if = "$mem_used$"
      description = "Check USED memory"
    }
...

Für die Pfadangabe zum Plugin ist immer die Verwendung einer Konstanten zu empfehlen, da sich der Ort von Plattform zu Plattform unterscheiden kann und eine Konstante ist für jede Instanz und damit für jeden Agenten gesondert setzbar. Standardmäßig sollten Konstanten in constants.conf im Icinga-Konfigurationsverzeichnis definiert werden.
Beim Plugin check_mem.pl im obigen Beispiel handelt es sich nicht um eines vom Monitoring-Plugin-Projekt, sondern um eines was gesondert auf den Agenten zu installieren ist. Ausserdem benötigen die Icinga-Instanzen der Agenten obige Definition. Für das CheckCommand mem wird diese schon in der ITL (Icinga Template Library) mit geliefert und muss nicht selbst erstellt werden. Auf den jeweiligen Agenten ist lediglich die Definition in icinga2.conf als include einzubinden. Sie befindet sich im PluginContrib-Bereich der ITL.

include <plugins>
include <plugins-contrib>  

In plugins hingegen befinden sich die Definitionen zu Plugins aus dem Monitoring-Projekt. Bei Windows empfiehlt sich die Definitionen der nativen (windows-plugins) bzw. NSClient++-Plugins (nscp) einzubinden.
Was aber nun, wenn man nun für ein Plugin selbst ein CheckCommand-Objekt anlegen muss? Es jeweils auf allen Agenten in die ITL legen? Nein, der ITL-Bereich ist ausschließlich für vom Projekt gepflegte Objekte, eigene würden beim nächsten Update wieder verschwinden. Ausserdem ist eine zusätzliche Pflege von sich ändernden Konfigurationsdateien für jeden Agenten nicht erstrebenswert. Hier kommen nun globale Zonen ins Spiel, die einem Konfiguration auf beliebige Endpoints synchronisieren und automatisch laden.

object Zone "linux-commands" {
  global = true
}
object Zone "windows-commands" {
  global = true
}

Im Gegensatz zum Server bzw. Master und Satelliten-Systemen, ist auf den Windows- und Linux-Agenten nur die entsprechende Zone in der zones.conf einzutragen. In beiden werden auch wirklich nur CheckCommands hinterlegt, Services und Templates werden in der Regel nicht auf Agenten benötigt und sind damit Informationen die besser nicht leicht zugänglich sowie zentral gehalten werden.
Windows kennt leider keinen graceful restart bzw. reload wie Unixsysteme und somit ist hier die Trennung sinnvoll, da Windows einen Stop des Dienstes und nachgelagertem Start nur ausführen muss, wenn es wirklich nötig ist.

Teil 3 dieser Reihe wird sich dann mit praktischen Definition von Services beschäftigen und wie diese ausschließlich aus den zugehörigen Host-Objekten parametresiert werden.

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.

Icinga2 & LSW

Ich musste feststellen das man mit dem Linux Subsystem for Windows auch Icinga2 + Icingaweb2 auch zum laufen bringen kann auf einem Windows.

Also hier mein kleiner Erfahrungsbericht:

Es galt erstmal heraus zufinden welches Ubuntu in dem Subsystem verwendet wird.

Dazu verwenden wir folgendes Kommando:

# lsb_release -a

selection_019

Nun installieren wir erstmal Updates:

# sudo -i && apt-get update
gefolgt von eurem PW und dann dem Update:

selection_020

Als nächstes installieren wir das Icinga2 Repo fuer die anstehende installation von Icinga2.

# add-apt-repository ppa:formorer/icinga && apt-get update

selection_022

Nun legen wir mit der Datenbank los:

# apt-get install mariadb-server mariadb-client -y

Es muss hiernach das Passwort für den MySQL Root Benutzer angelegt werden.

# /etc/init.d/mysql start
# mysql_secure_installation

Login zu Mariadb:

# mysql -p
Anlegen der Icinga-IDO Datenbank:

selection_027

# create database icinga;
Festlegen des IDO Benutzers:

# grant all on icinga.* to 'icinga'@'localhost' identified by 'icinga';
# apt-get install nagios-plugins-all -y

Damit haben wir die Plugin-Checks installiert aber es fehlt uns noch der Webserver :

Dem widmen wir uns nun :

# apt-get install apache2
gefolgt von der simplen installation von icinga2;

# apt-get install icinga2

selection_031

Wir starten nun erstmal den Icinga2 Service:

# /etc/init.d/icinga2 start
Nun brauchen wir natuerlich auch den Rest 🙂

# apt-get install icingaweb2 icingacli icinga2-ido-mysql
Nach dem die Installation durchgelaufen ist editieren wir erstmal die IDO Konfig Datei:

selection_034

# vi /etc/icinga2/features-enabled/ido-mysql.conf
und kommentieren alle wichtigen eintraege ein und ändern Sie ggf. ab.

Wir müssen auch noch die die php.ini editieren:

# vi /etc/php5/apache2/php.ini
Wir suchen darin nach date.timzezone und tragen hier eine Sinnvolle Zeitzone ein.

apt-get install php5-gd php5-imagick

gefolgt von :

# /etc/init.d/httpd restart
Auch ein enablen der Commandpipe ist notwendig:

# icinga2 feature enable command
Fuer das Webfrontend benoetigen wir einen setup token

# icingacli setup token create
Der Webserver läuft schon , wir oeffen im Edge die folgende adresse https://127.0.0.1/icingaweb2/setup

und benutzen den angeforderten Token.

Wir fuellen das Setup Sinnvoll aus 🙂

Ausserdem muss ggf. die iptables firewall eingetragen werden:

# iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

selection_054

Und erhalten zum Schluß ein laufendes Icinga2 welches im LSW installiert ist.

Ich hoffe ihr hattet bischen Spaß beim dem nachvollziehen oder nachbauen.

Ich freue mich über Feedback jeglicher Art.

Gruß

David

David Okon

Autor: David Okon

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 glücklichen Menschen zu machen.

Was macht eigentlich . . .

This entry is part 13 of 13 in the series NSClient++

. . . NSClient++ ? Länger haben wir hier im Blog nichts mehr zum Thema NSClient geschrieben. Grund genug um mal wieder den aktuellen Entwicklungsstand zu überprüfen.

Aktuell wird der Monitoring Agent in 2 Strängen weiterentwickelt. Die Version 0.4.4 ist als stable markiert und bekommt nur noch bugfixes und kleinere Erweiterungen. In Version 0.5.0 wurden einzelne Module komplett neu geschrieben. Mit der aktuellen 0.5.0.59 wurde weiter an der Stabilität und einzelnen Checks gearbeitet.

nsclient-logoBesonders hervorzuheben sind im 0.5er Release der Webserver, der ssl gesichert und REST-apifiziert Kommandos entgegen nimmt und Informationen zurückliefert, Auch ist es in der aktuellen Version möglich Performancedaten direkt an graphite zu schreiben, was besonders in Großen Umgebungen zu einer starken Entlastung des monitoring servers (egal ob icinga 1 oder 2) führen kann. Um den überwachten Server besser zu schützen beendet NSClient jetzt alle von ihm angestoßenen Skripte wenn es selbst beendet wird, damit keine Langläufer mehr verloren gehen.

Bei allen Verbesserungen in 0.5 sollte man aber nicht vergessen, dass diese Version noch beta ist und nur mit der nötigen Vorsicht verwendet werden sollte.

Christoph Niemann

Autor: Christoph Niemann

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.

Umstieg auf Icinga 2 gesucht?

Icinga Kaum hat man sein Nagios-System aufgebaut um Linux, Windows, ESXi und diverse Hardware-Komponenten wie Router und Switche zu überwachen, meint die Community im Jahr 2009 einen Fork mit dem Namen Icinga ins Leben zu rufen. Aufgrund vieler Bugfixes und Optimierungen ging es dann bei einer Vielzahl von Kunden in Richtung Migration auf Icinga – mit Erfolg. Als Dienstleister traten wir hier oft unterstützend und beratend zur Seite, bis der Kunde sein neues Monitoring in Betrieb nehmen konnte.

3 Jahre später kamen die Icinga Jungs dann auf die Idee Icinga 2 zu veröffentlichen, mit vielen neuen Features wie einem eingebauten Cluster, einer eigenen API, einem schnellen und dynamischen Webfrontend, einem fancy Web-Konfigurations Tool und vielem, vielem mehr.

Um allen einen einfachen Umstieg von sowohl Nagios als auch Icinga (oder natürlichem jedem anderen Monitoring-Tool) zu ermöglichen, bieten wir unsere Icinga 2 Starterpakete an. Innerhalb von 4 Tagen Dienstleistung bei Ihnen vor Ort bauen unsere Consultants gemeinsam mit Ihnen eine Icinga 2 Umgebung auf und fügen die ersten Services in das Monitoring hinzu. Selbstverständlich gehen wir auf die Unterschiede zu den Vorgänger-Versionen ein und zeigen auf, wie das neue Monitoring-Tool bedient werden kann.

Auf Wunsch installieren wir verschiedene Web-Module wie bspw. das Business-Process Addon, den Icinga Director oder ganz klassisch PNP4Nagios.

Unsere Starterpakete richten sich dabei nicht nur an Nagios / Icinga Benutzer, sondern natürlich auch an neue Kunden welche mit den Open Source Lösungen bisher noch keine Berührungspunkte hatten.

Warum sich ein Umstieg auf Icinga 2 lohnt? Hierzu kann man jetzt viele Vorteile schreiben. Am besten ist es aber man probiert das System selbst einmal über die bereitgestellten Vagrant-Boxen aus oder man schaut sich eines unserer Webinare zu Icinga 2 und Icinga Web 2 an, um einen besseren Eindruck zu bekommen.

Wer noch nicht überzeugt ist oder ein Angebot für ein Icinga 2 Starterpaket wünscht, kann gerne mit uns Kontakt aufnehmen. Wir freuen uns über jede Anfrage!

Christian Stein

Autor: Christian Stein

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