Icinga 2 Best Practice Teil 4: Host Templates und Services

Heute soll es um die Strukturierung von Services und deren Zuordnungen zu Gruppen von Hosts gehen. Ein Host Template kann zur Zusammenfassung von Informationen einer Gruppe von Hosts dienen und damit mehrere unterschiedliche Services für den jeweiligen Host anziehen. Wir wollen in den folgenden Beispielen Linux Hosts überwachen. Dort neben, wie schon in Teil 3 beschrieben, der Belegung der Dateisysteme auch in Abhängigkeit in welchem Netzsegment der Host angeschlossen ist, ob die Zeit synchron zum Zeitserver läuft.

template Host "linux-host" {
  import "generic-host"

  vars.os = "Linux"
  vars.disks["disk /"] = {
    disk_partition = "/"
  }
}

apply Service "time" {
  import "generic-service"

  check_command = "ntp_time"
  command_endpoint = host_name

  assign where host.vars.os == "Linux"
}

Es gibt zwei Netze mit je eigenem Zeitserver. Um dieses abzubilden, definieren wir für jedes Netz ein eigenes Host-Template:

template Host "dmz-net" {
  vars.ntp_address = "172.16.2.99"
}
template Host "lan-net" {
  vars.ntp_address = "172.16.1.99"
}

Diese beiden Templates enthalten nur netzspezifische Informationen, in unserem Beispiel auch nur den jeweilig zuständigen Zeitserver. Der Service-Check time mit dem Plugin check_ntp_time ermittelt die Differenz zwischen der lokalen Zeit des Hosts und der Zeit des NTP-Servers, der in ntp_address angegeben ist. Nun müssen wir für einen Host im internen Netzwerk lan-net nur noch beide Templates zusammen bringen:

object Host "host.example.org" {
  import "linux-host"
  import "lan-net"
  import "postgres-dbms"

  address = "172.16.1.11"
}

Habe wir weitere Services, die abhängig vom Netzsegment unterschiedlich zu konfigurieren sind, können diese Informationen den Netz-Templates hinzugefügt werden. Ein weiteres Beispiel wäre hier die Überwachung unterschiedlicher Domain Name Services. Diese Konzept der Stapelung von Host templates kann natürlich noch weitergeführt werden, z.B. auf Applikationen wie einen Postgresql basierendes Datenbank-Management-Systems bezogen. Ggf. muss jedoch auf die Reihenfolge der Importe geachtet werden, wenn Werte überschrieben werden sollen.

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.

Bald geht’s nach Berlin – Icinga Camp 2017

Am 07. März 2017 steigt das Icinga Camp in Berlin, wenn die Kalkscheue wieder zum Schauplatz der Monitoring-Verrückten wird. Jede Menge Icinga Talks und Diskussionen werden euch neben leckerem Essen und einem Icinga T-Shirt der neuesten Kollektion erwarten. Hier ein kleiner Vorgeschmack wer und was euch an diesem aufregenden Tag erwarten wird:

Nachdem Bernd den aktuellen Status von Icinga präsentiert, folgen Vorträge zu verschiedenen Icinga-Themen. Sven Nierlein von ConSol stellt mit Thrunk ein anderes Icinga Webfrontend vor, Eric Lippmann, Icinga CTO, gibt einen Einblick in Icinga Web 2. Werner Fischer von der Thomas.Krenn AG gibt Tipps, wie Hardware Monitoring besser gestaltet werden kann, wohingegen Mattis Haase von C-Store erläutert, was beim schreiben von Checks alles so zu beachten ist.

Außerdem werden Eduard Gueldner (Siemens AG) mit „Train IT Platform Monitoring“, Francesco Melchiori (Würth Phoenix) mit „Alynix – End user Experience Monitoring in Icinga“, sowie Thomas Gelf mit Infos zum Icinga Director und Micheal Friedrich („Integrations all the way“) mit von der Partie sein.

Noch kein Ticket? Buuuuh! Dann schnell hier hin klicken und noch eines der letzten Tickets ergattern. Wir sehen uns in Berlin! 🙂

Julia Hackbarth

Autor: Julia Hackbarth

Julia ist seit 2015 bei NETWAYS. Sie hat im September ihre Ausbildung zur Kauffrau für Büromanagement gestartet. Etwas zu organisieren macht ihr großen Spaß und sie freut sich auf vielseitige Herausforderungen. In ihrer Freizeit spielt Handball eine große Rolle: Julia steht selbst aktiv auf dem Feld, übernimmt aber auch gerne den Part als Schiedsrichterin.

TLS Konfiguration von Icinga 2 mit collect_ssl_info checken

In Icinga2 und dessen Kommunikationsprotokoll ist SSL/TLS die Kommunikationsbasis. Transportverschlüsselung von Daten ist heute weit verbreitet wie das Beispiel HTTPS zeigt. Die technische Grundlage ist SSL/TLS. SSL steht für Secure Socket Layer und TLS bedeutet Transport Layer Security. Transportlayer Security ist nur eine neuer Name der die Weiterentwicklung verdeutlichen soll. Die entscheidende Grundlage ist die Standardisierung dieser Kommunikation um möglichst vielen Kommunikationspartnern eine problemlose Kommunikation zu ermöglichen.

Die Kryptographische Grundlagen sind mehrere Algorithmen für Datenhashing und Verschlüsselung die sich in vier Gruppen aufteilt. Die erste Gruppe sind Securehashe. Beim Hashing besteht die Aufgabe von Quelldaten eine Quersumme zu erzeugen die zweifelsfrei nur von identischen Daten identische Quersummen erzeugt und gleichzeitig einen Rückschluss von der erzeugten Quersumme, Hashwert auf die Quelldaten unmöglich macht. Die zweite Gruppe sind symmetrische Chiffrierer. Bei Symmetrischer Verschlüsselung muss zuallererst ein geheimer Schlüssel erzeugt und nur an den Kommunikationspartner übermittelt werden. Danach wird ein symmetrisches Verfahren vereinbart und mit dem geheimen Schlüssel die Daten an der Quelle verändert und diese Transformation am Ziel wieder Rückgängig gemacht. Für alle unbeteiligten sind diese veränderten Daten unleserlich und damit wertlos. Die Dritte Gruppe sind asymmetrische Chiffren. In den siebziger Jahren wurden Asymmetrische Verfahren erfunden. Der erste Algorithmus der sich verbreitet hat trägt den Namen RSA nach den Anfangsbuchstaben der Entwickler. Wesentliches Prinzip ist hier dass immer zwei komplementäre Schlüssel erzeugt werden wobei immer was mit dem einen Schlüssel verändert wurde kann nur mit dem zweiten Schlüssel rückgängig und wieder lesbar gemacht werden. Und weiter kann von einem Schlüssel nicht der andere hergeleitet oder erzeugt werden. Das bietet die schöne Möglichkeit einen Schlüssel zu veröffentlichen und den anderen geheim zu halten. Da jetzt beliebig viele diesen öffentlichen Schlüssel anwenden und damit Daten verschlüsseln können und nur der Besitzer des zweiten geheimen Schlüssels dies Daten wieder lesbar machen kann, sonst niemand und damit entfällt die Notwendigkeit zwischen Beteiligten geheime Schlüssel vorher austauschen zu müssen. Noch erwähnen möchte ich eine vierte Gruppe, die Schlüsselaustauschprozeduren wie beispielsweise Diffie-Hellman. Solche Verfahren ermöglichen es ein gemeinsames Geheimnis, geheime Schlüssel, zwischen zwei Partnern zu verabreden ohne das Dritte durch abhören erfahren können was ausgehandelt wurde.

Im praktischen Einsatz werden meist alle verfahren kombiniert eingesetzt um damit die Aufgaben

  • Identitätsfeststellung
  • Massendatenverschlüsselung
  • Datenauthentizität
  • Schlüsselaustausch

zu bewältigen. Asymmetrische Verfahren bieten bisher nur geringen Datendurchsatz und sind für Massendaten kaum zu gebrauchen, bieten aber die Möglichkeit der Identitätsfeststellung indem man mit dem öffentlichen Schlüssel ein bestimmtes Datenmuster verschlüsselt, zur Gegenseite transferiert mit der Aufforderung zu entschlüsseln, das Muster zu invertieren und mit dem zweiten privaten Schlüssel zu verschlüsseln und wieder zurückzusenden. Kann an der Datenquelle die Antwort mit dem öffentlichen Schlüssel wieder erfolgreich entschlüsselt werden und liefert das erwartete invertierte Bitmuster, ist sichergestellt dass am andern Ende der zugehörige private Schlüssel vorhanden ist und somit ist die Identität festgestellt. Bisherige Asymmetrische Verfahren benötigen zur ausreichenden Schlüssel-härte größere Schlüssellängen. Schlüssel-härte bezeichnet die Resistenz gegen Knacker. Als neue Verfahren sind in den letzten Jahren EC Verfahren, Elliptische Kurven Kryptographie, dazugekommen, die erheblich härtere Schlüssel haben und damit deutlich kürzer sein können. Ein Vergleich, beim RSA Verfahren sind weniger als 2048 Bit als unsicher anzusehen, hingegen ECDSA erreicht die gleich Härte schon mit gut 200 Bit Schlüssellänge. Mit Symmetrische Verfahren können Massendaten am schnellsten codiert werden und sie bieten eine relativ hohe Schlüssel-härte. Symmetrische Verfahren sind bereits mehrere tausend Jahre bekannt und es gibt viele verschiedene davon. In neuere Zeit hat sich hier der AES, Advanced Encryption Standard, verbreitet. 128 Bit lange Schlüssel sind heute bei diesem symmetrischen Verfahren schon als hart und damit als sicher zu betrachten. Aber beide Kommunikationspartner brauchen denselben geheimen Schlüssel und der muss vorher sicher erzeugt und ausgetauscht werden. Hier kommen Schlüsselaustauschprozeduren wie DH, Diffie-Hellman oder die neuere Variante ECDH, Elliptische Kurven Kryptographie Diffie Hellman zum Einsatz oder alternative werden auch asymmetrische Cipher dazu eingesetzt. Und nicht vergessen möchte ich die Aufgabe übermittelte Daten auf Authentizität zu prüfen und jede Veränderung zu bemerken und solche Daten als falsch abzuweisen wozu wieder Hashverfahren angewendet werden, mein HMAC bezeichnet, Hashed Message Authentication Code

Zusammengefasst

  • Symmetrische Verfahren arbeiten performant aber benötigen ein gemeinsames Geheimnis
  • Asymmetrische Verfahren arbeiten langsam aber verwenden zwei komplementäre Schlüssel die als privat und öffentlich bezeichnet werden
  • Secure Hashe bilden Prüfsummen von Daten
  • Schlüsselaustauschprozeduren handeln Geheimnisse aus

So besteht heute die Aufgabe öffentliche Schlüssel und Daten zu Personen, Firmen oder Rechnern zuzuordnen. Dazu haben sich mehrere Arbeitsabläufe etabliert. Manche, handeln nach dem Prinzip des Web of Trust, also wer kennt wen und vertraut wem und welche Schlüssel gehören zu wem. Andere handeln nach der Standardisierung x509, einem ITU-T Standard. Zur Erfüllung dieses Standards haben sich sogenannte Trustcenter etabliert die sich in zwei Aufgaben splitten der CA und der RA. CA bedeutet Zertifikatsautorität und hat zur Aufgabe kryptographisch Schlüssel und Datenzugehörigkeit zu beweisen in Form eines x509 Zertifikats. Der zweite Teil besteht aus der Registrierungs Autorität und der Aufgabe die Verifikation von Kundendaten wie Adresse, Firmenname, Rechnernamen und bei Fehlern Zertifikate zu verweigern. Ein Zertifikat enthält dann diese Daten, einen öffentlichen Schlüssel und die Signatur durch die CA.

Signaturen sollen Datenauthentizität sicherstellen. Dazu wird über die als korrekt bewerteten Daten mit einem Secure Hase eine Prüfsumme erstellt und mit dem privaten Schlüssel der CA verschlüsselt. Diese CA stellt ihren öffentlichen Schlüssel mit Ihren Daten als x509 Root-Zertifikat aus und hat diesen normalerweise bereits weit verteilt in Webbrowsern oder anderen Programmen. Eine zu jeder Zeit durchführbare Authentizitätsprüfung wiederholt den Schritt die Quersumme aus den vorhandenen Daten, wie Rechnernamen neu zu erzeugen, die verschlüsselte Quersumme in der Signatur mit dem öffentlichen Schlüssel der CA aus deren Zertifikat zu entschlüsseln und zu vergleichen. Sind beide identisch, so ist damit die Authentizität bewiesen. Solche Zertifikate können mehrstufige Ketten bilden und beginnen immer mit einem Root-Zertifikate der CA, einem Zwischenzertifikat und dem Server oder Clientzertifikat am Ende das dann in Massen ausgestellt wird.

Heute wird sehr oft SSL/TLS angewendet. Transport Layer Security beschreibt eine große Zahl von verfügbaren Ciphern, Chiffrierverfahren, deren Anwendung, Protokollen und besonders das jeweilige Handshake Protokoll, also das Aushandeln vom Kommunikationsparametern. Für SSL stehen mehrere Softwarepakte zur Verfügung die durch die Standardisierung untereinander in der Kommunikation kompatibel sind und verschlüsselt kommunizieren können. Diese Softwarepakete werden in der Regel in Kommunikationsprogramme als Bibliotheken eingebunden. Solche um SSL erweiterten Programme haben oft ein “S” für Secure im Namen. Das SSL/TLS-Protokoll enthält heute das TLS-Record-Protokoll das die über TCP, Transmission Controll Protocol, die zu transferierenden Datenblöcke behandelt. Darüber werden die TLS-Protokolle, TLS-Handshake, TLS-Cipher-Spec, TLS-Alert-Protocol und das TLS-Application-Protocol transportiert. Für die praktische Anwendung werden fast immer mehrere Algorithmen kombiniert eingesetzt um Identitäten fest zu stellen, das gemeinsame symmetrische Verfahren zu vereinbaren und den gemeinsamen geheimen Schlüssel zu erzeugen und für beide Seiten zugänglich zu machen. Über TLS-Handschake beginnt die Kommunikation, wer ist wer, über TLS-Cipher-Spec wird der Symmetrische Cipher mit Parametern vereinbart. Anschließend werden Meldungen über das Alert-Protocol und die Massendaten über das TLS-Application-Protokoll transportiert.

Das TLS-Handshake-Protocol arbeitet beim Verbindungsaufbau diese Schritte ab

  1. Client schickt zum Server ein Hello
  2. Server identifiziert sich beim Client mit seinem Zertifikat
  3. Client kann sich bei Server mit seinem eigenen Zertifikat ausweisen oder mitteilen dass er keines hat
  4. Sind die vorangegangenen Schritte akzeptiert wird ein einmaliger gemeinsamer Schlüssel nur für diese Verbindung vereinbart, und im Abstand von Stunden geändert

Über das Alert-Protocol verständigen sich die Kommunikationspartner über verschiedene Events während der Kommunikation wie zB Datenblöcke fehlerhaft übermittelt oder andere Ereignisse.

x509 Zertifikate können also auch zur Authentisierung von Clients gegenüber Servern verwendet werden, sodass ein Server dies Zertifikate auf Zugehörigkeit oder weitere Angaben prüfen und dann zur Kommunikation akzeptierten oder ablehnen und die Verbindung beenden oder mit User und Passwortcheck fortfahren kann. Dies Möglichkeit bietet sich für automatische Verbindungen zwischen Servern oder Systemkomponenten an. Eine solche hierarchische x509 Zertifikatskette wird von Icinga 2 zur Authentisierung verwendet. Dabei existiert ein Root-Zertifikat einer CA auf einem Icinga 2 Server. Mit dem privaten Schlüssel dieser CA werden dann für jeden Kommunikationspartner eine eigenes x509 Zertifikat erzeugt. Entscheidender Teil ist der korrekte Rechnername, FQDN, Full qualified Domain Name. Danach erhält jeder Kommunikationspartner sein eigenes Zertifikat, den privaten Schlüssel und das Rootzertifikat der Icinga 2 CA.

Damit kann nur kommunizieren wer die “Erlaubnis” per Zertifikat hat, also ein Zertifikat das in diesem Baum signiert ist und wenn, dann nur verschlüsselt. Zur weiten Detaillierung können in Icinga 2 Konfigurationsdateien die TLS Version und die erlaubten symmetrischen Cipher definiert werden. In jedem Zertifikat ist der Servername hinterlegt und damit wird die Kommunikation nur von diesem System mit einem Zertifikat aus dem Icinga 2 CA Baum angenommen. Im Unterschied zu Zertifikaten von Webservern akzeptiert Icinga 2 keine Metazeichen im Rechnernamen.

Beispieleinträge in einer /etc/icinga2/features-enabled/api.conf Datei

protocolmin = "TLSv1.1"
cipher_list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256"

Als Erweiterung zur Erleichterung der Einrichtung und Erstkontaktaufnahme mit dem Icinga 2 Server von Systemen mit Agenten werden sogenannte Tickets verwendet. Solche Tickets leiteten sich aus dem Root-Zertifikat, und dem Systemnamen des Agenten, FQDN, ab.

Erzeugen kann man Tickets auf zwei Arten

icinga2 pki ticket --cn mein.agent.de
c4eb335a1e62c4779bed3901eaa245699d92817b

oder via rest-api

curl -k -s -u apiuser:apipassword -H 'Accept: application/json' \
-X POST 'https://IcingaCAServer:5665/v1/actions/generate-ticket' \
-d '{ "cn":"mein.agent.de" }' | python -m json.tool

Und dieser API-User muss natürlich angelegt sein und sollte nur Rechte für generate-ticket haben. Das wird in der api-users.conf eingestellt

object ApiUser "apiuser" {
  password =  "apipassword"
  permissions = [ "actions/generate-ticket" ]
}

Für Administratoren stellt sich Aufgabe solche Sicherheitseinstellungen zu kontrollieren. Und dazu gibt es ein Toolchen das solche Einstellungen einfach über Netz abfragt, das Skript collect_ssl_info.

collect_ssl_info 192.xx.yy.zz:5665

fragt vom Icinga 2 Server das Zertifikat ab

collect_ssl_info 192.xx.yy.zz:5665 -showcerts

fragt die komplette Zertifikateskette ab

Und nun ein kleines Beispiel zur Abfrage nach schwachen Ciphern.

collect_ssl_info -qp -u 192.xx.yy.zz:5665 -u www.xyz.de:443 \
 -c RC4-MD5 -c AES128-SHA256 
===== begin ciphertest 192.xx.yy.zz:5665 =============
RC4-MD5                          failed
AES128-SHA256                    success
===== end ciphertest 192.xx.yy.zz:5665 ===============
===== begin ciphertest www.xyz.de:443 ==============
RC4-MD5                          failed
AES128-SHA256                    success
===== end ciphertest www.xyz.de:443 ===============

jetzt erzeugen wir listen für ein zweites Beispiel

host.txt

192.xx.yy.zz:5665
www.xyz.de:443

cipher.txt

RC4-MD5
AES128-SHA256

und erledigen den gleichen Job mit Anwendung dieser Listen

collect_ssl_info -qp -ul host.txt -cl cipher.txt 
===== begin ciphertest 192.xx.yy.zz:5665 ===============
RC4-MD5                          failed
AES128-SHA256                    success
===== end ciphertest 192.xx.yy.zz:5665 ===============
===== begin ciphertest www.xyz.de:443 ===============
RC4-MD5                          failed
AES128-SHA256                    success
===== end ciphertest www.xyz.de:443 ===============

Eine Übersicht über die Icinga 2 Konfigurationsparameter.

Configuration Attributes:

Name Description
cert_path Required. Path to the public key.
key_path Required. Path to the private key.
ca_path Required. Path to the CA certificate file.
crl_path Optional. Path to the CRL file.
bind_host Optional. The IP address the api listener should be bound to. Defaults to 0.0.0.0.
bind_port Optional. The port the api listener should be bound to. Defaults to 5665.
accept_config Optional. Accept zone configuration. Defaults to false.
accept_commands Optional. Accept remote commands. Defaults to false.
cipher_list Optional. Cipher list that is allowed.
tls_protocolmin Optional. Minimum TLS protocol version. Must be one of TLSv1, TLSv1.1 or TLSv1.2. Defaults to TLSv1.

Das Skript steht zum Download bereit und viel weitere Info zur Konfiguration von Icinga 2.

Siegfried Eichhorn

Autor: Siegfried Eichhorn

Siegfried ist ein Urgestein der IT, das die Dinosaurier noch selbst erlebt hat. Bei den ersten Projekten mit Open Source und Linux gabs noch komische Bemerkungen, aber das ist längst Geschichte. Nach vielen Projekten und Eskapaden hat er jetzt das Abenteuer NETWAYS gewagt und arbeitet dort als Consultant. Und wenn er da mal nicht arbeitet, genießt er Nürnberg.

Icinga 2 Best Practice Teil 3: Services überwachen

Nun in Teil 3 dieser Serie werden wir uns näher damit beschäftigen wie in Icinga 2 Services überwacht werden bzw. wie es zu konfigurieren ist, dass bestimmte Services nur auf bestimmten Hosts überwacht werden. Hier bietet Icinga 2 als Neuerung eine regelbasierte Zuweisung an Host-Objekte die definierten Eigenschaften genügen.

apply Service "ping4" {
  import "generic-service"

  check_command = "ping"

  assign where host.address || host.address6
}

So wird hier ein Service ping4 an alle Hosts “gebunden”, die das Attribut address oder address6 definiert haben. Nach diesem recht einfachem Beispiel wenden wir uns auch gleich etwas komplizierterem zu, der Überwachung von Dateisystemen auf einem Linux-System.

apply Service for (filesystem => config in host.vars.disks) {
  import "generic-service"

  check_command = "disk"
  command_endpoint = host.name

  vars += config

  assign where host.vars.os == "Linux"
  ignore where typeof(config) != Dictionary
}

Da hier über das CheckCommand disk, das Plugin check_disk zur Anwendung gelangt, das lokal auf dem zu überwachenden System laufen muss, wird es via command_endpoint auf genau diesem Endpoint angetriggert (siehe hierzu Teil 1 dieser Serie). Ein Host kann mehrere unterschiedlich Dateisysteme beherbergen, deshalb sind diese im Host-Objekt mit dem Custom-Attribute vars.disks zu definieren. Ausserdem muss zusätzlich, wie in dem assign-Statement gefordert, vars.os auf Linux gesetzt sein.

object Host "host.example.org" {
  ...
  vars.os = "Linux"

  vars.disks["disk /"] = {
    disk_partition = "/"
  }
  vars.disks|"disk /tmp"] = {
    disk_partition = "/tmp"
  }
}

Bekanntlich handelt es sich bei vars um ein Dictionary und vars.disks ist eine Darstellungsform eines Keys in diesem Dictionary. Eine andere Form einen Schlüssel anzusprechen ist der Index mit []-Klammern, wie in vars.disks[“disk /”]. Das heißt wir haben hier ein Dictionary in einem Dictionary. Und um es noch auf die Spitze zu treiben weisen wir den einzelnen Keys als Wert wieder jeweils ein Dictionary zu, Perl lässt grüßen. Wozu nun das Ganze? Mit apply Service for wird der Inhalt von vars.disks durchlaufen. Da es sich hierbei um ein Dictionary handelt, wird hier ein for-each verwendet, zu sehen an filesystem => config. Beides sind hier unsere Laufvariablen für die Schleife. Der Variablen filesystem wird jeweils der Key zu gewiesen, also beim ersten Durchlauf “disk /” und beim Zweiten “disk /tmp”, in config dann demnach der zugehörige Wert. Diesen Wert, selbst ein Dictionary, kann als Konfigurations-Dictionary bezeichnet werden, der den jeweiligen Pluginaufruf von disk parametrisiert. Die möglichen Parameter für disk sind sehr gut der Online-Dokumentation zu entnehmen. Wie dies funktioniert und warum die Zeile vars += config hierzu eine zentrale Rolle spielt, wird in Teil 4 erklärt werden. Der Name des Services entspricht standardmäßig dem Inhalt von filesystem.
Selbstverständlich besitzt jedes Linux-System ein Root-Dateisystem und sagen wir, bei uns auch ein eigenes für /tmp. Natürlich möchte man nun nicht für alle seine Hosts immer diese obigen 7 Zeilen angeben müssen, deshalb definieren wir mit diesen ein Host-Template mit der Bezeichnung linux-host. Nun haben Regeln die dumme Eigenheit ihre Ausnahmen zu haben, z.B. hat der Host host.example.org im Gegensatz zu allen anderen Hosts eben kein Dateisystem /tmp. Was dann?

object Host "host.example.org" {
  import "generic-host"

  vars.disks["disk /tmp"] = false
}

Hier wird nun für /tmp die Definition aus dem Template nachträglich überschrieben. Das ignore-Statement in unserer Service-Definition sorgt dafür, dass alle Dateisysteme, denen kein Konfiguration-Dictionary zugewiesen ist, auch nicht als Service in unserer Icinga-Konfiguration landen. Bei typeof handelt es sich um eine Funktion, die die Typesierung einer Variablen ermittelt.

Bis zum nächsten Mal, ihr müsst unbedingt schauen wie es weiter geht. In Teil 4 folgt die etwas theoretische Erklärung wie solche Services jeweils einzeln unterschiedlich parametrisiert 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.

Icinga, Nagios, Naemon, OMD, Check_MK, Op5 oder Shinken – Teil II

Einen Vergleich der oben genannten Tools hatte ich vor fast drei Jahren einmal gemacht. Seitdem ist viel passiert (SPOILER-ALARM: Nicht bei allen) und ich dachte es wäre mal wieder an der Zeit für ein heiteres Core-Bashing. Ich mache aber keinen Feature-Vergleich, um festzustellen, wer mehr Checks in der Minute ausführen kann. Es geht mir mehr um die Agilität und die strategische Ausrichtung des Projekts. Und in den nächsten Tagen folgt nochmal ein detaillierter Artikel zum Thema Metriken, also schon mal den Sekt kaltstellen.

Grundsätzlich versuche ich bei der Bewertung folgende Kriterien einzubeziehen:

  • Aktivität des Projekts aus Sicht der Code-Basis
  • Aktivität der Community
  • Aktuelle Roadmap und Features
  • Und last but not least, meine persönliche und rein subjektive Sicht

Da wir mit Op5 noch einen Neuen (nicht im Business, aber in der Vergleichsrunde) haben, starten wir gleich durch und fangen an mit… Shinken:

Shinken

Es mag an dem allgemeinen Trend zur veganen Ernährung liegen, aber um Shinken ist es in den letzten Monaten sehr ruhig geworden. Auf dem verlinkten GitHub-Repo ist seit Oktober letzten Jahres nichts mehr in den Master committed worden, was nicht wirklich einen guten Eindruck macht. Auch die Website ist vollkommen veraltet und das Forum scheint offline zu sein. Jetzt denkt man im ersten Moment, das Ding ist komplett tot, aber auf Shinken Enterprise hat man zumindest die Jahreszahl im Footer aktualisiert und es wird hier auch gearbeitet.

Eine Roadmap habe ich auch nach längerer Recherche nicht gefunden. Ich konnte lediglich entdecken, dass Jean Gabès an einem Discovery-Tool mit dem Namen Kunai arbeitet. Vor einigen Monaten ging es in der Community etwas rund und Shinken, eigentlich ja mal als Fork von Nagios gedacht, wurde selbst geforked. Das neue Projekt nennt sich Alignak und hat bereits den Preis für den kompliziertesten Namen einer Monitoring Software gewonnen.

In Frankreich ist Shinken noch immer eine Nummer, da es im Toolkatalog der Behörden als eine Art Standard für Monitoring definiert ist. Features, Roadmap und somit der verbunden Mehrwert sind nahezu nicht ersichtlich und die Website besteht eigentlich nur aus ganz viel heißer Luft.

Mein Fazit: Es tut mir leid, Jean, aber wie bei Austern die zu lange in der Sonne standen, würde ich die Finger von Shinken lassen.

Op5

Ehrlich gesagt habe ich die Kollegen in Schweden lange aus dem Auge verloren. Erst ein paar Gespräche auf der OSMC im letzten Jahr und die Info, dass Andreas Ericsson nicht mehr dort arbeitet, haben meine Aufmerksamkeit wieder mal auf die Freunde im Norden gelenkt. Auch wenn der verwendete Core Naemon, welcher als “unabhängiges” Projekt hier nochmal ein eigenes Kapitel spendiert bekommt, nicht im GitHub von Op5 zu finden ist, wird dort sonst viel gemacht. Sowohl bei Ninja (dem Webinterface) also auch bei Merlin (der Datenbank und HA-Komponente) wird viel fleißig gebohrt und geschraubt.

Der eigentlich verwendete Core spielt schon seit vielen Jahren für Op5 keine große Rolle, denn als Veredler geht es ihnen vielmehr um Integration und die Erweiterung mit eigenen Add-ons und Tools. Was Neuigkeiten angeht, wird man auch bei Op5 nicht richtig fündig. Das Tech-News-Archive hat seit einigen Monaten keine Neuerung mehr gesehen und eine richtige Roadmap findet man auch nicht.

Strategisch sehe ich Op5 heute da, wo wir vor 8 Jahren hin wollten. Alle möglichen System-Management-Disziplinen aus einem Guss zu kombinieren, sodass der User nichts mehr machen muss. Die Welt hat sich aber verändert und so würde man heute eher Graylog oder den ElasticStack favorisieren, bevor man den integrierten op5 Logger verwendet. Der Naemon-Core und alle anderen Add-ons sind in hoher Qualität miteinander verbunden und der User hat mit der eigentlichen Open-Source-Software nichts zu tun. Somit ist Op5 für mich auch kein Open-Source-Tool und will es vermutlich auch nicht wirklich sein. Die kostenlose Lizenz, die eine Verwendung von 20 Geräten erlaubt, ist in meinen Augen eher ein Marketinginstrument.

Mein Fazit: Op5 Monitor ist ein solides Produkt und wer alles aus einer Box haben möchte, fährt damit mit Sicherheit besser als mit NagiosXI. Der Vorteil der vollintegrierten Lösung ist an dieser Stelle aber auch der größte Nachteil des Werkzeugs. Gerade in den Bereichen Metriken und Loghandling wird es in den nächsten Jahren um seine Bedeutung kämpfen müssen.

Check_MK

Beginnen wir das ganze Thema sachlich: Files sind nicht die Lösung für jedes Problem, NEIN, NEIN, NEIN! Somit wäre das durch und mein strategischer Kampf für die Daseinsberechtigung einer Datenbank im Bereich Monitoring wäre erledigt. Im Bereich des Source-Codes waren die Kollegen aus München schon immer sehr aktiv und so geht es auf deren Git-Repo zu wie in der Münchner S-Bahn zur Rush-Hour. Trotzdem habe ich auch bei Check_MK vergeblich versucht, eine Roadmap zu finden und wurde lediglich im Bereich des Konferenz-Archivs in den vergangenen Jahren fündig. Sollte es eine Public-Roadmap geben, freue ich mich über einen Hinweis.

Nachdem ich mich ein bisschen auf dem Demo-System umgesehen haben, konnte ich dort keine wesentlichen Neuerungen finden. Bei der Durchsicht der letzten Commits wurde jedoch klar, dass sehr viel Energie in den Support der eigenen Check_MK-Checks geht. Die massive Anzahl der integrierten Checks sind für den User mit Sicherheit komfortabel, aber auch eine Bürde für die Entwickler. Wenn man die investierte Zeit hochrechnet, dürfte das mit Sicherheit zulasten von Investition gehen.

Mein Fazit: Vor drei Jahren hatte ich folgendes geschrieben “Ehrlich gesagt glaube ich aber auch, dass Check_mk in der Zwischenzeit eher mit geschlossenen Systemen Op5 Monitor oder OpsView zu vergleichen ist”. Ich würde sagen, die Annahme hat sich vollends bestätigt. Die Dokumentation auf der Website ist gut strukturiert und detailliert, aber ansonsten kann man über Strategie und Ausrichtung fast nichts finden. Persönlich war ich darüber hinaus nie ein Fan von Auto-Discovery, da es aus meiner Sicht alles das nicht ist, was “Infrastructure as Code” sein sollte. Das Check_mk trotzdem eine große Fangemeinde kann ich nachvollziehen, aber die ist einfach heute isolierter als in der Zeit des reinen Addon-ons.

OMD

Das eigentliche OMD-Projekt scheint es in der Form nicht mehr zu geben. Die Kollegen von Check_MK haben sich aus dem Projekt offensichtlich zurückgezogen und so idled die Website, deren Ownership bei Mathias liegt, eher vor sich hin. Tot ist das Thema jedoch nicht, da sich die Freunde von Consol dem Projekt angenommen haben. Die Weiterentwicklung erfolgt auf deren GitHub-Account und somit geht es mit dem Produkt ordentlich voran. Auf einer eigenen Seite wird der Unterschied zwischen OMD von Consol und dem Legacy-OMD – das sich aus meiner Sicht erledigt hat – detailliert erläutert.

Der eingeschlagene Weg von OMD gefällt mir. Wenn ich auch mit dem gebündelten Ansatz so meine Probleme habe, bietet es eine sehr einfache Möglichkeit ein Monitoringsystem hochzuziehen. Der User hat dann immer noch die Wahl zwischen Naemon und Icinga und es gibt reichlich Innovation hinsichtlich Metriksystemen wie Graphite und Prometheus. Auch LMD, was als schnelles Bindeglied zwischen unterschiedlichen Livestatus-Cores und dem Webinterface verstanden werden darf, ist bereits mit dabei.

Eine Roadmap im klassischen Sinn konnte ich auch hier nicht finden, aber Gerhard hat erst vor einigen Wochen einen kurzen Abriss über 6 Jahre OMD gegeben. Die 45 Minuten sind mit Sicherheit gut investiert.

Mein Fazit: Wer eine gebündelte Monitoringlösung sucht und auf Open Source wert legt, sollte sowohl von Check_MK als auch von Op5 die Finger lassen. Hier empfiehlt sich der Einsatz von OMD. Die Kollegen sind seit vielen Jahren im Bereich Monitoring aktiv, wissen worauf es ankommt und verweilen nicht auf dem Status Quo.

Naemon

Naemon ist letztendlich ja das Ergebnis eines frustrierten Andreas, der von den Nagios-Freunden kurz nachdem er Nagios 4 fertig gestellt hatte, aus dem Projekt gekegelt wurde. Warum genau Nagios Enterprises den Bruch mit Andreas vollzogen hat, habe ich erst von zwei Jahren auf der PuppetConf erfahren, hier wird es jedoch leider nicht landen.

Auf dem GitHub-Repo gibt es durchaus Aktivität und erst vor zwei Tagen ist mit Version 1.0.6 ein neues Release erschienen. Das Projekt wird in den letzten Jahren eigentlich ausschließlich von Sven Nierlein am Leben gehalten und ist laut meinem Kenntnisstand auch der bevorzugte Core in OMD. Laut Website gab es in den letzten Monaten keine großen Features sondern lediglich Bugfixes.

Für das Projekt wäre es mit Sicherheit schön, wenn es mehr Contributors hätte. Ich weiss wie anstrengend der “Betrieb” eines solchen Projekts ist und zolle hier Sven Respekt, dass er das Ding weiter in Bewegung hält. Um ehrlich zu sein, sieht es jedoch im Moment für mich nicht so aus, als ob da die Post abgeht.

Mein Fazit: Wer mit dem Funktionsumfang von Nagios zufrieden ist, aber a) mit “denen” nichts zu tun haben will und b) auch Livestatus gleich fertig mit dabei haben will, ist mit Naemon gut bedient. Auch wenn nicht viele Features dazu kommen, wird das Projekt am Leben gehalten und das reicht für ein “eingefrorenes” Featureset vollkommen aus.

Nagios

Mein Fazit: Wem Nagios reicht, soll bitte Naemon nehmen.

Icinga

Zugegeben bin ich nicht der Richtige, um Icinga objektiv zu beurteilen, da ich mit der Software und vor allem den Personen einfach zu viel zu tun habe. Aber die Aktivität des Projekts ist sicher mit Abstand konkurrenzlos. Erst vor einigen Tagen ist das Projekt weg vom privaten Redmine zu GitHub gezogen. Das in der Regel vier bis fünf Personen in Vollzeit an Icinga arbeiten ist natürlich ein Grund für die starke Aktivität.

Mit Icinga 2 haben wir mit Sicherheit die Kruste von Nagios abgelegt und gerade die Konfiguration bietet eine Vielzahl an Möglichkeiten, die es sonst in dem Bereich nicht gibt. Eine große Herausforderung stellt noch das geerbte Datenbankschema da, das in großen Umgebungen immer mal wieder Schwierigkeiten bereiten kann. Eine alternative Lösung dafür zu schaffen, welche sowohl Livedaten sehr schnell, aber auch historischen Daten sehr lange zur Verfügung stellt, ist unsere Aufgabe für 2017. Dies wird sowohl im Core als auch bei Icinga Web 2 zu einer Vielzahl von Änderungen führen und somit den Großteil unserer Zeit in Anspruch nehmen.

Strategisch positioniert sich Icinga eher gegen eine gebündelte Lösung. Das Projekt kümmert sich um Core und Web und hat im letzten Jahr seine Anstrengungen in Richtung Integrationen intensiviert. Dies schließt beispielsweise die fertige Integration für Chef und Puppet aber auch Themen wie IcingaBeats mit ein. Auch der Icinga Director, der unterschiedlichste Quellen für die Konfiguration zusammenfassen kann, erfreut sich sehr starker Beliebtheit.

Mein Fazit: Icinga ist dann das richtige Werkzeug, wenn man die am Markt befindlichen Lösungen für Metriken, Logmanagement, Konfigurationsmanagement usw. nach dem best-of-breed Ansatz kombinieren will. Der Anwender muss hier definitiv ein bisschen mehr Hand anlegen, um die unterschiedlichen Lösungen zusammenbauen, profitiert dann aber auch von der Flexibilität, die er sich damit erarbeitet hat. 

Feedback willkommen

Wie bereits angedeutet handelt es sich hierbei um eine subjektive Betrachtung und sie erhebt nicht den Anspruch auf Vollständigkeit. Sollte ich jemanden zu Unrecht falsch beurteilen oder eine Aussage nicht korrekt sein, bitte ich um einen Hinweis und werde den Post entsprechend korrigieren. Habe ich jemanden zurecht schlecht beurteilt, so muss er damit leben.

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

First talks for Icinga Camp Berlin are online now!

Nach der äußerst erfolgreichen Deutschland-Premiere geht es am 7. März 2017 in die zweite Runde. Die ersten Vorträge stehen bereits fest. Neben Talks einiger Team-Mitglieder werden

#Francesco Melchiori
#Sven Nierlein
#Werner Fischer
#Eduard Gueldner und
#Mattis Haase

mit dabei sein.

Wir freuen uns, Euch in Berlins berühmter Eventlocation, der Kalkscheune, zu sehen!

Nicht vergessen, Euer Monitoring-Madness Tagesticket zu buchen!

 

Markus Neder

Autor: Markus Neder

Nach langen Jahren im Hotelgewerbe, hat sich Markus auf die andere Seite geschlagen und leitet nun bei NETWAYS die Event-Abteilung. Seine langjährige Erfahrung als Hotelmeister hilft uns jedes Jahr die beste Konferenz von allen die noch kommen werden zu veranstalten. Wenn er privat nicht mit seinen Kindern unterwegs ist, entspannt er am liebsten bei der Gartenarbeit.