acoby
services

Icinga ist ein Fork von Nagios. Nagios ist in vielen Rechenzentren ein Defacto-Standard für das Monitoring von Systemen. Die Abtrennung von Icinga erfolgte unter anderem, weil die Entwicklung von Nagios sehr langsam und “altbacken” war.

Mit Icinga2 ist mittlerweile ein sehr mächtiges Tool auf dem Markt, mit dem man riesige weltumspannende Infrastrukturen monitoren kann. Das Grundprinzip von Icinga/Nagios ist, dass es Scripte (sogenannte Plugins) gibt, die man auf der Commandshell eines Hosts (Linux/Windows) ausführen kann und dieser Script gibt mit seinem Exit-Code eine Information, ob er erfolgreich gelaufen ist, oder nicht. Der Code 0 bedeutet, alles ok. Alles andere ist dann Warning, Critial, Unknown, etc.

Die Scripte können zusätzlich noch Output liefern (stdout) und damit fürs Monitoring Aussagen und Performancewerte ausgeben. Diese kann man nutzen, um Trends darzustellen. Auch das kann Icinga/Nagios out-of-the-box.

Welche Scripte wo ausgeführt werden soll, beschreibt ein Agent. Dieser kann mit anderen Agenten zusammenarbeiten und eine Zone bilden. Agenten können auch Parents haben und damit verteilt man dann die Last der Agenten auf die Maschinen. Die Verbindung zwischen den Agenten ist SSL verschlüsselt. In der frühen Vergangenheit lief das alles via SSH. Mittlerweile gibt es in Icinga ein eigenes Protokoll auf Port 5665.

Icinga sammelt die Informationen aller Agenten auf einem oder mehreren Mastern. Der Master wiederum kann eine Web-Oberfläche oder API haben, bei der man die Zustände einsehen kann. Mit Icinga Director lässt sich all das webbasiert konfigurieren. Da wir aber alles automatisch machen, ignorieren wir den Director und verwenden die grundlegend (auch vom Director verwendeten) Text-Konfigurations-Dateien.

Wir gehen davon aus, wir haben folgendes Ansible-Inventar:

all:
  hosts:
    host1:
      monitoring_domain: monitoring.domain.tld
      monitoring_parent:
    host2:
      monitoring_parent: host1
    vm1:
      monitoring_parent: host1
    vm2:
      monitoring_parent: host2
    vm3:
      monitoring_parent: host2
    vm4:
      monitoring_parent: host2
  children:
    monitoring_master:
monitoring_master:
  hosts:
    host1:

Dieses Inventar beschreibt einen Host1, der in Zukunft unser Icinga Monitoring Master sein soll. Es könnten auch mehrere sein.

Außerdem gibt es noch host2, dieser ist aus Monitoring Sicht ein Host in der Master-Zone von host1. Genauso wie vm1. Die Maschinen vm2, vm3, vm4 sind Teil der Zone host2 und damit ist host2 ein Satellite und leitet Anfragen von host1 an die VMs weiter und umgekehrt sammelt alle Informationen der VMs ein und schickt sie gebald an host1. Man kann sich leicht vorstellen, wie man seine eigene Infrastruktur so aufbauen kann. Alle VMs eines Hosts kann man als Agenten des jeweiligen Hosts sehen, der eine Zone aufbaut. Genauso kann man so auch die verschiedenen Lokationen von einander trennen und Bandbreite sparen.

Linksammlung

Hier finden sich einige nützliche und interessante Links an, die sich im Laufe der Recherche angesammelt haben.

Icinga2

Für die Docker Container Validierung gibt es einige Checks, ein sinnvoller ist vermutlich:

Das Teil ist einfach mit pip zu installieren und gibt für alle laufenden Container eine Antwort in Summe. Das Problem sind die Container, die evtl. nur temporär arbeiten (zB. composer, mongo-db-init, ..). Es gibt zwar eine Regex, die man für das Matching nutzen kann, es muss geprüft werden, ob man die negieren kann.

Ist etwas buggy, aber ist auch eine Option für den Weg, dass man generell beim Initialisieren pro Service ein Servicecheck anlegt. Die jeweilige Docker-Rolle bestimmt also ihre Checks selber. Macht ja auch Sinn.

Das Problem ist, wie kriegen wir den Check weg, wenn die Rolle wegfällt. Irgendein Cleanup muss erfolgen.