Eine der Fragen, die mir am häufigsten bei Kunden begegnet ist die Frage nach der Empfehlung, ob agentenloses oder agentenbasiertes Monitoring. Meist erkennt man schon an der Frage was eigentlich bevorzugt wird und im Unterton klingt auch mit, dass dies bitte auch die Empfehlung sein soll. Um nun alle die auch vor dieser Frage stehen zu beruhigen, meine Antwort ist immer zu nehmen was am besten in die Umgebung passt und womit alles überwacht werden kann was benötigt wird. Trotzdem hat natürlich alles Vor- und Nachteile, die ich versuchen möchte aufzuzeigen.
Zu aller erst möchte ich aber mit dem “Vorurteil” aufräumen es gäbe sowas wie agentenlose Checks. Die meisten verwenden diesen Begriff für die Abfrage von SNMP oder auch WMI. In meinen Augen handelt es sich hierbei aber auch um Agenten, die allerdings zum Glück meist vorkonfiguriert sind, denn leicht zu erweitern sind diese Agenten nicht.
Hiermit haben wir auch schon einen ersten Vor- und Nachteil von SNMP. Der Vorteil eines einheitlichen Agenten auf allen Systemen sei es nun irgendwelche Hardware, Linux oder Windows, der zudem entweder standardmäßig verfügbar ist oder zumindest leicht verfügbar gemacht werden kann, liegt auf der Hand. Der Vorteil resultiert auch gleich im nächsten, denn prinzipiell reicht bei solch einer Umgebung ein Check um alles zu überwachen. Allerdings sind wir hier schon beim ersten Nachteil, den Daten die per SNMP geliefert werden und ihrer Struktur. Oftmals sind diese eher zu einem geringen Teil fürs Monitoring interessant und teilweise gehen interessanten Werte in der Maße unter. Zwar sollte dies aufgrund der MIBs nicht passieren, aber an diese ist oftmals schwer heranzukommen und wenn nicht schwer dann zumindest immer mit etwas Zeitaufwand. Zusätzlich sind diese von sehr schwankender Qualität. Trotzdem lässt sich hat man die relevanten Werte gefunden mit den immer gleichen Konstrukten auch für alles ein spezialisierter SNMP-Check entwickelt, was wieder ein Pluspunkt ist. Die Möglichkeit hierfür alle Programmiersprachen verwenden zu können, sei es nun beispielsweise Bash, Perl, C oder auch mehrere Checks mit Check_multi zu verketten, und auf bestehende Checks zurückgreifen zu können, sind allgemeine Vorteile von Nagios/Icinga und der Community und kein Pluspunkt speziell für SNMP. Über Security will ich hingegen bei SNMP nicht reden, für viele steht SNMP auch für “Security Not My Problem”, weshalb ein Monitoring auf Basis von SNMP oftmals direkt an der IT-Sicherheit scheitert. Zusätzlich hat SNMP auch noch den Weg der aktiven Alamierung, was noch ein Vorteil ist, allerdings sind hier die MIBs meist noch schlechter und den zusätzliche Aufwand für diesen zweiten Meldeweg möchte ich als Nachteil verbuchen, selbst wenn EventDB hierfür eine schöne Lösung darstellt.
Ähnliches wie für SNMP gilt auch für WMI, allerdings ist die Lösung nur für Windows verfügbar, die Abfragen (aus Sicht eines Linux-Users) sind komplizierter, die Werte noch seltsamer und die Software zum Abfragen ist auch schwerer zu bekommen/zu kompilieren. Wer seine Windowssysteme aber hiermit überwachen möchte findet die Anleitung nicht weit entfernt.
Die Abfrage per SSH ist dagegen eher nur für Linux zu empfehlen, auch wenn es doch so einige SSH-Server für Windows gibt. Auch hier steht der Pluspunkt beim geringen Konfigurationsaufwand. Der Check nutzt eine normalerweise durch die IT-Sicherheit erlaubte Verbindung, benötigt nur einen SSH-Key der auf das System gebracht werden muss und den Zugriff absichert und alle Plugins ausführbar für den Benutzer. Die Plugins sind hierbei bis ins Unendliche erweiterbar (gerne auch durch uns) was ein weiterer klarer Pluspunkt ist. Allerdings wird dann SSH zu mehreren Zwecken genutzt, Logins erfolgen in hoher Frequenz und die Plugins werden im normalen Benutzerkontext ausgeführt, weshalb ich zumindest nicht der größte Freund dieser Lösung bin.
Die Abfrage des NSClient++ per Check_nt möchte ich einfach mal außer acht lassen, da dieser keine Vorteile gegenüber Check_nrpe hat. Er hat sogar den Nachteil nur als Windowsschnittstelle zu dienen wogegen NRPE-Kommunikation sowohl mit NRPE als auch NSClient++ möglich ist. NRPE hat den Vorteil gegenüber SNMP genauso wie SSH beliebig erweiterbar zu sein. Gegenüber SSH ist der Konfigurationsaufwand allerdings höher, da eine neue Kommunikationsverbindung etabliert werden muss und eine zusätzliche Komponente konfiguriert werden muss, die sich dann auch noch auf Linux/Unix und Windows unterscheidet. Der Vorteil den ich dafür erhalte ist ein eigener Dienst mit eigener Netzwerkkommunikation und in dessen Kontext die Plugins ausgeführt werden. Sicherer wird dies allerdings erst wenn man diesen entsprechend absichert, beispielsweise durch einen eigenen SELinux-Kontext.
Wer möchte kann auch NRPE unter Xinetd laufen lassen, was aber noch eine zusätzliche Komponente ist, nur um NRPE nicht durchgängig laufen zu haben. Aber für den ein oder anderen mag die Möglichkeit ein Vorteil sein. Für SSH und NRPE/NSClient++ gibt es mit NSCA auch eine aktive Komponente fürs Monitoring, welche aber auch zusätzlichen Aufwand bedeutet. Ein weiterer Nachteil bei all den letztgenannten Komponenten ist in Zusammenhang mit Plugins mit extrem großem Output, dass hierbei eine zusätzliche Stelle mit Zeichenbegrenzung existiert.
Um ein Fazit zu ziehen stelle ich mir die Frage wie sieht für mich die ideale Lösung nun aus? Ich installiere auf den Systemen über Softwaremanagement Clients und Plugins, über Konfigurationsmanagement konfiguriere ich diese entsprechend und sichere diese mit allen Sicherheitsfeatures ab. Für Hardware nutze ich natürlich weiterhin SNMP und schreibe mir meine speziellen Checks oder verknüpfe zumindest generische SNMP-Checks zu einem Check mittels Check_multi. Aber dies ist meine Idealvorstellung, die die maximale Erweiterbarkeit bietet und den Nachteil der Verteilung von Software und Konfiguration durch Automatisierung und Standardisierung auf ein Minimum verringert. Passt dies nicht in die Umgebung ist allerdings jede Lösung praktikabel solang damit das Ziel erreicht werden kann, insbesondere da keine Lösung eine andere ausschließt. Denn selbst unterschiedliche Lösungen für unterschiedliche Anforderungen zu verwenden bedeutet nur mehr Komponenten und mehr Aufwand.
0 Comments