[Eisfair] nagios-objects?

kay kay at martinen.de
So Dez 18 14:54:05 CET 2016


Am 18.12.2016 um 09:37 schrob Ansgar Püster:
> 
> Am 18.12.2016 um 08:46 schrieb Helmut Backhaus:
>>
>> Am 16.12.2016 um 16:39 schrieb Ansgar Püster:
>>>
>>> Und ja: nagios-objects bietet über den ECE die Möglichkeit
>>> nahezu alle Objekte für Nagios zu definieren also auch
>>> hosts und services.
>>
>> Aber auch das erfordert doch Grundwissen über Nagios, oder?
> 
> Ja, Grundwissen ist erforderlich, daher auch mein entsprechender
> Hinweis einige Zeilen tiefer. Aber nagios-objects bietet die
> von Eisfair gewohnte Konfigurationsschicht, macht Prüfungen
> und erzeugt dann die Konfigurationen Dateien.

Schönes Ding. Mein Problem bei nagios war halt
1. das ich dies paket nicht fand
2. das ich keinen hinweis darauf fand WO und WAS ich bei "manual"
eintragen kann/sollte. Ich hab die doku überflogen und im /etc gesucht
und hatte dort eine hosts oder services datei mit inaktivierten
einträgen erwartet. Quasi eine art vorlage die man im texteditor dann
kopieren und modifizieren kann.

Aber ich fand nichts und das war frustrierend genug, zumal sonst bei
Eisfair zumindest die grundlegendsten Konfig-Dinge im Setup erledigt
werden können. Darum benutze ich ihn ja. Das daß bei nagios nun anders
rum ist habe ich so auch nicht erwartet.

Beim Nagios-objects würde ich erwarten das ich hosts und ihre ip
konfiguriere und diesen dann services zuordnen kann die man z.b. aus
einer erweiterbaren dropdown-liste auswählt. Ähnlich wie es ja auch bei
smokeping mit den probes geht.

Ich werde das demnächst noch mal aus probieren und schauen ob es klappt.


>> Gibt es den ein Tool(s) die dafür besser geeignet sind?

Gute Frage. Besser ist die: was will man erreichen?

>> Alles was ich finde (bei der Tante G...) sind mehr oder weniger Forks
>> von Nagios die ähnlich kompliziert sind (kommt natürlich auf die Sicht
>> des Betrachters an).

ja, eben. Ich hätte gern check_Mk ausprobiert (gibt es nicht für EIS)
auf einem Debian, aber mit charts, also wohl mit pnp4nagios o.ä. aber
das hängt NOCH komplizierter zusammen. Und icinga ist auch nur ein fork
von nagios.

> Ich würde ein Tool immer erst dann auswählen, wenn mir
> halbwegs klar geworden ist, was ich eigentlich konzeptionell
> und inhaltlich will.

Ich habe schon vor etlichen Jahren mrtg standalone für mehrere Hosts
komplett zu Fuß ein gerichtet. Naja, mit cfgmaker und idxmaker-hilfe.
Ich habe auch "The dude" in Version 2.2 und 3.x benutzt aber das ist
windows-only und kann zwar viel, aber auch nicht alles.

Und ich habe auch cacti eingerichtet und benutzt, ebenso wie smokeping
auch auf dem EIS. Wobei ich immer noch erinnere das cacti auf dem Eis-2
damals wirklich einfachst zu installieren ging und sauflott arbeitete.
Später, nachdem es Eis-2 nicht mehr gab und auf der gleichen HW mit
Eis-1 war es lange nicht so einfach und lief merklich schwerfälliger.
Warum auch immer das so war...

Alle diese Tools haben ihre stärken und ihre Schwächen. Eines das alles
gute vereint habe ich noch nicht gesehen.

> Was bedeutet "mal eben" ein paar Hosts damit überwachen?
> Sind Mini-Konzept ("mal eben erzeugt") tragfähig für größere
> Lösungen?

Bei mir z.b.

2-4 switche mit management. d.h. Interface-statistics plotten (auch
fehlercounter) und erwünscht wäre eine nachricht wenn es mehr errors
gibt. Ersteres wäre zu fuß mit MRTG machbar, das zweite m.W. nicht.

Dann ca 2-4 Server (mind. 2 Proliants) deren "gesundheit" auch per snmp
überwacht werden sollte (wenn möglich) da die health-monitoring tools
vom hersteller nicht wirklich gut funktionieren (oder nur lokal ohne
alarm) oder außer lm-sensors kein(e oder ein BMC) vorhanden ist.
D.h. erweiterbare, konfigurierbare snmp-einrichtung was nagios/icinga
oder check_mk wieder in die mitte rückt.

Und zuletzt nur eine grobe Überwachung von Win oder Linx-Clients wenn
sie an sind. (!)

Vor allem dies letzteres geht m.W. nicht so einfach weil die meisten
(nagios, o.a.) einen sonst mit "Host down" mails tot werfen.
Möglicherweise wäre das mit einem Agent (nrpe o.a.) pro client besser
lösbar, dazu müsste aber die zentrale instanz erst mal laufen.

Derzeit habe ich darum immer noch "The Dude" in einer Win2k VM am
laufen, der kann autodiscover, plottet die service-verfügbarkeit und
bietet immerhin einen generellen überblick über alles.

-- 
Posted via SN


Mehr Informationen über die Mailingliste Eisfair