Nagios-/Icinga-Portal

Hi,
ich wollt mal eine kleine Diskussion eröffnen, da ich bisher nur recht wenig über dieses Problem zu lesen gefunden hab:
Genereller Aufbau ist wie folgt:

• mehrere OMD Installationen auf geographisch getrennten Systemen mit WAN Strecken dazwischen (100-1000Mbit)
  
• Nagios via check_mk konfiguriert
  
• Oberfläche multisite (mit rewrite rules für pnp etc)
• eine Gruppe von Admins die überall alles sehen dürfen und konfigurieren müssen aber nur für manches benachrichtigt werden
• diverse Gruppen von Benutzern die verschiedene Systeme auf verschiedenen Sites sehen dürfen/für diese benachrichtigt werden

Einige selsbt gesetzte Vorraussetzungen:

• "Ease of Use" -> erledigt ->multisite
• "ease of Config": möglichst Konfigs/templates nicht pro site anpassen müssen
• gewisse Versionskontrolle bei konfigdateien/templates

Um das alles hinzubekommen habe ich folgendes veranstaltet:

1. check_mk configs in möglichst generische (soll heissen "Site unabhängige") Stücke zerlegt -> check_parameters.mk, custom_checks_mk,ignore_inventory.mk
2. möglichst viel an host_tags gehängt
   
3. main.mk generisch gestaltet
4. Variablen die Site spezifisch sind (all_hosts, monitoring_host) in Dateien abgelegt die .local. im Namen enthalten
5. unison zwischen den Sites eingerichtet (rsync hätte wascheinlich auch geklappt)
6. pfade $OMD_HOME/etc/(check_mk|pnp4nagios|htpasswd) synchronisiert,dabei alles ignoriert was ".local." im Namen enthält

So muss man bei einer konfigänderung nur noch unison aufrufen, und alle Konfigs/templates/logins sind abgeglichen, und veränderungen führen automatisch zu Versionierten Backups von unison(wenn korrekt konfiguriert)

Allerdings hat dieser Ansatz noch ein paar Macken:

1. Contacts/contacgroups: check_mk erzeugt nur contactgruppen, wenn diese auch im Host verwendet werden, -> man müsste contactgroups und contacts in "extra_nagios_conf" konfigurieren, was ich unbequem finde
2. all_hosts: unbequemerweise muss man die lokal konfigurieren, da ich noch nicht ruasgefunden hab, wie man cmk -I per default dazu bringt nur Hosts mit einem bestimmten tag zu inventarisieren
3. remote reload: bisher bin ich zu doof (oder istes ein bug?) "cmk -O" remote auszuführen("ssh cmk -O " funktioniert so nicht)
4. templates.special: Benutz ich eigentlich recht gerne und häufig(Anzahl aller Request auf allen Loadbalancer-Backends etc), klappt aber nur wenn entweder man vorher eine pnp Anzeige auf der entsprechenden Site aufruft oder die rrd's auf allen Sites liegen, prinzipiell wäre es ja möglich die rrds auch zu syncen, aber das kann je nach Site-größe schon zu recht viel Traffic führen, da weder unison noch rsync inkrementelle updates vonn rrds machen kann. Hab schon an drbd gedacht, aber das ist mir zu gefährlich, da die WAN Strecken ja auch mal ausfallen können...

btw. das Problem mit den Contacts(groups) hab ich durch eine kleine Anpassung im check_mk.py hinbekommen, über ein dictionary namens all_contacts lassen sich jetzt Contacts und die dazugehörigen Gruppen erzeugen, auch wenn diese nicht an einen Host gebunden sind/verwendet werden, damit kann sich jetzt jeder contact, der sich authentifizieren kann (htpasswd muss man schon noch selbst anpassen) auf jeder Site anmelden und sieht seine Hosts egal wo sie liegen. (angehängtes File, Use at your own Risk)


Mich würde interessieren wie ihr sowas gelöst habt,bzw was ihr für Verbesserungsvorschläge hättet.

Da vielen dank für die schnellen Antworten.
Auf die Idee mit dem --list-host bin ich garnicht gekommen... Manchmal sieht man den Wald vor Bäumen nicht.
Warum das mit dem ssh cmk nicht klappt forsch ich nochmal nach
und die nagios contacts geschichte.... nuja mir ist die nagios.cfg zu anstrengend aber das Hauptproblem sind ein paar der Kollegen, die sich schon schwer genug mit der check_mk konfig tun...denen kann ich nich noch ne nagios cfg zumuten und ausserdem bin ich faul und mag meinen Ansatz. Vielleicht gefällt er ja auch anderen,da er doch die Usererzeugung erheblich vereinfacht:

Das mit dem rrd habichmir gedacht, das es Ärger gibt(deswegen auch noch ganrnicht versucht).
Aber was für andere Möglichkeiten meintest du(die bei denen Man aufpassen muss?) rrdcached als Netzwerkservice

Zitat von »sni«

Früher hatte ich auch ein ähnlich verteilten Ansatz. Aber das bringt etliche Probleme mit sich.
Neben dem Synchronisieren müsstest du ja auch alle verteilten Sites redundant installieren. Neben
dem Aufwand erzeugt das auch Hardwarekosten (sofern man nicht virtualisiert, dann müsste man aber den
Host redundant auslegen, was aber oft schon der Fall ist)

Nun das mit der Redundanz überleg ich mir noch, der Grund fürs verteile Monitoring ist nicht Lastverteilung oder Ausfallsicherheit, sonder Zwang

Zitat von »sni«

Mit unison hab ich auch eher gemischte Erfahrungen gemacht. Konflikte waren an der Tagesordnung.

Bisher hab ich da noch keine Probleme, gibt aber auch nicht soviele Leute die daran rumschrauben, Wichtig war mir eigentlich eher das Die konfigs wirlich überall synchon sind, aber warten wirs ma ab.

Zitat von »sni«

Letztlich bin ich jetzt wieder bei einem zentralen Ansatz mit einer Site. Monitoring sollte meiner Meinung nach
nicht sonderlich kompliziert und super ausgefallen sein. Je einfacher es ist, desto weniger geht kaputt
oder fällt aus.

Da stimm ich dir zu, nur wie oben schon gesgat, ich muss!, da einige Netze/Server nur von bestimmten IP's aus Monitorbar sind,bzw in privaten Netzen liegen, und die FW Regeln zu den zugehörigen VPNs nicht immer unserer Kontroller unterliegen, weiterhin mag ich auch nich die restlichen (noch einzubauenden) 500 Server via WAN Strecke monitoren, wenn ich das auch aus einem Low-Latency Gbit Netz machen kann

Zitat von »sni«

Dann kommt es natürlich auch auf Zuständigkeiten an. Eine Site, an der 10 Leute in verschiedenen
Verzeichnissen basteln geht meist schief. Noch besser, gerade bei größeren Umgebungen wäre eigentlich,
wenn die Monitoring Daten aus einer CMDB oder irgendeiner Art Inventardatenbank kommt und dann
automatisch generiert wird. So kann man sicherstellen dass nichts vergessen wird und es sorgt auch
dafür dass alles möglichst identisch überwacht wird.

Bezüglich Versionskontrolle bietet sich git an. Ein "git init" ist immer das erste nach dem Site anlegen.

Das mit dem Git is ne gute Idee, muss hier sowieso noch Redmine und eine Versionskontrollsystem installieren für einige Projekte, da würde das wohl passen.
Das mit den 10 Usern habich nicht, es geht um 5Admins, die meist recht froh sind wenn ich mich um die Konfig kümmer, nur im Falle das ich ma ncih da bin oder Bereitschaftsdiesnt muss was ändern oder so halt,
Das mit der CMDB ist ein wunder Punkt..... aber prinzipiell hastu Recht und das ist auch quasi das endziel.

Hmm, das klingt gut,
aber kommt eher hinten in die ToD0 List,
das mit dem german mussich mir auchnochma anschauen, wäre ja prinzipiell der richtige ansatz für die Monitorings in rpivaten subnetzen,
(wahrscheinlich sinniger als jedes ma ne OMD site darauf aufzumachen...)
Und danke für den tip mit cmk