10.09.2011, 17:04 UTC+2

Sie sind nicht angemeldet.

Gedanken zum synchronisieren von OMD-Multisite Sites

smue

Anfänger

Beiträge: 10

Geburtstag: 28.02.

Wohnort: Berlin

Anzahl Nagios-Server: 3

Nagios-Version(en): 3.2.3

Verteiltes Monitoring: Ja

Redundantes Monitoring: Nein

Anzahl-Hosts: ~500

Anzahl Services: ~6k

Betriebssystem(e): Ubuntu 11.04

Plugin-Version(en): x

NDO-Version: 3

1

16.08.2011, 14:33

Gedanken zum synchronisieren von OMD-Multisite Sites

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.
»smue« hat folgende Datei angehängt:
  • check_mk_contacts.patch.txt (4,07 kB - 3 mal heruntergeladen - zuletzt: 31.08.2011, 08:47)
Der Horizont vieler Menschen ist ein Kreis mit dem Radius Null
- und das nennen sie ihren Standpunkt.
Albert Einstein

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »smue« (16.08.2011, 14:39)


pitchfork

Super Moderator

Beiträge: 15 096

Wohnort: Kassel

Beruf: Sysadmin SAP / Linux / AIX

Anzahl Nagios-Server: 2

Hobbys: Motorrad fahren, wenns die Zeit erlaubt :-)

Nagios-Version(en): 3.2.1

Icinga-Version(en): ---

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 310

Anzahl Services: 4500

Betriebssystem(e): Debian 5.0 Lenny

Plugin-Version(en): 1.4.x

NagVis-Version: 1.4.1

NDO-Version: ---

IDO-Version: ---

Perfparse-Version: ---

Sonstige Addon's: SNMPTT, NagTrap, NagVis 1.4.5, check_mk, PNP-0.6.x. Thruk

2

16.08.2011, 14:50

Zitat von »smue«

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


kannst du auch als nagios config einschleusen. Du mussts ja nicht alles via check_mk machen


Zitat von »smue«

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



local ist hier ein Tag für localhost

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
OMD[noc]:~$ check_mk -I $(check_mk --list-tag local)
cpu.loads             1 new checks
cpu.threads           1 new checks
df                    2 new checks
diskstat              2 new checks
kernel                3 new checks
kernel.util           1 new checks
mem.used              1 new checks
mem.vmalloc           1 new checks
mounts                2 new checks
netctr.combined       3 new checks
postfix_mailq         1 new checks
tcp_conn_stats        1 new checks
uptime                1 new checks


Zitat von »smue«

remote reload: bisher bin ich zu doof (oder istes ein bug?) "cmk -O" remote auszuführen("ssh cmk -O " funktioniert so nicht)

Quellcode

1
2
3
4
5
6
ssh  '/omd/sites/noc/bin/check_mk -O'
's password: 
Generating Nagios configuration...OK
Validating Nagios configuration...OK
Precompiling host checks...OK
Reloading Nagios...OK
PNP Developer.
PNP 0.6.14 ist online !
Fragen zu PNP mit Angabe der verwendeten PNP Version werden bevorzugt beantwortet.
OMD - Open Monitoring Distribution

pitchfork

Super Moderator

Beiträge: 15 096

Wohnort: Kassel

Beruf: Sysadmin SAP / Linux / AIX

Anzahl Nagios-Server: 2

Hobbys: Motorrad fahren, wenns die Zeit erlaubt :-)

Nagios-Version(en): 3.2.1

Icinga-Version(en): ---

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 310

Anzahl Services: 4500

Betriebssystem(e): Debian 5.0 Lenny

Plugin-Version(en): 1.4.x

NagVis-Version: 1.4.1

NDO-Version: ---

IDO-Version: ---

Perfparse-Version: ---

Sonstige Addon's: SNMPTT, NagTrap, NagVis 1.4.5, check_mk, PNP-0.6.x. Thruk

3

16.08.2011, 14:57

Zitat von »smue«

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...


Vorsicht!

OMD verwendet den rrdcached! es ist somit nicht möglich die RRDs zu kopieren, da noch nicht alle Daten geschrieben wurden.
Weiterhin ist dein Vorhaben nicht ratsam. Man will keine RRD Datenbanken auf drbd Devices und schon garnicht über Wan Leitungen.

Es gibt aber andere Möglichkeiten. Die muss man aber sehr genau analysieren.

Jörg
PNP Developer.
PNP 0.6.14 ist online !
Fragen zu PNP mit Angabe der verwendeten PNP Version werden bevorzugt beantwortet.
OMD - Open Monitoring Distribution

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »pitchfork« (16.08.2011, 15:02)


sni

Profi

Beiträge: 754

Geschlecht: Männlich

Wohnort: München

Anzahl Nagios-Server: viele

Nagios-Version(en): 2.* / 3

Verteiltes Monitoring: Ja

Redundantes Monitoring: Ja

Anzahl-Hosts: viele

Anzahl Services: viele

Betriebssystem(e): viele

Plugin-Version(en): 1.4.11

Sonstige Addon's: Thruk, ModGearman

4

16.08.2011, 14:58

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).

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

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.

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.

smue

Anfänger

Beiträge: 10

Geburtstag: 28.02.

Wohnort: Berlin

Anzahl Nagios-Server: 3

Nagios-Version(en): 3.2.3

Verteiltes Monitoring: Ja

Redundantes Monitoring: Nein

Anzahl-Hosts: ~500

Anzahl Services: ~6k

Betriebssystem(e): Ubuntu 11.04

Plugin-Version(en): x

NDO-Version: 3

5

16.08.2011, 15:26

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:

Quellcode

1
2
3
4
5
6
7
8
all_contacts= {
    'test1' : {                                     #contact_name            
    'email' : ',      #optional, wird wenn nicht vorhanden auf contact_name gesetzt
    'groups': 'comma,separated',   # optional wird wenn nciht vorhanden auf username gesetzt, nicht vorhanden contactgroups werden automatisch erzeugt
    'template': 'template_name'   # optional wird auch generic-contact gesetzt (TODO)
  '....'                                    #jedwede normale nagios contact object definition sollte übernommenw erden können (TODO)},
'contact2':{},
}

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.
Der Horizont vieler Menschen ist ein Kreis mit dem Radius Null
- und das nennen sie ihren Standpunkt.
Albert Einstein

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »smue« (16.08.2011, 15:35)


pitchfork

Super Moderator

Beiträge: 15 096

Wohnort: Kassel

Beruf: Sysadmin SAP / Linux / AIX

Anzahl Nagios-Server: 2

Hobbys: Motorrad fahren, wenns die Zeit erlaubt :-)

Nagios-Version(en): 3.2.1

Icinga-Version(en): ---

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 310

Anzahl Services: 4500

Betriebssystem(e): Debian 5.0 Lenny

Plugin-Version(en): 1.4.x

NagVis-Version: 1.4.1

NDO-Version: ---

IDO-Version: ---

Perfparse-Version: ---

Sonstige Addon's: SNMPTT, NagTrap, NagVis 1.4.5, check_mk, PNP-0.6.x. Thruk

6

16.08.2011, 15:59

Zitat von »smue«

Warum das mit dem ssh cmk nicht klappt forsch ich nochmal nach


'cmk' ist ein Alias der erst verfügbar ist wenn du wirklich eine shell hast.
PNP Developer.
PNP 0.6.14 ist online !
Fragen zu PNP mit Angabe der verwendeten PNP Version werden bevorzugt beantwortet.
OMD - Open Monitoring Distribution

pitchfork

Super Moderator

Beiträge: 15 096

Wohnort: Kassel

Beruf: Sysadmin SAP / Linux / AIX

Anzahl Nagios-Server: 2

Hobbys: Motorrad fahren, wenns die Zeit erlaubt :-)

Nagios-Version(en): 3.2.1

Icinga-Version(en): ---

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 310

Anzahl Services: 4500

Betriebssystem(e): Debian 5.0 Lenny

Plugin-Version(en): 1.4.x

NagVis-Version: 1.4.1

NDO-Version: ---

IDO-Version: ---

Perfparse-Version: ---

Sonstige Addon's: SNMPTT, NagTrap, NagVis 1.4.5, check_mk, PNP-0.6.x. Thruk

7

16.08.2011, 16:04

Zitat von »smue«

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


rrdcached ist nicht Netzwerk transparent. Das ist keien Lösung für dich.

Ich würde die Perfdaten der Satelliten per mod_gearman an die Zentrale zu senden.
Dort zentral _alle_ perfdaten verarbeiten und zusätzlich die Daten wie gehabt auf dem Satelliten zu speichern. Das ist zwar doppelte Datenhaltung aber sicherer/robuster vom Transport her.
Zusätzlich würden in der Zentrale die Special Template wie gewünscht funktionieren.
PNP Developer.
PNP 0.6.14 ist online !
Fragen zu PNP mit Angabe der verwendeten PNP Version werden bevorzugt beantwortet.
OMD - Open Monitoring Distribution

smue

Anfänger

Beiträge: 10

Geburtstag: 28.02.

Wohnort: Berlin

Anzahl Nagios-Server: 3

Nagios-Version(en): 3.2.3

Verteiltes Monitoring: Ja

Redundantes Monitoring: Nein

Anzahl-Hosts: ~500

Anzahl Services: ~6k

Betriebssystem(e): Ubuntu 11.04

Plugin-Version(en): x

NDO-Version: 3

8

16.08.2011, 18:37

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
Der Horizont vieler Menschen ist ein Kreis mit dem Radius Null
- und das nennen sie ihren Standpunkt.
Albert Einstein

Ähnliche Themen