Monitoring: Check-MK 2.0

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Monitoring: Check-MK 2.0

Beitrag von heisenberg » 13.07.2021 15:05:44

Hallo zusammen,

ich möchte gerade mal wieder über eines meiner Lieblingsprogramme berichten: Das Monitoring-System Check-MK.

Anfang März 2021 wurde die neue Version 2.0 veröffentlicht. Check-MK gibt's grundsätzlich in 3 Editionen:
  • Check-MK Raw Edition (Komplett OpenSource)
  • Check-MK Enterprise Edition(proprietär)
  • Check-MK Managed Service Edition(proprietäres Cloud Zeugs, k. A.)
Da wir hier im Debianforum sind, ist alles was nicht Open Source mal uninteressant und darüber werde ich kein Wort verlieren, falls es nicht im Zusammenhang mit der OSS-Variante relevant ist. Die Raw Edtion ist installierbar auf Stretch und Buster, d. h. dafür sind Debianpakete verfügbar. Der Code ist via github verfügbar. Siehe: https://github.com/tribe29/checkmk

zu Check-MK

Check-MK ist eher ein Schwergewicht unter den Monitoring-Systemen. Damit gemeint ist, dass es sich auf einem eigenen System am wohlsten fühlt und vom Umfang dafür gedacht ist mindestens eine Hand voll oder mehr Server/Netzwerkgeräte zu überwachen.

Ich mag das Check-MK weil es für mich selbst Spaß macht es zu verwenden. Ich verwende die RAW-Edition jetzt schon ein paar Jahre lang und es ist für mich eine Software, die ich nicht missen möchte. Dort wo mich z. B. Prometheus / Grafana überfordert, bzw. mir das einfach viel zu viel Arbeit ist, mir eigene Dashboards selbst zusammen zimmern zu müssen, da freue ich mich, dass das bei Check-MK erst mal in einem funktionsfähigen Zustand ist und im Ausgangszustand optimiert auf Benutzerfreundlichkeit und Effizienz. Und es gibt eine Vielzahl von Möglichkeiten, wo man sich mit eigenen Erweiterungen und Anpassungen reinhängen kann, um die eigenen Anforderungen umzusetzen.

Auf zur Version 2.0!

Ich habe jetzt selbst bewusst ein paar Monate gewartet, bis ich anfange mit der 2.0 zu experimentieren, damit ich ggf. nicht mit anfängliche Bugs der neuen Version rumschlagen muss. Dann habe ich jetzt aber meine vorhandene Monitoring-Instanz geklont, die alte stillgelegt und den Klon über 2 Major-Releases auf die neue Version aktualisiert. Das ging insgesamt recht stressfrei. Manche individuellen Checks musste ich neu schreiben. Andere laufen aufgrund von Auto-Migration in der neuen Version problemlos. Ich hatte mit viel mehr Aufwand gerechnet, weil das Monitoringsystem bei mir über die Zeit schon ganz gut gewachsen und immer wieder einige Anpassungen erfahren hat.

Was gibt's neues in der Version 2.0?

Was mir persönlich positiv aufgefallen ist:
  • Das Interface ist deutlich überarbeitet worden. Es ist vereinfacht und umgestaltet worden und checkmk-spezifische Terminologie ist durch generische ersetzt worden: z. B. "WATO" -> "Setup". Ehrlich gesagt, hat mir das Interface schon sehr gefallen und deswegen hätte es für mich da keine Änderung gebraucht. Allerdings habe ich mich recht schnell an die Änderung gewöhnt. Ziel der Änderungen ist es vor allem, dass es ein sauberes UI-Konzept darstellt, d. h. dass Neue damit möglichst gut zurecht kommen.
  • Modernes Dark-Theme als default. (Ich fand das alte besser, aber gut, ist halt so...)
  • Die Erstellung von Checks ist durch eine neue API deutlich vereinfacht worden. Auch grafische Elemente(Graphen, Perf-O-Meter) und Metriken lassen sich sehr viel einfacher anpassen als vorher.
  • Das HTML5-Graphensystem ist aus der Enterprise-Edition in die RAW-Edition gewandert. Es sieht deutlich besser aus als das PNP4NAgios, das vorher hier im Einsatz war.
  • Es gibt noch so einiges mehr, aber darüber kann ich persönlich noch nix sagen. Siehe: https://checkmk.com/de/produkt/neueste-version
Arten von Checks

Es gibt mehrere Arten von eigenen Checks mit denen man selbst Systeme überwachen kann:
  • Lokale Checks: Die laufen lediglich auf den überwachten Geräten und werden automatisch vom Monitoring Server erkannt. Eine sehr einfache Art, eigenen Checks umzusetzen.
  • Datenquellen Checks: Diese laufen auf dem Monitoringserver und bestehen in Skripten die auf beliebige Weise Daten für das Monitoring von Systemen sammeln(z. B. Daten eines Virtualisierungsclusters holen und den Systemen im Monitoring zuordnen.)
  • Plugin-basierte Checks: Diese Checks haben eine Client-Komponente(auf dem überwachten System, beliebige Programmiersprache) und eine Server-Komponente(Python3). Damit ist mehr möglich, z. B. können Schwellwerte unabhängig vom Client durch regelbasierte Konfiguration flexibel auf unterschiedliche System angewendet werden. Auch hat man hier einen serverseitigen Status. Beispiel-1: Wenn eine Festplatte auf einem Server per SMART mit z. B. 12 "Pending Bad Sectors" eingelesen wird, dann ist der Zustand OK. Sobald ein neuer Pending Bad Sector dazu kommt (oder evtl. weniger wird, weil der Status zu Defekt übergeht), dann gibt es eine Warning. Beispiel-2: Bei den Dateisystemen kann eine bestimmter Speicherverbrauch pro Zeiteinheit(z. b. Platzverbrauch von 20 GB pro Tag) eine Warnung auslösen. Das könnte ein Client-seitiger Check u. U. auch; aber dann wäre die zentrale Konfiguration nicht möglich bzw. viel schwieriger.
Beispiel für die neue Check-API

Auch wenn die offizielle Dokumentation die Erstellung von eigenen Checks sehr ausführlich erklärt, hier mal ein persönlich genutztes und dokumentiertes Beispiel für die neue Check-API bei der Umsetzung eines Plugin-basierten Checks:

Zweck: Check zur Überwachung ob zugewiesene öffentliche IPv4-Adressen konfiguriert sind oder ob da eine fehlt.

Client-Komponente(Hier hat sich nix geändert):

Code: Alles auswählen

#!/bin/bash
#
#	check-plugin to display ipv4 addresses of the current system
#
#	example output(anonymized):
#
#	<<<ipv4>>>
#	IP x.y.162.124
#	IP x.y.162.250
#	IP 172.18.0.1
#	IP 172.17.0.1
#
export LC_ALL=C
export IP_REGEX="(([0-9]{0,3}[.]){3}[0-9]{0,3})"

echo "<<<ipv4>>>"
# prüfen ob "ip" vorhanden ist,
if which ip >/dev/null ; then
        while read line ;do

                line="${line##*inet }"
                line="${line%% *}"
                line="${line%%/*}"
                echo "IP $line"
                # es wird nur 127.0.0.1 ausgefiltert. 192.168... und 172... 
                # könnte man hier bereits auch ausfiltern. Ich habe mich 
                # entschieden das serverseitig zu tun
        done < <(	
        			ip a 			\
        		| 	grep "inet "		\
        		| 	grep -v 127.0.0.1	\
        		| sed -re "s/^.*inet ($IP_REGEX)[^0-9].*/\1/"
        		)

# wenn kein "ip" vorhanden, dann wird ifconfig verwendet
elif which ifconfig >/dev/null ;then
        IP_ADDRESSES="$(
			ifconfig 
        	      |	sed -r -n -e '/127.0.0.1/n' 	\
        		          -e "/^.*inet (addr:)?($IP_REGEX)[^0-9].*$/s/^.*inet (addr:)?($IP_REGEX)[^0-9].*$/\2/p")"
        for IP in $IP_ADDRESSES ; do
                echo IP $IP
        done
fi
Und das ist jetzt die neue serverseitige Komponente:

Code: Alles auswählen

# Importiere das API-Modul der neuen Check-API für diesen check
from .agent_based_api.v1 import *

# Das ist der Definitionsblock
#
# name: ist der Name des Checks und auch Abschnitts aus dem Datenbereich 
# des Agenten(=Client-Komponente)
# service_name: ist der Name, mit dem der Check in der Oberfläche angezeigt wird.
#               Das %s ist der Platzhalter, indem das Item aus der discover Funktion
#               eingesetzt wird.
# check_function: ist die Funktion die die regelmässigen Prüfungen durchführt.

register.check_plugin(
    name = "ipv4",
    service_name = "IPv4 %s",
    discovery_function = discover_ipv4_addresses,
    check_function = check_ipv4_addresses,
)

# Discover-Funktion: Erkenne die Instanzen des Checks auf dem überwachten System.
# Hier: Jede IP-Adresse bzw. jede Zeile) ergibt einen Check für einen Host
# section sind alle Zeilen aufgesplittet in Felder des Abschnittes "<<<ipv4>>>"

def discover_ipv4_addresses(section):
    for txt, address in section:
        yield Service(item=address)

# Prüf-Funktion
# Jetzt wird über den Inhalt des ipv4-Abschnittes iteriert. Dabei werden
# alle checks, deren IP-Adressen auch bei der Discovery da gewesen sind und
# jetzt wieder gefunden werden als OK bestätigt, ansonsten gibt's den Warn-Status

def check_ipv4_addresses(item, section):
    s = State.WARN
    summary = "ip address not found"
    for text, address in section:
        if address == item:
            s = State.OK
            summary = "ip address found"
    yield Result( state = s, summary = summary)
Allgemeine Zusatzbemerkungen zu Check-MK
  • Die Dokumentation ist in Deutsch und Englisch verfügbar. Sehr kompakt, umfassend und sehr hohe Qualität. Details bzgl. der neuen Konfigurationsmöglichkeiten der Weboberfläche fehlen noch teilweise. Da musste ich schon etwas in den Konferenvideos/Präsentationen graben, bis ich ein Problem gelöst bekommen habe. Dokumentation in Deutsch: https://docs.checkmk.com/latest/de/
  • Die Tutorial-Videos sind mal neu erstellt worden. (Allerdings noch auf dem Stand von Version 1.6. Playlist auf YouTube: https://www.youtube.com/watch?v=g1g2ztX ... 9Rtwu9rfzW , Der "Chef" Mathias Kettner hatte die diesmal selbst gesprochen.)
  • Ein Forum(deutsch+englisch) gibt es dazu mittlerweile auch: https://forum.checkmk.com
  • Eine Plattform, auf der man eigene Checks(im MKP-Format(=ein tar-basiertes Format)) veröffentlichen kann findet sich hier: https://exchange.checkmk.com
Sonstige Anmerkungen
  • Check-MK ist mit Sicherheit nicht die reine Open Source-Lehre. U. a. deswegen, weil die Entwickler eher ein System haben möchten, dass die Administratoren so gut wie möglich unterstützt und das Leben einfacher macht. Die Entwicklung lässt das, was die Nutzer wollen auch immer recht stark miteinfliessen: Es werden bei den Konferenzen immer auch Umfragen durchgeführt, welche der Ideen aus der Firma vom Nutzerkreis gewünscht werden. D. h. es werden auch Elemente umgesetzt, die man bei strukturell sauberer Herangehensweise vielleicht anders lösen würde. Da fällt mir z. B. die Agent-Bakery(Enterprise Edition) ein: Das ist eine Softwareverteilung direkt durch das Monitoring-System. Das macht man vielleicht meistens eher über ein dediziertes System wie z. B. Ansible und Konsorten. Fazit: Wer ein strukturell sauberes OSS-Monitoring System will, der ist wahrscheinlich bei Icinga-2 (oder evtl. bei Zabbix?) besser aufgehoben.
  • Der Agent läuft in der Voreinstellung auf der Client-Umgebung als "root", aus dem Grund, weil viele Informationen, z. B. die, die mittels spezieller HW-Tools ausgelesen werden root-Rechte erfordern. Das kann man natürlich ändern, aber damit ist natürlich etwas Aufwand verbunden. Im Forum gibt es entsprechende Diskussionen dazu.
  • Weiterhin ist natürlich die Frage: Wie geht es mit der RAW-Edition weiter? Ein wesentlicher Punkt, ist das die RAW-Edition als Kern entweder auf Icinga-1 oder auf Nagios setzt. Icinga-1 ist seit langem vollständig durch Icinga-2 ersetzt und die Nagios Entwicklung ist AFAIK gefühlt seit langer Zeit im Stillstand bzw. tot. Allerdings vermisse ich selbst auch trotz dieses Nachteils seit Jahren nichts.
  • Wenn Euch selbst diese Software nicht gefällt und Ihr meint, XYZ ist aber viel besser, dann öffnet doch bitte einen eigenen Thread in dem Ihr Eure Begeisterung für XYZ ausführlich darlegt. Hier würde ich mir wünschen dass das Thema bei CheckMK bleibt. Danke!
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
TRex
Moderator
Beiträge: 8038
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: Monitoring: Check-MK 2.0

Beitrag von TRex » 13.07.2021 18:20:48

heisenberg hat geschrieben: ↑ zum Beitrag ↑
13.07.2021 15:05:44
Wenn Euch selbst diese Software nicht gefällt und Ihr meint, XYZ ist aber viel besser, dann öffnet doch bitte einen eigenen Thread in dem Ihr Eure Begeisterung für XYZ ausführlich darlegt. Hier würde ich mir wünschen dass das Thema bei CheckMK bleibt. Danke!
+1

CheckMK ist mir übrigens zu fett. Bessere Software ist in CheckMK enthalten. *micdrop* :P
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!Wie man widerspricht

Antworten