Viele meiner Leser wissen es bereits: Ich nutze sehr gerneICINGA2 (externer Link) als meine Monitoring Software. Vor vielen Jahren bin ich von Nagios damals zu ICINGA 1 gewechselt und sehr zeitnah zu Version 2. Entsprechend ist klar, dass mein Homelab Monitoring primär von ICINGA2 durchgeführt wird.

Wie sieht für mich Monitoring aus?

Bevor ich dir mein Homelab Monitoring zeige, möchte ich erst mal auf die Frage eingehen, wie das ganze überhaupt für mich aussehen soll, bzw. was für mich der Sinn und Zweck eines Monitoring ist.

Privat als auch im beruflichen Leben weiß ich gern vor meinen Kunden (Partner:in, Kolleg:innen, externe Kund:innen) ob etwas nicht funktioniert. Realistisch betrachtet gibt es Dinge die man nicht vor anderen wissen kann: zum Beispiel ob das Internet noch funktioniert. 🤷‍♂️ Allerdings ist es im Rahmen der Kommunikation immer ein wesentlicher Vorteil schon zu wissen ob/was nicht richtig funktioniert. Die Kunst ist es hier eine Balance zu finden zwischen Dingen die sinnvoll überwacht werden können und welche einfach nur interessant sind zu wissen. Entsprechend versuche ich viele Dinge zu überwachen und mit sauberen Schwellwerten zu versehen um möglichst frühzeitig ein Problem zu sehen oder gar vor einem Problem eingreifen zu können.

Das gerade angesprochene Beispiel mit der Internetleitung ist so ein Thema. Das Monitoringsystem kann ein Ping auf einen externen Dienst absetzen der quasi immer Verfügbar ist, z. B. Google oder Cloudflare. Auf Grund der Auslastung des Monitoringservers wird der Ping nur nicht durchgehend abgesetzt wie wir es z. B. unter Windows mit dem Parameter-t kennen. Stattdessen wird alle paar Sekunden (oder Minuten) eine Reihe von Pings abgesetzt und hieraus dann ermittelt ob die Internetleitung (bzw. wird ja der Service überprüft) verfügbar ist.

Was monitore ich im Homelab?

Nun kommen wir zur spannenden Frage was ich denn im Homelab überwache. Wie oben bereits geschrieben gibt es für mich kein Grund die Verfügbarkeit der Internetleitung zu überwachen. Es ist immer jemand im Haus der das vor mir erkennen würde. Zudem müsste ich für eine entsprechende Benachrichtigung eine zweite Internetleitung bereit stellen oder ein SMS Gateway anschaffen. Beides für daheim zu großer overhead.

Ansonsten versuche ich alle Infrastrukturdienste zu überwachen, sofern sie durch die jeweilige Software überwachbar sind. Mein DHCP Server ist z. B. in derUnifi (externer Link) USG integriert, hier kann ich den Dienst nicht sauber überwachen, da die Firmware ein geschlossenes System ist.

Anders sieht es z. B. beim Thema Smart Home aus. Hier überwache ich sämtliche Dienste (Home Assistant, zwave to mqtt, zigbee to mqtt, etc) auf deren Ausführung. Ausführung heißt in diesem Falle aber nicht ob die ausführbare Datei gestartet ist, sondern ob der Service wirklich läuft. Ist z. B. das Webfrontend erreichbar oder nimmt der Service auf einem bestimmten Port auch Daten entgegen. Ob das relevante Daten sind, ist hier uninteressant, es geht schließlich einzig und allein um die Verfügbarkeit.

Dazu kommen natürlich noch alle anderen Bereitstellungen wie DMS, Netzwerkspeicher und so weiter. Überall werden, sofern es Sinn macht, natürlich auch Metriken wie CPU oder RAM Auslastung mit protokolliert und grafisch dargestellt.

Homelab Monitoring – Die Software

Wie bereits geschrieben nutze ichICINGA2 (externer Link) als Software. Diese setzt zum Betrieb eine SQL Datenbank voraus. Ich für meinen Teil nutze wo immer es auch geht MariaDB, einfach als persönliche Präferenz.

Alle Metriken bzw. Performancedaten werden in eineInfluxDB Datenbank gespeichert. Die Grafen in ICINGA Web 2 sowohl als auch eigenständige Dashboard werden mittels Grafana realisiert. Dieses greift auf die Influx Datenbank zu und stellt nach meinen Wünschen die Werte grafisch dar.

Wenn du mir schon länger folgst weißt du, dass ich mein Homelab mit ICINGA2 monitore und damit alles im Blick behalte. Seit kurzem setze ich auch FreeIPA als Identity Management ein, also musste ich noch ICINGAWEB2 mitFreeIPA (externer Link) verbinden. Anfangs kein so leichtes unterfangen. Dieses Tutorial hilft dir aber bei deiner ICINGAWEB2 FreeIPA Konfiguration.

Die Installation vonICINGAWEB2 (externer Link) kann ganz regulär nachoffizieller Anleitung (externer Link) durchgeführt werden. Spannend wird es erst, wenn wir das Frontend einrichten möchten. Als Backend nehmen wir entsprechend LDAP und lassen im nächsten Schritt auch schon über Eingabe der Domäne alle Einstellungen suchen.

Eines noch Vorweg: Das ICINGA2 Buch hat mir immer sehr geholfen das System besser zu verstehen und viele Konfigurationen und Anpassungen leicht zu meistern. Solltest du frisch in das Thema einsteigen empfehle ich dir das Buch zu kaufen.

Dies funktioniert natürlich am Besten, wenn man FreeIPA auch direkt als DNS Server einsetzt. Andernfalls kann es sein, dass die Daten nicht korrekt gezogen werden. Eine Anpassung desDNS am ICINGA2 Host ist anschließend notwenig.

Die Einrichtung kann man sogar, wenn man nichts besonderes konfigurieren möchte, einfach immer weiter klicken. Die Konfiguration erfolgt mit dem neuen ICINGAWEB2 Installer fast automatisch.

Nach komplett abgeschlossener Einrichtung müssen wir allerdings noch dieroles.ini Datei anpassen.

[Administrators]
users = "username@domain.tld"
permissions = "*"

Wer möchte passt natürlich noch die Berechtigungen an. In diesem Beispiel ist das mein Administrator-Benutzer, der soll natürlich alle Berechtigungen haben.

Nun können wir über das Frontend bei ICINGAWEB2 anmelden. Als Benutzername müsst ihr den vollqualifizierten Nutzername verwenden. Wie oben in der roles.ini also z. B.

username@domain.tld

Mit dem entsprechenden Passwort zusätzlich eingegeben, habt ihr ein erfolgreichen Login bestritten. Zum Vergleich zeige ich euch noch meine anderen Konfigurationsdateien.

Meine ICINGAWEB2 FreeIPA Konfiguration

Zum Vergleich zeige ich euch noch meine anderen Konfigurationsdateien. Damit sollte es für dich auch möglich sein eine korrekte Verbindung zu FreeIPA durchzuführen.

authentication.ini

[icingaweb2]
user_class = "inetOrgPerson"
filter = ""
user_name_attribute = "uid"
backend = "ldap"
base_dn = "dc=example,dc=com"
domain = "example.com"
resource = "icingaweb_ldap"

groups.ini

[icingaweb2]
resource = "icingaweb_ldap"
user_backend = "icingaweb2"
group_class = "group"
group_filter = ""
group_name_attribute = "gid"
group_member_attribute = "
member"base_dn = ""
backend = "ldap"

ressources.ini

[icingaweb_ldap]
type = "ldap"
hostname = "dc.example.com"
port = "389"
encryption = "none"
root_dn = "dc=example,dc=com"
bind_dn = ""
bind_pw = ""
timeout = "5"

Anschließend sollte der Login problemlos klappen.

EinSYNOLOGY (externer Link) NAS mitICINGA2 (externer Link) überwachen erfordert nicht unbedingt ein gesondertes Plugin, da die Systeme auch ohne Probleme direkt via SNMP überwacht werden können. Fertige Plugins haben allerdings den Vorteil, dass sie schneller zum Einrichten und zum anderen übersichtlicher sind.

Bis vor kurzem habe ich immer mit dem Plugin check_synology gearbeitet. Allerdings hatte das bei mir unter verschiedenen Systemen immer mal wieder zu aussetzern geführt. Aus diesem Grund habe ich mich vor ein paar Tagen auf die Suche nach einem neuen CheckPlugins gemacht und bin natürlich fündig geworden.

SYNOLOGY NAS MIT ICINGA2 ÜBERWACHEN

check_synology.py (externer Link) funktioniert ausschließlich mit SNMPv3, bietet also noch mehr Sicherheit als lediglich über SNMPv2 oder gar v1.

Nach dem herunterladen des Plugins und einfügen des CheckCommands (Pluginersteller liefert das glücklicherweise mit), kann man schon anfangen die Service Checks zu schreiben. Meine sehen derzeit so aus:

apply Service "syno-load" {
check_command = "check_synology"
vars.synology_mode = "load"
vars.synology_host = "$address$"
vars.synology_warning = "$synology_load_w$"
vars.synology_critical = "$synology_load_c$"
assign where host.vars.os_type == "DSM"
}
apply Service "syno-memory" {
check_command = "check_synology"
vars.synology_mode = "memory"
vars.synology_host = "$address$"
vars.synology_warning = "$synology_load_w$"
vars.synology_critical = "$synology_load_c$"
assign where host.vars.os_type == "DSM"
}
apply Service "syno-status" {
check_command = "check_synology"
vars.synology_mode = "status"
vars.synology_host = "$address$"
vars.synology_warning = "$synology_load_w$"
vars.synology_critical = "$synology_load_c$"
assign where host.vars.os_type == "DSM"
}
apply Service "syno-disks" {
check_command = "check_synology"
vars.synology_mode = "disk"
vars.synology_host = "$address$"
vars.synology_warning = "$synology_load_w$"
vars.synology_critical = "$synology_load_c$"
assign where host.vars.os_type == "DSM"
}

Anschließend noch die Host Definition

object Host "synology.int.casalani.de" {
check_command = "hostalive"
address = "10.0.1.21"
vars.os_type = "DSM"
vars.synology_snmp_user = "icinga2"
vars.synology_snmp_authkey = "strenggeheim"
vars.synology_snmp_privkey = "strenggeheim"
}

Anschließend noch die config validieren undICINGA2 neu laden. InICINGA (externer Link) Web 2 sieht es dann so aus:

Nach jetzt mehreren Tagen Test, kann ich sagen, dass das Plugin hervorragend funktioniert. Entsprechend meine Weiterempfehlung.