checkmk Erfahrungen

  • Hallo Miteinander,


    ich denk der Titel sagt schon etwas aus. Ich bin am überlegen von Icinga 2 auf checkmk raw umzusteigen.

    Beide haben zwar Nagios als Kern, aber ich finde check_mk wesentlich angenehmer bei der Konfiguration.

    Auch die Integration in das Ticketsystem Zammad, das ich nutze würde mir gut gefallen.


    Habt Ihr Erfahrungen mit chekmk oder eventuell bessere Alternativen?


    VG Fisi

  • Mahlzeit,


    das letzte Mal mit CheckMK vor ca. 2 Jahren gearbeitet. Was monitorst du denn so alles?

    Icinga2 ist ja "nur" ein Monitoring Framework, von Haus aus ist da checkmk besser. Allerdings war ich in checkmk oft an dem Punkt angelangt wo ich dann doch wieder selber Pakete "backen" muss und die GUI fand ich sehr unübersichtlich. Die Appliance ist ein netter Ansatz, allerdings mag ich es zu wissen was so alles darin läuft und konfiguriert ist. Und zudem entspricht sie nicht meinem "Ansible" Ansatz für Verwaltung.


    Ich habe was Zeit in Icinga2 und Automatisierung gesteckt, Hosts werden per Ansible / Kubernetes Daemonset ohne zutun registirert. Dies beinhaltet den Austaisch der Zertifikate, feststellen was die Maschine so ist (OS, Memory, Disk, Loadwerte werden automattisch ermittelt etc.) (inkl. Autoscaling in AWS), die Master laufen im HA Modus und koordinieren sich selber. Das heßt Konfig gegen master1 testen, der 2. monitort weiterhin und erst wenn auf dem 1. alles OK ist wird die Konfig automatisch zum anderen übertragen und der 1. monitort in der Zeit. Das fehlt mit bspw an Prometheus sehr.


    integriert ist das ganze dann mit Matrix / Email als Alarmierung. Im Anhang mal ein Beispiel von paar Hostschecks. Die restlichen checks werden von icinga2 containern gemacht, da wird so ziemlich alles gecheckt was man möchte, webseiten status, zertifikate die ablaufen, ob die Netcup SOAP erreichbar ist und Status 200 meldet etc.

    Auch die Master checken sich gegenseitig. Prometheus spielt an der Stelle den Wächter und sammelt die sonstigen Metriken im Cluster so ein.


    Von extern wird das ganze noch von einem Monitoring Dienst gegengeprüft, roundabout sind es ca. 1000 Checks gegen 10 Nodes.



    Gruß,

    Michael

    Files

    • p1.png

      (310.52 kB, downloaded 30 times, last: )
    • p2.png

      (19.52 kB, downloaded 22 times, last: )
    • p3.png

      (41 kB, downloaded 24 times, last: )
  • Habe ausschließlich Erfahrung mit Check_MK und nutze das beruflich und privat.


    Kann also keine Vergleiche zu anderen Systemen anstellen.


    Ich finde bei Check_MK die auto-discovery großartig, und dass der Agent einfach nur ein Shell Script ist, der via SSH abgerufen werden kann. Sprich man kommt an seine Server ran ohne Ports zu öffnen und ggf VPN zu benutzen. Etwaige Pakete die das Script braucht (smart als Beispiel) lässt sich zusammen mit dem Script easy via Ansible installieren/verteilen.


    Auch das erstellen eigener Checks ist sehr einfach, solange kein Plugin auf Check_MK Seite benötigt wird. So überwache ich zum Beispiel den sync meines VDSL Modems mit einem Shell Script, was die Werte aus dem WebUI des Modems holt. Das kann auf einem beliebigen Host laufen und via Piggyback Mechanismus in den richtigen Host hinzugefügt werden.


    Für Jitsi habe ich mir auch ein entsprechenden Local Check gebaut, sodass Check_MK Graphen der Nutzung zeichnet.


    Ein Check Plugin kann in einer beliebigen Programmiersprache geschrieben werden. Schwerfällige Local Checks (Health Checks, APT Update) können gecached werden, sodass diese zum Beispiel nur alle 60 Minuten ausgeführt werden.


    "Richtige Check Plugins" habe ich bisher nicht programmiert, die Local Checks in Verbindung mit Piggyback waren bisher immer ausreichend.


    Bei der Integration in andere Systeme kann ich nichts sagen, ich nutze nur Email Alerts.


    Von der Stabilität ist Check_MK rock solid. Ich nutze das jetzt so zirka vier Jahre und jedes Update ist ohne Zicken durch gelaufen, inklusive Upgrade des Debian auf dem Check_MK läuft. Ich update normalerweise so 2-3 Mal pro Jahr auf die zu dem Zeitpunkt aktuelle Version und verteile dann auch den aktuellen Agent via Ansible auf die Systeme.