Thruk und Icinga2 HA Cluster

  • Hallo,


    hat jemand Erfahrung mit Thruk als Frontend für ein Icinga2 HA Cluster?


    Mir stellen sich folgende Fragen:


    - sollte ich beide Icinga2 Cluster Nodes als Peers im Thruk konfigurieren und einen auf hidden stellen?
    - Wenn ich einen Schnell-Command über Thruk absetze, wird der dann an beide Cluster Nodes übermittelt?
    - Gibt es eine Möglichkeit wie Thruk automatisch erkennt, welcher der Icinga2 Cluster Nodes aktiv ist, wenn einer ausgefallen ist?


    Gruß, Andy

  • Bei Icinga2 rate ich zwischen Thruk und Icinga noch LMD zu hängen (https://github.com/sni/lmd)
    Das löst gleich mehrere Probleme auf einmal:
    - LMD unterstützt mehrere Connections pro Peer und macht automatisch ein Failover
    - LMD korrigiert einige Bugs in der Icinga2 Livestatus Implementierung
    - LMD macht die Sache nochmal schneller


    LMD ist in der OMD-Labs Edition gleich mit dabei. Ansonsten aber auch schnell installiert, ist ja nur ein go-binary.
    Ein offenes Problem sind die Compat Logfiles in Icinga2 welche in einer HA Umgebung "broken by design" sind. Die Timestamps
    stimmen nicht und das Problem lässt sich wohl auch so einfach nicht lösen. Wir arbeiten gerade an einem Import der
    IDO Logfiles in die Thruk Logcache DB in der Hoffung dass dort die Daten stimmen.
    Kommandos werden hierbei an einen Node geschickt, ich nehme an dass Icinga2 das dann intern im Clustern klären kann was da wie syncronisiert werden muss.


    Doku:
    - https://github.com/sni/lmd
    - https://labs.consol.de/omd/packages/lmd/

  • Vielen Dank für den Tipp mit dem LMD!
    Das ist genau was wir benötigen, da wir nicht nur ein neues Icinga2 HA Cluster haben, sonder auch noch diverse alte Nagios- und Shinken Instanzen ablösen, die aber während der Migrationsphase eine zeitlang simultan alle unter einem einzigen Thruk Frontend eingebunden werden sollen...


    Und abgesehen von den inhärenten Problemen bei Logfiles in einer Cluster Umgebung, macht es auch aus Performancegründen bei einer größeren Umgebung gar keinen Sinn Logfiles zu benutzen. Unser altes Monitoring basiert auf Shinken + MongoDB Backend, da sind die Thruk Reports sogar bei Abfragen über mehrere Jahre richtig flott!
    Ich hoffe Icinga2 + IDO DB wird genauso gut und schnell funktionieren...


    Wie sich die commands bei einem Icinga2 Cluster verhalten werde ich einfach mal noch ausprobieren.

  • Leider komme ich bei der Installation von LMD nich weiter.
    Ein # go install github.com/sni/lmd/lmd führt zu folgendem Fehler:
    can't load package: package github.com/sni/lmd/lmd: cannot find package "github.com/sni/lmd/lmd" in any of: /usr/local/go/src/github.com/sni/lmd/lmd (from $GOROOT) ($GOPATH not set)
    Und ein # go get github.com/sni/lmd/lmd läuft ein paar Sekunden, endet ohne Fehler aber scheint sonst nichts weiter zu tun...
    Leider kenne ich mich mit go nicht gut aus, daher wäre ich für jeden Tipp dankbar!

  • Wie die LMD Installation klappt habe ich jetzt herausgefunden:
    - $GOPATH auf ein lokales Go Repository Verzeichnis setzen
    - Zuerst # go get github.com/sni/lmd/lmd um das LMD package und alle Dependencies herunterzuladen
    - Dann funktioniert auch das # go install github.com/sni/lmd/lmd

  • Der LMD funktioniert auch schön, allerdings nur mittels manuellem Aufruf. Also z. B.: # lmd --config /etc/thruk/lmd.ini


    Wenn ich die LMD Parameter (use_lmd_core etc.) in der Thruk Konfig definiere, wird der LMD bei mir mit folgenden Argumenten gestartet:
    /opt/apps/go/bin/lmd -pidfile /var/cache/thruk/lmd/pid -config /var/cache/thruk/lmd/lmd.ini -config /etc/thruk/lmd.ini


    Und verwendet wird wohl die Konfig aus /var/cache/thruk/lmd/lmd.ini in der aber nur irgendwelche Defaults stehen, die dazu führen dass der LMD deamon nach dem Starten direkt wieder crashed...


    - Thruk Version: 2.12~2
    - LMD Version: 1.0.2

  • Ich habe die Icinga2 Backends als Connections in /etc/thruk/lmd.ini definiert und im Thruk als Backend nur noch LMD als type=livestatus und peer=127.0.0.1:3333 eingetragen.
    Ist das nicht die normale Konfigurationsweise?

  • Also wenn ich das jetzt richtig verstanden habe, trage ich in der lmd.ini, die ich in der Thruk config (thruk_local.d/lmd.cfg) bei lmd_core_config=/etc/thruk/lmd.ini eintrage nur die allgemeinen Parameter ein, wie Loglevel etc., aber keine [[Connections]]. Wenn ich Thruk dann mit use_lmd_core=1 starte, wird vom Thurk der lmd Prozess automatisch mitgestartet und die lmd Konfig zusammengeführt aus der lmd_core_config und den Backends, die ich als <peers> in der Thruk Konfig eingetragen habe.



    Allerdings treten dabei bei mir zwei Probleme auf:


    1:


    In /etc/thruk/lmd.ini habe ich definiert:
    Listen = ["127.0.0.1:3333"]



    In /var/cache/thruk/lmd/lmd.ini steht aber:
    Listen = ['/var/cache/thruk/lmd/live.sock']



    Den Socket /var/cache/thruk/lmd/live.sock gibt es aber gar nicht und daher findet Thruk auch keine Backends.



    2:
    Wie kann ich in den Thruk <peer> Einstellungen konfigurieren, dass es sich um ein Cluster handelt?
    Ich möchte im LMD für das Icinga2 Cluster ja dann eine [[Connections]] mit den zwei Icinga2 Cluster nodes in der source und nicht zwei einzelen [[Connections]] mit je einer source.



    Sollte ich dafür vielleicht ein Issue im LMD Github aufmachen?



    Viele Grüße,
    Andy

  • Ja, fast alles richtig. Ich würde die manuelle lmd.ini aber erstmal leer lassen und schauen dass es damit klappt und erst dann erweitern. Loglevel, listen und logfile wird eh schon mitgeneriert und landet alles in /var/cache/thruk/lmd.


    Wenn du Icinga2 im Cluster laufen lässt, trag einfach 2 Adressen ein:


    Code
    1. <Component Thruk::Backend>
    2. <peer>
    3. name = icinga2
    4. type = livestatus
    5. <options>
    6. peer = 192.168.70.10:6557
    7. peer = 192.168.70.20:6557
    8. </options>
    9. </peer>
    10. </Component>
  • Ahh, danke für den Tipp! Ich wusste nicht, dass man im Thruk Backend zwei peers eintragen kann. Ein kleiner Hinweis in der Thruk Doku wäre ganz nett ;))


    Ich habe jetzt in der lokalen lmd.ini (/etc/thruk/lmd.ini) nur noch zwei Einträge: LogFile und LogLevel. Damit übernimmt LMD nun schön das Backend Cluster aus der Thruk Konfig als [[Connections]] Cluster.
    Und wenn ich in der lokalen lmd.ini keinen Listener Eintrag habe wird auch der Socket (/var/cache/thruk/lmd/live.sock) erstellt und funktioniert.
    Allerdings musste ich die /var/cache/thruk/lmd/lmd.ini manuell löschen, damit Änderungen in der /etc/thruk/lmd.ini auch wirksam werden.



    Ansonsten funktioniert der LMD jetzt wunderbar! Danke! :)

  • Das mit den mehreren Peers steht deswegen nicht in der Doku weil es tatsächlich nur im Zusammenspiel mit LMD und Icinga2 verwendet wird. Und wie gesagt, die Doku steht auf github und freut sich über jeden der mithilft.
    Ich hab mal angefangen und hier eine LMD Seite gestartet: https://thruk.org/documentation/lmd.html
    Über den Link oben zu Github kann sie direkt Online editierit werden.

  • Ich hab mal ein Unterkapitel für das Icinga2 Cluster Setup hinzugefügt...


    Der LMD ist auf jeden Fall eine super Sache und bei einer verteilten Monitoring Infrastruktur echt viel wert!
    Wenn du vorhast noch weiter daran zu entwickeln und ein paar Betatests brauchst, helf ich gern :)

  • Danke für den Pull Request.
    Nun ja, verteiltes Monitoring mit Thruk würde ohne auch gehen. Mit LMD gehts halt schneller und der Hauptgrund war
    tatsächlich eine einheitliche Livestatus Schnittstelle zu schaffen die aus unterschiedlichen Quellen befüttert werden kann.


    Für die Zukunft sind noch ein paar Sachen geplant.
    - Ein Clustermodus wird definitiv kommen. Hierbei wird LMD dann im Cluster laufen und selbstständig die Last und Backends verteilen. Derzeit fahren wir LMD mit bis zu 200 Nagios Cores im Backend, aber da erwarten wir nächstes Jahr nochmal einen krassen Zuwachs mit bis zu 10.000 Nagios Cores.
    - Eine Rest Api wird vermutlich kommen, allein schon damit die Instanzen sich im Cluster unterhalten können.
    - SSL Unterstützung wäre auch noch eine Idee


    Mal sehen was 2017 so bringt, aber da wird auf jeden Fall noch einiges kommen.

  • nächstes Jahr nochmal einen krassen Zuwachs mit bis zu 10.000 Nagios Cores.

    Keine falsche Bescheidenheit :) 
    Es sind 11.000


    Gerhard

  • Das klingt ja sehr vielversprechend!


    Wenn LMD als Cluster laufen soll, gilt das für die stand-alone Version nehm ich an. Ein Thruk Cluster macht ja wahrscheinlich nicht so viel Sinn, es sei denn hinter einem Load Balancer...


    Für die stand-alone Version kommen dann bestimmt noch so nette Sachen wie systemd units? :))


    Viele Grüße und schöne Feiertage!


  • Für die stand-alone Version kommen dann bestimmt noch so nette Sachen wie systemd units? :))

    Was genau meinst du?
    Und klar, in erster Linie sprech ich von einem LMD Cluster. Aber auch Thruk Cluster machen in großen Umgebungen Sinn und haben allerdings ganz eigene Herausforderungen, wie, z.B.: cronjobs, dashboards, reports, usw...

  • Wenn die Monitoring Engine in einem HA Cluster läuft wäre es natürlich eine tolle Sache, wenn das Frontend ebenfalls keinen single point of failure darstellt und eine HA Implementierung unterstüzten würde... aber wie du sagst, stell ich mir das auch nicht ganz einfach vor.


    Ich mein ein init script / systemd unit-file zum Starten von LMD als daemon...