Icinga2: welchen remote Agenten nutzen? (Icinga Client, NRPE, check_by_ssh...)

This forum was archived to /woltlab and is now in read-only mode.
  • Hi


    Ich will so langsam zu Icinga2 migrieren... Dabei will ich alt Lasten soweit es geht loswerden :)
    Einer der Lasten ist NRPE. Ich benutze sehr oft check_multi (auch kaskadiert) und gepatchte Version von NRPE (multiline patch). Da ich nicht immer neue Versionen selbst patchen/als RPM bauen will, hätte ich paar Fragen:


    (wir überwachen nur Netzwerk Hardware und Linux/Solaris Hosts)


    Was empfehlt ihr für einen Agenten?
    1. Icinga2 hat nen eigenen 'Agenten' ist der nicht overkill für kleine Checks? (pro/cons)
    2. Was haltet ihr von check_by_ssh? (pro/cons)
    3. Ich meine was gelesen zu haben dass es irgendwann mal ne Alternative/Weiterentwicklung von NRPE geben wird. Ist es so?
    4. Gibts noch was was man sich anschauen könnte?


    Danke im Voraus!

  • Servus,


    Fangen wir mit dem schlechten an:


    3. Weiterentwicklung von NRPE


    Ich hatte mal die Idee, das Ding zu patchen und unter der Icinga Fahne zu maintainen. Das hat sich allerdings als nicht machbar herausgestellt. Zum Einen bist du mit dem SSL-Zertifikats-Patch sofort inkompatibel zum alten NRPE mit anonymous DH, zum anderen ist der restliche Code der da so rumfliegt gelinde gesagt Schrott. Mal abgesehen von dem "Protokoll", welches in abgewandelter Form auch in NSCA und NDO herumfliegt - ein Albtraum, das zu debuggen. (check_nrpe hat ja nedmal einen Verbose-Mode)


    Ich habe gesehen, dass NRPE Upstream auch IPv6 eingebaut hat, allerdings unsauber und mit diversen Bugs, sodass ich das nie in Produktion verwendet habe. Zumal es in letzter Zeit auch massig CVEs und andere Bugs gab, die dem Ganzen einen fahlen Beigeschmack geben, gerade wenn du es in einer sensitiven Umgebungen einsetzt (und eigentlich ist jedes Netz sensitiv, egal ob intern oder extern).


    Ich hab das letztens mal für einen Kollegen zusammengefasst:



    2. check_by_ssh


    Dadurch dass man sich mit Icinga 2 und Command Argumenten etwas schwertut, hier den zusätzlichen Transportlayer einzubinden (ist bei NRPE ähnlich kompliziert), ist es jetzt nicht so wirklich passabel einzubinden. Ansonsten taugt es aber durchaus als NRPE Ersatz, und ist in vielen Umgebungen das mittel der Wahl, wenn es um sichere Verbindungen geht. Ich kenne aber auch das Zombie-Problem, wenn der Client die Verbindung nicht sauber zumacht, und man sich dann irgendwann mit der ssh(d)_config die Kugel gibt.


    [musste das splitten, wieder mal mehr als 10000 Zeichen geschrieben]

  • 4. andere Agenten


    Man kann sich NSClient++ auch auf Linux installieren, und dessen Check-Plugin dann verwenden. Ich kenne aber ehrlich gesagt niemanden der das macht, oder wo das dokumentiert ist. Subjektiv gesehen ist NSClient++ für mich auch nur auf Windows zuhause und dort auch nicht als Service, sondern als lokales Plugin welches Windows-Metriken analog zu WMI und Konsorten zurückliefert. Ansonsten - checkmk erfordert seine eigene Welt, und solangs dort keinen Icinga 2 Support gibt, braucht man sich das imho auch nicht anzusehen.


    1. eigener Icinga 2 Client


    Dieser Client ist mit dem Anspruch entstanden, out-of-the-box verteiltes Monitoring durchführen zu können. Klarerweise weiss man von Anfang der Entwicklung bis hin zum fertigen Release und danach noch nicht genau, in welche Richtung die Community das nun verwenden mag. Weswegen es verschiedene Rollen eines Clients gibt, was die Sache natürlich planungsbedingt komplizierter macht.


    http://docs.icinga.org/icinga2…lient-configuration-modes


    Zum Einen ist ein Client oder Satellit auch nur ein Icinga 2 (Core) mit einem lokalen Scheduler und allen Features. Konfiguriert man den Satelliten bzw Client (im Fachjargon "Node" wie in der Doku und den Wizards genannt) dann lokal, zb beim Ausrollen oder via Konfigurationsmanagementtool, kann mittels inventory und update-config am Master sichergestellt werden, dass die Konfigurationsobjekte generiert werden und damit die vom Client erhaltenen Checkergebnisse auch verarbeitet werden. Hierzu gibts entsprechende Setup-Wizards, die einem die Arbeit des SSL-Zertifikat-Generierens sowie weiterer adaptiver Konfiguration abnehmen.


    Dabei ist es völlig egal, ob man nun auf Linux, Unix oder Windows arbeitet - Icinga 2 wird auf all diesen Plattformen entwickelt und getestet. Hinsichtlich Windows gibts den Support allerdings nur als Client, mit eingeschränktem Feature-Set (zB Livestatus mit Unixsocket geht dort ja ned). Nachdem es auf Windows auch keine Monitoring-Plugins gibt, hat ein Kollege die ehrenvollen Aufgabe erhalten, Pendants davon für Windows zu entwickeln, welche beim Installationsvorgang auf Windows ebenso installiert werden. Heisst im Umkehrschluss, dass du auf jedem Client ein Basisset an Plugins und vorkonfigurierten Services auf dem lokalen Host (FQDN) hast (die Beispiel-Konfiguration wird hier praktisch direkt verwendet als Ausgangspunkt).


    http://docs.icinga.org/icinga2…lient-configuration-local


    Wenn dir die eierlegende Wollmilchsau zuviel ist, und du eigentlich nur NRPE-Like Commands auf anderen Knoten (Nodes) ausführen willst, gibt es die Möglichkeit, diese Knoten als "Command Execution Bridge" zu konfigurieren. Hierzu solltest du allerdings schon mal was von Zonen und Endpoints gehört haben, denn das zugrunde liegende Kommunikationsprotokoll zwischen Icinga2 Knoten ist generisch das Cluster-Protokoll, und die entsprechende Konfiguration wird bei ersten Setup-Wizards vorgenommen. Für diesen Modus kannst du das ähnlich tun, lediglich am Master müssen diese neuen Knoten derzeit noch händisch konfiguriert werden. Hintergrund von Zone und Endpoint ist - Aufbau der Kommunikation (Endpoint, Host/Port) und Vertrauenswürdigkeit (Zonen-Member, Parent-Child).
    Sobald das Setup steht, kannst du mittels additivem "command_endpoint" Attribut in einem Host oder Service-Object am Master (oder Satellit der Clients anspricht) steuern, wo diese Checks ausgeführt werden. Neben dem obligatorischen Client gibts auch Leute, die den command_endpoint innerhalb von HA-Cluster-Zonen verwenden, um etwa Gesundheitschecks durchzuführen - du siehst, alles ist in sich verzahnt.
    Wichtig bei diesem Setup ist - die CheckCommand Objekt-Konfiguration muss auch am Client liegen, denn hier kannst du einschränken, welche Command-Argumente vom Master geschickt auch tatsächlich verarbeitet werden. Manche Setups erfordern eingeschränkte Clients, die etwa bestimmte Check-Attribute nicht überschreiben dürfen, da statisch konfiguriert (Passwörter sind so ein Ding).


    http://docs.icinga.org/icinga2…figuration-command-bridge


    Und last but not least haben wir festgestellt, dass der Config Sync im Cluster mit zones.d und entsprechenden Zonen und Endpoints sich auch klassisch in Master-Satellite-Client Szenarien abbilden lässt, und man mittels globaler Template Zone zB CheckCommands, Groups, Apply-Regeln, etc verteilen kann. Hierbei gibt es eigentlich keinen Unterschied, man definiert lediglich eine Rolle für den Knoten und behandelt ihn entsprechend.


    http://docs.icinga.org/icinga2…ration-master-config-sync


    Und weils so schön ist, lassen sich die 3 Szenarien auch mischen. Wird natürlich höchstgradig komplex und ohne Drawing Board und Test-Setup eventuell schwierig. Aber in der Summe denke ich, dass man sich mit Icinga 2 alleine schon austoben kann, und unser Anspruch ist es auch, das in Zukunft soweit zu verfeinern, dass man keine externen Abhängigkeiten hat (ausser den Plugins, ohne die das Ökosystem niemals so erfolgreich geworden wäre, und wir deshalb bis ins Jahre Schnee als Schnittstelle supporten werden ;)).


    Sicherheitstechnisch betrachtet kommst du an einer CA und SSL-Zertifikaten heutzutage nicht mehr vorbei, und dank cli und setup Tools ist die Sache auch nicht so schwierig, wie etwa openssl direkt auf der Shell. Der Security-Audit in so mancher Firma freut sich auf jeden Fall.


    X. Overkill?


    Natürlich kann man Services auch mit deren eigenen Protokoll überwachen, oder klassische Wege wie SSH oder SNMP wählen. Vielerorts kann man auch gar keine zusätzliche Software auf den Clients installieren, sei es Policy-Restriktion oder technische Nicht-Machbarkeit - aber dort wo man kann, sollte man mit Bedacht auf ein homogenes Setup und der Maintenance immer darauf achten, möglichst wenige externe Komponenten zu verwenden. Solltest du den Icinga 2 Client verwenden, bekommst du zusätzlich die Möglichkeit, mit deinem Feedback und ggf Anforderungen das Produkt (nennen wirs mal so, auch wenn es keine Enterprise Edition geben wird) in der Summe besser zu machen.


    Und es gibt hinsichtlich Support auch eine zentrale Anlaufstelle - uns. Wenngleich ich dir nicht garantieren kann, komplexe Probleme adhoc zu lösen. Bei solchen Szenarien, die dann auch schon NDAs erfordern um alle Möglichkeiten zu durchdenken, empfehle ich dann gerne die Möglichkeiten eines Dienstleisters, wenngleich das nicht sein muss. Erfahrunsgemäss redet es sich leichter in Person - was mich auf ein anderes Thema bringt: Vielleicht ist deine Migration ja ein Thema für die OSMC, der Call for Papers läuft gerade :-) Fallstricke, Planungsdetails, Best Practices, Anbindung von spezieller Hardware - ich finde das immer sehr interessant zu sehen wie andere Probleme lösen :)


    PS: Weil du gesagt hast, dass du Netzwerkhardware verwendest - ich sehe immer mal wieder Aktivität bei meiner Kopie der Manubulon SNMP Plugins (für die wir in Icinga 2 auch Plugin Check Command Definitionen direkt mitliefern). Vielleicht magst du dich daran auch beteiligen, oder rumpatchen - ich plane da irgendwann noch die Doku in Markdown reinzudonnern, und jedem Zugriff auf das Repo zu geben, der das pflegen mag: https://github.com/dnsmichi/manubulon-snmp

  • erst mal vielen dank für die zwar Ausführliche aber auch richtig übersichtliche Antwort!


    Ich habe es mir schon fast gedacht dass ich prinzipiel am besten mit dem Icinga Client fahre. Auf den werde ich mich jetzt fokusieren bei weiterer Plannung.


    Was SNMP angeht verwende ich es nur für Router/Switche/Loadbalancer und fahre (bis auf kleine Bugs) gut mit dem check_nwc_health. Der wird ja mit Fokus Netzwerkappliances entwickelt und IMHO die umfangreichste Sammlung was sowas angeht. Leider kann man da nicht so einfach Bugs melden (oder ich habe nix gefunden), da man nichts mehr zu dem Blog hinzufügen kann (habe ich frueher mal gemacht) bzw. für Forum Sign In braucht man irgendwelche Invitingcodes... Ich hoffe dies ändert sich, habe da auch schon entsprechend Mail geschrieben. Habe paar Bugs gefunden in Verbindung mit relativ aktueller Hardware und habe selbst einen Check für Brocade 4G SSL/ADX Loadbalancer entwickelt der vielleicht gut dort passen würde. Naja mal sehen.


    Eine Frage hätte ich noch, wie siehts mit Icinga Client auf aktuellem Solaris aus? Gibts da was fertiges oder so? Irgendwelche Tips?


    Danke im Voraus!

  • Servus,


    Ne, bei Solaris musst du dich einlesen, es ist aber mit einem gängigen gcc (4.7+) auch darauf zu kompilieren (das Sunstudio geht definitiv nicht, deren Compiler ist zu alt). Wie man Icinga2 von Hand baut, findest du sowohl in der INSTALL.md wie auch in Paketen von *BSD, Gentoo, ArchLinux oder eben auch Spec-Files/Debian Control Files. Solaris ist eines der Themen, wo ich raus bin - das schau ich mir nur an, wenn mich jemand zwingt :-)


    Ad check_nwc_health - einfach mal Gerhard anhaun, er liest ja hier auch mit. Meine Kollegen mögen das Plugin auch gerne, das Manubulon Zeugs kommt eher aus der Ecke "lang rumgelegen, immer mal wieder verwendet".


    Hinsichtlich Client - der ist auch Teil der Icinga 2 Basic Schulung, und da hat ihn jeder soweit verstanden. Cluster Config Sync gibts aber erst in der Advanced Schulung, weil das ein zu harter Brocken ist ;-) Wenn ich mal Zeit finde, baue ich auch die Vagrant Boxen auf einen Client um, aber derzeit gefällt mir das Cluster-Konstrukt einfach besser, auch weil ich dort den command_endpoint auch verwenden kann für Demo-Zwecke ;-)