Welches Monitoringsystem verwendet Ihr?

[heisenberg]

Hallo zusammen,

mal eine eher breit gestreute Frage an alle, die ein Monitoringsystem verwenden: Welches Monitoringsystem verwendet Ihr? Warum verwendet Ihr es? Was findet Ihr gut bei Eurem Monitoringsystem? Was findet Ihr schlecht? Was wünscht Ihr Euch gerne anders?

Ich fange mal an....

Nachdem ich eine Weile mit Big Sister - damit konnte man schon irgendwie arbeiten - gearbeitet habe und anschliessend mit einem puren Nagios zu tun hatte, wobei mich letzteres sehr abgeschreckt hatte, bin auf Empfehlung zu Check_MK(Mit Nagios-Monitoring-Engine) umgestiegen. Und bis jetzt muss ich immer noch sagen: Saugeile Software.

Was mir gut gefällt

• Mit OMD oder der Check_MK Raw-Edition ist es super schnell aufgesetzt und läuft sofort.
• Was im Standardumfang bereits direkt integriert ist, ist beachtlich
• Das Webinterface ist super. Sowohl für Nutzung als auch für Konfiguration(WATO).
• Man kann sich sehr tief in die Software einarbeiten. Aber man muss es nicht. Auch mit nicht so tiefen Linux-Kenntnissen kann man das System gut verwalten.
• Es ist sehr vielseitig. Wenn man etwas braucht entdeckt man immer wieder was neues, was sehr nützlich ist.(Konfigurationsschnittstelle, Statusabfrageschnittstelle, Eventconsole und automatische Aktionen, Weathermaps, ...).
• Der Code ist gut organisiert. Updates funktionieren echt einfach, auch ohne Debian-Repository-Integration. Es gibt sorgfältig durchdachte Trennungen zwischen Upstream-Code und eigenen Erweiterungen. Wenn man seine eigenen Erweiterungen richtig ablegt, wird das Update und auch ggf. das Rollback zum Kinderspiel.
• Hierarchisches Regelmodell(Nicht drüber nachdenken. Einfach nutzen. D. h. Vorgabe für alle. gruppen- bzw. ordnerspezifische Regeln und Ausnahmen für Einzelne Systeme.)
• Stetige Weiterentwicklung von brauchbaren Features
• Eigene Checks sind schnell geschrieben.
• Sehr gute, deutsche Dokumentation
• Monitoring-Clients für viele Betriebssysteme(Linux,Windows,*BSD,...)
• Open Source

Was mir nicht so gut gefällt

• Es gibt für mich keinen groben Schnitzer, der wirklich nervt
• Es wäre schön für verschiedene Benutzer verschiedene Startseiten definieren zu können.
• Die Konfiguration hätte ich lieber in einer DB, statt in Python-Dateien, so dass ich darauf besser mit Programmen zugreifen kann

[Lookbehind]

Hallo,

ich falle hier zwar wahrscheinlich nicht zu 100% rein, weil das Monitoring für mich eher nur ein Gimik ist, und keine Notwendigkeit. Dennoch wollte ich kurz erzählen was mir an dem Raben gefällt, und eben auch was nicht.

Ich benutze Munin auf meinem kleinen Home-Server weil ich gerne die Speicherplatz-Entwicklung eines Netzwerk-Shares im Auge behalten wollte und es sehr schnell lästig wurde, jedes mal mit df über die Konsole nachschauen zu müssen. Bei Recherchen was man da besser machen könnte bin ich dann über RRD sehr schnell auf Munin gestoßen, habs ausprobiert und bin gleich hängen geblieben.

Was mir gefällt:

• Super simple Installation, da direkt in den Debian Repos verfügbar
• Einfaches erweitern mittels Plugin-System
• Plugins lassen sich sehr leicht im Netz finden oder gleich selber schreiben, mehr als n bisschen Scripting-Fähigkeiten braucht es dazu nicht, Beispiele gibt es genug.
• Bietet eine schöne Übersicht über diverse "Messwerte" des Systems, sowohl aktuell als auch die frühere Entwicklung.

Was mir nicht so gefällt:

• Die Konfiguration ist anfangs etwas gewöhnungsbedürftig
• Es wäre schön, wenn man sich eigene Rubriken zusammen stellen könnte, in denen man die Graphen anordnet wie man sie braucht.

Grade bei letzterem bin ich mir nicht ganz sicher, ob ich nicht einfach nur zu blöd dafür bin. Bzw. da der Home-Server immernoch auf Wheezy läuft (jaja, ich weiß, ich hab Jessie schon länger auf der Agenda), könnte es sein, dass neuere Versionen von Munin da auch mehr können.

Wie bereits erwähnt: So wahnsinnig viel Arbeit habe ich in diese Monitoring-Lösung (so man es denn überhaupt als solche bezeichnen möchte) nicht investiert. Es tut was ich möchte, mit wenig Aufwand. Ich bin Glücklich damit.

[Colttt]

Hallo,

wie der ein oder andere weiss nutzt ich Zabbix..
hab mich dafür vor knapp 10jahren entschieden, hattte yuerst Nagios versucht aber bin da recht schnell dran gescheitert zudem fand ich es doof das ich für alles nen plugin brauche. Ich wollte auch was haben was andere über die GUI nutzen können.

Da stieß ich auf zabbix.. es wird ca 90% übers webfrontend alles eingestellt (der rest sind eigene scripte oder so), es wird alles in eine DB gespeichert, hat den vorteil das man sich ein super reporting basteln kann. Da bis auf das frontend alles in C geschrieben ist, ist es extrem performant und Ressourcenschonend. Die community wächst und ist immer sehr kompetent und hilfsbereit. Man kann webseiten und scenarios erstellen und monitoren und alles was als zahl bei zabbix ankommt kann man sich automatisch als Graph anzeigen lassen.. und und und....

negativ ist daran das alels in einer DB gespeichert wird und damit natürlich auch die performance von zabbix steht und fällt, nested hostgroups gibts seit der neusten version.. was ich noch gut finden würde wäre nested LLD, aber das geht jetyt hier zu weit

wer dazu fragen hat, immer her damit

[whisper]

Auf meinem Server benutze ich Collectd, das ist zum einen wirklich easy zu installieren und zu konfigurieren und zum anderen mit der Web GUI CGP [1] ein unglaublich nettes Gespann.
Der Vorteil gegenüber munin und auch Cacti, ist, dass man Canvas Grafiken benutzt und die Grafiken erst on demand erstellt werden, ich kann beliebig in der Zeit zurückschauen und in Details rein zoomen.
Damit kann man gerade auf einem exponierten Server Langzeitbetrachtungen machen und sich im Falle eines Falles sehr Zeitgenau ansehen, ab wann ein Missstand auftrat.
[1]https://github.com/pommi/CGP
Im beruflichen Umfeld haben wir ebenfalls Check_MK auf Nagios Basis.
Ist einfach toll, wenn man einen Kollegen hat, der es betreut und fortlaufend an die sich ändernde Hardware Landschaft anpasst.
Ein wirklich tolles Tool, nur für Privat etwas zu aufwändig

[heisenberg]

...zudem fand ich es doof das ich für alles nen plugin brauche.

Also grundsätzlich will man sein Monitoring ja schon an sein persönliches Szenario anpassen und erweitern. Die Plugin-Methode ist da für mich ein guter Weg. Natürlich bringt es einen gewissen Aufwand mit sich, Plugins auch auf die überwachten Maschinen zu verteilen. Löst Zabbix das besser? Im übrigen finde ich es praktisch, alle beliebigen Monitoring-Plugins verwenden zu können, also Plugins die als Minimalanforderung nur 3 Statuscodes zurückgeben müssen: 0 - OK, 1 - Warnung, 2 - Kritisch.

...es wird alles in eine DB gespeichert, hat den Vorteil, das man sich ein super Reporting basteln kann.

Du meinst, weil man Zugriff auf alle Zahlen hat, sich so selbst alle Daten einfach per SQL ziehen kann und beliebige Statistikdaten so einfach berechnen kann? Oder gibt's da spezille Berichtsfunktionen, die Zabbix anbietet?

...bis auf das Frontend alles in C geschrieben ist, ist es extrem performant und ressourcenschonend.

Das ist sehr wichtig. Bei Check_MK ist das meiste in Python, was beim Neustart in vorkompillierten Bytecode übersetzt wird. Ist natürlich bei weitem nicht so performant wie pur C. Bei der Pluginentwicklung der eigenen Erweiterungen muss man da auch sorgsam entwickeln, sonst geht die CPU des Monitoring-Servers in die Knie.

... alles was als Zahl bei zabbix ankommt, kann man sich automatisch als Graph anzeigen lassen...

Ja. Das ist Gold wert, wenn man im Fehlerfall die Entwicklung der Leistungsdaten hat und nicht bei Null anfängt und sich kontextfrei d. h. ohne Kenntnis der normalen Arbeitslast mit vmstat oder gkrellm versucht sich ein Bild zu machen.

was ich noch gut finden würde, wäre nested LLD, aber das geht jetzt hier zu weit

LLD = Low Level Discovery. Ja, den Automatismus zur Checkerstellung schätze ich bei Check_MK auch sehr. Mittlerweile kann man das auch automatisiert neu erkennen lassen, was ich ich Moment allerdings noch nicht nutze, da ich erst seid kurzem die Dienste, die ich nicht benötige wegkonfiguriert habe. Wenn man das nicht tut, kommen die ganzen vorhandenen aber nicht aktiven Dienste wieder, was lästig ist.

Was meinst Du bei Zabbix mit verschachtelter Diensteerkennung(nested LLD)? Bei Check_MK wird grundsätzlich alles erkannt. Basierend auf Ordnern, Hostgruppen und Hostnamen kann ich dann noch Dienste per Textmuster deaktivieren, die ich nicht haben möchte. Ist das so etwas?

Bezüglich Diensteerkennung gefällt mir auch der Ansatz, dass der Agent im Shellscript prüft: "Gibt es dieses oder jenes Tool auf dem zu überwachenden Rechner(z. B. smartctl für die SMART-Datenanzeige)?" Wenn nein, dann gibt's halt keine Smart-Daten. Wenn ja: Hole die Smartdaten für alle vorhanden Festplatten. Und am Server wird dann entschieden, was damit gemacht wird(Ich hätte gerne nur Smartdaten für die Festplatten, oder: Ich hätte auch gerne die Temperaturwerte). So läuft das mit ganz vielen Sachen(Sensorendaten, RAID-Controller-Checks,...). D. h. für viele der vorhandenen Checks läuft es so ab: Kommandozeilentool installieren: Neue Checks im Host suchen. Neuer Check ist da

[Colttt]

Also grundsätzlich will man sein Monitoring ja schon an sein persönliches Szenario anpassen und erweitern. Die Plugin-Methode ist da für mich ein guter Weg. Natürlich bringt es einen gewissen Aufwand mit sich, Plugins auch auf die überwachten Maschinen zu verteilen. Löst Zabbix das besser?

Zabbix sammelt in der Regel Daten per Zabbix agent ein, der Agent hat schon extrem viel onboard, damit lässt sich eigentlich schon sehr viel erschlagen. Alles was man dazu noch haben möchte, bastelt man sich entweder ein Modul (bsp für Postgres), da es auch in C geschrieben wird ist es auch sehr performant, wenn man keine Programmierkenntniss in C hat, gibts dafür auch nen Pythonwrapper wo man dann Pythoncode als Modul ausführen kann.. aber Standard ist dann wohl entweder Userparameter, dort wird die ausgabe eines Befehls an zabbix weitergeleitet. Zabbix kann aber auch VMware out-of-the box monitoren, auch telnet/ssh-checks ausführen, IPMI, SNMP, JMX, ODBC etc.. alles schon drin
Da bei Zabbix vieles out-of-the box läuft gibts halt auch viele Templates für sehr vieles, einfach runterladen, einem host verlinken fertig

Im übrigen finde ich es praktisch, alle beliebigen Monitoring-Plugins verwenden zu können, also Plugins die als Minimalanforderung nur 3 Statuscodes zurückgeben müssen: 0 - OK, 1 - Warnung, 2 - Kritisch.

genau hier arbeitet zabbix anders, hier bekomme ich keine Statuscodes zurück sondern direkt Werte (bsp CPU Load 2,4) darauf erstelle ich dann ein Trigger (wenn CPU Load über den Zeitraum von 5minuten/ die letzten 5checks über 5 liegt dann ist das ein Problem, dann sage ich ihm noch welche schwere das Problem hat, da gibts 5Stufen

Du meinst, weil man Zugriff auf alle Zahlen hat, sich so selbst alle Daten einfach per SQL ziehen kann und beliebige Statistikdaten so einfach berechnen kann? Oder gibt's da spezille Berichtsfunktionen, die Zabbix anbietet?

Zabbix selbst hat auch schon Reporting an board: Verfügbarkeit und Topauslöser pro Host in einem bestimmten Zeitraum.. also eher rudimänter.. wenn man was komplexeres haben will muss man halt die API oder SQL bemühen

Das ist sehr wichtig. Bei Check_MK ist das meiste in Python, was beim Neustart in vorkompillierten Bytecode übersetzt wird. Ist natürlich bei weitem nicht so performant wie pur C. Bei der Pluginentwicklung der eigenen Erweiterungen muss man da auch sorgsam entwickeln, sonst geht die CPU des Monitoring-Servers in die Knie.

Jup das kenn ich, ich hab schon Icinga-Umgebungen ausgetauscht da war die Load konstand >2-3, nach der Zabbix migrierung wo auch mehr items abgefragt wurde war die load mehr <1-2

LLD = Low Level Discovery. Ja, den Automatismus zur Checkerstellung schätze ich bei Check_MK auch sehr. Mittlerweile kann man das auch automatisiert neu erkennen lassen, was ich ich Moment allerdings noch nicht nutze, da ich erst seid kurzem die Dienste, die ich nicht benötige wegkonfiguriert habe. Wenn man das nicht tut, kommen die ganzen vorhandenen aber nicht aktiven Dienste wieder, was lästig ist.

nunja, da gibt es bei Zabbix zum glück filter wo ich sagen kann welche rein sollen und welche nicht mittels regexp, kann dann natürlich auch ne längere Liste werden, aber wie oft muss man das anfassen

Was meinst Du bei Zabbix mit verschachtelter Diensteerkennung(nested LLD)? Bei Check_MK wird grundsätzlich alles erkannt. Basierend auf Ordnern, Hostgruppen und Hostnamen kann ich dann noch Dienste per Textmuster deaktivieren, die ich nicht haben möchte. Ist das so etwas?

Nunja, ich finde ein Item(SNMP) per LLD und aufgrund das was ich gefunden habe sollen nochmals andere gefunden werden, ich glaub ich habs hier ganz gut erklärt KLICK .. und das geht leider momentan noch nicht.

Was zabbix noch fehlt ist meiner Meinung nach ein "Check Now" was Nagios+Ableger ja haben, heisst also ich muss nicht warten bis die Zeit abgelaufen ist wo das Item wieder überprüft wird, sondern ich klick auf nen Butten und es wird sofort geprüft, leider aktuell nicht möglich.

[DeletedUserReAsG]

Ich hab’ mir in der letzten Zeit mal netdata angeschaut und finde es recht praktisch. Ist allerdings eher dazu gedacht, den Betriebszustand kurzfristig zu beobachten und auszuwerten, als langfristige Statistiken anzulegen. Dafür ist’s leicht zu handhaben, ressourcenschonend und macht schmucke, interaktive Diagramme.

[Colttt]

Nachtrag:

was mir auch noch fehlt ist das man bei zabbix aktuell noch nicht ehm, also wenn ein von einem Item/Sensor den ich abfrage ein bestimmter Wert erreicht ist er erst dann den anderen Wert abfragen soll, Bsp Updates, sobald Updates verfügbar sind, soll er auch abfragen was es für updates sind

[trg2889]

Kann man das nicht einfach über die Actions lösen? Nur so als Gedankengang

[Colttt]

Kann man das nicht einfach über die Actions lösen? Nur so als Gedankengang

nette idee, aber geht nciht, zumindest nicht das ich es so spontan wüsste.
Was man evtl machen könnte ist ne Action erstellen die nen Script aufruft um das dann an Zabbix zu senden, aber ob das sinn und zweck davon ist, wäre ja dann von hinten durch die Brust ins Auge

[heisenberg]

Ich schmeiss auch noch mal Bloonix in den Raum. Was es taugt, weiss ich nicht. Aber sieht hübsch aus.

[heisenberg]

Das mit dem Schweregrad einer Störung würde ich mir auch wünschen. Warning und Critical ist etwas wenig.

[heisenberg]

Eine Sache, die mir bei Check_MK auch gut gefällt, ist die Flexibilität, was die Datenübertragung zum Server betrifft. Üblicherweise lauscht der Agent auf einem Port und wird abgefragt. Ist der Ziel-Host z. B. hinter NAT, ist das nicht ganz so einfach(Remote-Port-Forwarding würde z. B. gehen). Hier kann man z. B. die Ausgabe des Agents auch einfach regelmäßig per scp/ftp/rsync auf den Monitoring-Server hochladen.

[Colttt]

Nunja einfach finde ich das jetzt nicht grade..
Bei zabbix kann ich zwischen passiven (Server fragt Agent) und aktivem (Agent schickt Daten zum Server) Agent in der GUI aussuchen und das Pro Host..
Wenn es eine größere Umgebung/Standorte ist kann man Proxys zwischen schalten, diese sammeln die Daten von den Agent und schicken diese dann zum Server. Was auch gleich den Server selbst entlastet.

[heisenberg]

Da hier mit Colttt und mir zwei Vertreter von Zabbix und Check_MK sind, die es intensiv nutzen habe ich nochmal den einen oder anderen Artikel dazu ausgegraben und werde das nochmal in Ruhe durchlesen.

Was mir bei Zabbix gefällt würde ich mal als Worker-Architektur bezeichnen. Sprich: Es wird nicht einfach ein neuer Prozess erzeugt, der dann einen beliebigen Check ausführt, sondern es gibt eine festlegbare Anzahl an Prozessen für die jeweilige Arten eines Checks, die dann gestartet werden, laufen und wiederkehrend Ihre Art von Check ausführen(z. B. ping oder http). Auf die Art und fällt die ständige Prozesserzeugung einfach komplett weg. Auch abgesehen vom performanten Unterbau in C muss das sehr effizient sein.

So hier noch ein paar Links zum Lesen für Interessierte:

• Pro-Linux: Systemüberwachung mit Zabbix(2008)
• ADMIN-Magazin: Monitoring mit Zabbix(2012)
• IT-Administrator: IT Infrasktrukturen mit Zabbix überwachen(6/2013)
• Best Monitoring Solution 2015 - OMD (Open Monitoring Distribution)(11/2013)
• Google Trends: Nagios, Zabbix, Icinga, Check_MK
• OpenHUB: Projektvitalität: Check_MK, Zabbix, Nagios