Nagios Weakness – mir bekannte Schwächen von Nagios

Das ist eine Sammlung von Merkwürdigkeiten oder Mängeln in Nagios, über die ich mich in meiner Zeit als Nagios Consultant geärgert hatte. Keine Garantie auf Vollständigkeit. Im Gegenteil manche Mängel können auch mit der aktuellen Version schon behoben sein. Ich schreibe mir diese hier zusammen, damit sie nicht verloren gehen.

Schwächen in der Konfiguration

• Benennung der Parameter. Mal mit Unterstrich, mal ohne. Mal Mehrzahl, mal Einzahl. Gut das es oft mehr als eine Möglichkeit gibt.
• Redundanz in der Konfiguration: Wo ist etwa der Unterschied zwischen Parents und Hostdependencies? Parents sind nur eine besondere Art von Hostdependencies, oder?
• Nagios versucht über die „illegal_.._chars“ Sicherheitsprobleme in der Konfig zu lösen. Dabei macht einen genau dies das Leben schwer. Es gibt nämlich keine Möglichkeit Sonderzeichen zu escapen. Noch schlimmer ist, dass alles nach einem Strichpunkt verworfen wird. Braucht man einen Strichpunkt als Parameter muss man tatsächlich das Plugin anpassen oder einen Wrapper schreiben

Schwächen im Daemon

• Das Konzept einer sequentiellen status.dat ist nicht ausreichend. Ein Update der Datei erfordert ein komplettes Neuschreiben. Während des Updates ist der aktuelle Status im Webinterface nicht vollständig. Selbst das Auslagern in eine Ramdisk verbessert diese Situation nicht merklich. Ich habe sogar das Gegenteil beobachtet. Kann das aber nicht erklären.
• Die beste Maschine nützt nichts, wenn Nagios viele Dinge immer nach einander ausführt. Zwar werden mehrere Prozessoren durch die gleichzeitige Aufrufe der Plugins genutzt, aber viele Dinge sind sequentiell nur auf einen Prozessor fest gebunden (obsess, perfdata, …). Nagios unterstützt weder SMP noch an wichtigen Stellen Threads.
• Ändert sich die Konfiguration in Nagios so wird kein automatisch Check geforced. Das ist besonders interessant, wenn etwa die Schwellwerte geändert wurden. Nur das Plugin alleine entscheidet über OK,WARNING,CRITICAL und daher müsste Nagios eigentlich sofort einen neuen Check auslösen. Nagios hat keine Rückkopplung zu den Plugins.
• Passive Events behalten nur den letzten Status. Es fehlt überhaupt ein vernünftiges Handling von asynchronen Events. Passive Checks halten immer nur den letzten Status.
• Zuviele Macros? Die Macros wechseln zwischen den Versionen die Namen, machen nicht immer was sie versprechen und bieten auch nicht alle Möglichkeiten, die man so braucht. Warum nicht einfach eine vernünftige Schnittstelle zur status.dat?
• Warum unterscheidet sich status.dat und retention.dat. Warum bleibt der Status beim Beenden nicht einfach stehen …
• Jetzt liefern die Plugins doch tatsächlich mittlerweile großteils formatierte Performancewerte. Nagios stellt sie auch dar, aber dennoch gibt es keine vernünftige Schnittstelle um diese abzugreifen. Tools wie PNP, NagiosGrapher, … müssen Klimmzüge machen um sie zu ermitteln und anschließend auch selbst parsen.

Schwächen im Webinterface

• Die Statusmap ist in ihrer jetzigen Umsetzung eigentlich zu 95% nicht verwendbar. Meist sieht man nur schwarze Flecken.
• Unübersichtlich. Sucht mal den Kommentar zu einer Downtime 🙂 …
• Nicht „Mehr-„Instanzenfähig. Das Webinterface beherrscht immer nur ein Nagios. Bei verteilten Konfigurationen ist es nicht möglich über ein Webinterface External Commands auf daran angebundenen Nagios Servern diese auszuführen.
• Kein vernünftiges Reporting! Beim Reporting fehlen wichtige Features. So fließen z.B. die Timeperiods in das Reporting nicht ein. Oder etwa doch?

• NSCA übermittelt keinen Timestamp. Nagios übermittelt die Ergebnisse ohne jegliche Information wann sie ermittelt wurden
• NSCA/Obsess Bottleneck. Durch Obesses over Services/Hosts wird nach jedem Check eine Shell gespawnt und das entsprechende Command ausgeführt. Das Problem ist, dass solch ein Kommand nicht parallel aufgerufen wird. Ist es zu langsam so stauen sich diese Commands und die Latenz in Nagios wächst

Schwächen bei Plugins

• Plugins und deren Output sind nur wage definiert. Es gibt leider keine einfache Möglichkeit ein Plugin automatisch zu erkennen und so etwa die Definition für Graphen automatisch zu zuordnen. Solch eine Verknüpfung geht zur Zeit nur über Umwege (NagiosGrapher? verwendet hier die ServiceDescription). Bei den Plugins fehlt zur Zeit eine ID (MD5-Checksum?), Versionsnummer und Beschreibung der Ausgaben.

Schwächen in Addons

• NRPE
  • Authentifizierung/Autorisierung. Rein über die Source IP. Wenig sicher, oder?
  • Parameterübergabe. Es gibt nur 2 Möglichkeiten. Entweder sind sämtliche Parameter der Plugins auf dem Client konfiguriert oder aber NRPE prüft die Parameterübergabe nicht. Weder die eine noch die andere Methode ist wirklich sinnvoll einsetzbar.
• NDO
  • Blocking! Hat die Anbindung an die Datenbank ein Problem steht Nagios.
  • Einbahnstraße. NDO ist nur Output. Es bringt nichts die Daten in der Datenbank zur Laufzeit zu ändern
  • Völlig unübersichtliches Datenmodell.
  • Wenn NDO in Zukunft das Mittel für distributed Monitoring sein soll, wie sollen dann External Commands ausgetauscht werden. Da fehlt noch ein Konzept.
  • NDO liefert Daten ohne Ende. Mit dem Datenwust ist nicht vernünftig möglich Auswertungen zu fahren. Es fehlt eine Schicht, die Werte extrahiert (Performancewerte) und agregiert (etwa Up- und Down-Zeiten ermittelt).