Saturday, May 18th 2013, 9:51pm UTC+2

You are not logged in.

  • Login
  • Register

"kumulierter" Status an übergeordneten Nagiosserver senden

Dear visitor, welcome to Monitoring-Portal.
Although this is a german monitoring forum, please don't hesitate to post in English. Nearly everybody here understands you and will answer in English as well.
If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form to register here or read more information about the registration process. If you are already registered, please login here.

Nightflight

Beginner

Posts: 38

Number of monitoring servers: 1

Nagios Version: Nagios 3.2.0 und Centreon 2.1.4.

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 15

Number of services: 60

OS: W2K W2K3 NT4 ESXi

Plugin Version: Ndoutils 1.4b8;NRPE 2.9;VMware-VIPerl 1.5.0;NSClient++ 0.3.7

NDO Version: 1

1

Thursday, September 22nd 2011, 9:05am

"kumulierter" Status an übergeordneten Nagiosserver senden

Hallo Gemeinde,
bevor ich mich selber ins Skripting stürze wollte ich mal anfragen, ob es vielleicht schon eine fertige Lösung für nachfolgende Anforderung gibt.

Situation:
Wir (werden) haben ca. 120 "untergeordnete" Nagiosserver, von denen jeder ca. 100 Clients mit je 10 Services überwacht.
Die Überwachungsergebnisse sollen (per nscaweb über SSL) als passive Checks an einen zentralen Monitoringserver im Internet
übertragen werden.
Das ganze Konstrukt funktioniert mit ein paar TestClients wunderbar.
Wenn wir das ganze jedoch produktiv setzten wollen gehe ich davon aus, das der zentrale Monitoringserver niemals die Datenflut (120*100*10) bewältigen wird - zumal auch noch SSL gefordert ist.

meine Idee:
die "untergeordneten" Nagiosserver sammeln die Prüfergebnisse ihrer Überwachten Clients und schicken nur noch 4 passive Checks
an den zentralen Monitoringserver:

Hostcheck: Nagios_XY (Zustand des Nagiosservers)
Servicecheck: Nagios_XY_all_services (kumulierter Zustand aller überwachten Services auf dem Nagiosserver selber)
Servicecheck: Nagios_XY_Slaves_Hosts (Kumulierter Zustand aller Hostchecks der, durch den jeweiligen Nagiosserver überwachten Hosts)
Servicecheck: Nagios_XY_Slaves_Services (kumulierter Zustand aller Servicechecks der, durch den jeweiligen Nagiosserver überwachten Hosts)

Unter kumulierten Zustand stelle ich mir vor, das z.B. ein Nagios_XY_Slaves_Services OK gemeldet wird, wenn alle überwachten Services OK sind.
Der Status des Nagios_XY_Slaves_Services richtet sich nach dem kritischsten Status der kumulierten Servicechecks.

Meine Lösung wäre ein Skript, das durch die Status.dat durchläuft, die daten wie oben beschrieben kumuliert, ein Ergebnis erzeugt und dieses an NSCAWEB zum weiterversandt übergibt.
Gibt es sowas eventuell schon, sodaß ich mir die Mühe sparen kann?

pitchfork

Administrator

Posts: 18,436

Location: Kassel

Occupation: Sysadmin SAP / Linux / AIX

Number of monitoring servers: 2

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

Nagios Version: 3.2.3 ( OMD )

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 360

Number of services: 6700

OS: Debian 6.0

Plugin Version: 1.4.x

Other Addons: SNMPTT, NagTrap, check_mk, PNP-0.6.x. Thruk

2

Thursday, September 22nd 2011, 9:11am

Quoted from "Nightflight"

Wir (werden) haben ca. 120 "untergeordnete" Nagiosserver, von denen jeder ca. 100 Clients mit je 10 Services überwacht.
Die Überwachungsergebnisse sollen (per nscaweb über SSL) als passive Checks an einen zentralen Monitoringserver im Internet
übertragen werden.
Das ganze Konstrukt funktioniert mit ein paar TestClients wunderbar.
Wenn wir das ganze jedoch produktiv setzten wollen gehe ich davon aus, das der zentrale Monitoringserver niemals die Datenflut (120*100*10) bewältigen wird - zumal auch noch SSL gefordert ist.


Wie sehen deine Messergebnisse hierzu aus?
+++ PNP Developer +++ PNP 0.6.21 ist online ! +++
Hilfreiche Infos gefunden? Dann schnell ein paar Cent flattrn
OMD - Open Monitoring Distribution

Nightflight

Beginner

Posts: 38

Number of monitoring servers: 1

Nagios Version: Nagios 3.2.0 und Centreon 2.1.4.

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 15

Number of services: 60

OS: W2K W2K3 NT4 ESXi

Plugin Version: Ndoutils 1.4b8;NRPE 2.9;VMware-VIPerl 1.5.0;NSClient++ 0.3.7

NDO Version: 1

3

Thursday, September 22nd 2011, 9:24am

Hallo,
ich hab noch keine Messungen gemacht - für den bisherigen Test haben wir
1 zentralen Nagios
1 "untergeordneten" Nagios mit 5 ServiceChecks
1 überwachten Client mit 5 Servicechecks
gebaut.
Dabei ging es lediglich um die Prüfung der angedachten Kommunikationswege über NSCAWEB SSL und nicht um einen Lasttest.
Ich bin jetzt einfach mal von der schieren Menge an Daten (selbst ohne PerfDaten) ausgegangen und bin davon überzeugt gewesen, das der zentrale Nagios
darunter krachen gehen würde. Schließlich wollen wir die Check- und Freshnessintervalle nicht auf alle 2 Stunden setzen.

pitchfork

Administrator

Posts: 18,436

Location: Kassel

Occupation: Sysadmin SAP / Linux / AIX

Number of monitoring servers: 2

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

Nagios Version: 3.2.3 ( OMD )

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 360

Number of services: 6700

OS: Debian 6.0

Plugin Version: 1.4.x

Other Addons: SNMPTT, NagTrap, check_mk, PNP-0.6.x. Thruk

4

Thursday, September 22nd 2011, 9:30am

Also ist deine nächte Aufgabe ein "untergeordnetes" System mit entsprechend größe aufzusetzen.

Du solltest die größe auch eher zusätzlich in check/minute definieren
Die Anzahl Hosts/Services mag ja nett sein, sagen aber erst mit einer Info über den normal_check_interval etwas über die Anzahl der zu erwartenden Events aus!

Also System aufsetzen und den Netzwerk Traffic messen der über nscawb läuft.

Ohne diese Messung ist alles weitere reine Spekulation.

Jörg

BTW: Die Messung geht wunderbar über IPTables Rules.
+++ PNP Developer +++ PNP 0.6.21 ist online ! +++
Hilfreiche Infos gefunden? Dann schnell ein paar Cent flattrn
OMD - Open Monitoring Distribution

Nightflight

Beginner

Posts: 38

Number of monitoring servers: 1

Nagios Version: Nagios 3.2.0 und Centreon 2.1.4.

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 15

Number of services: 60

OS: W2K W2K3 NT4 ESXi

Plugin Version: Ndoutils 1.4b8;NRPE 2.9;VMware-VIPerl 1.5.0;NSClient++ 0.3.7

NDO Version: 1

5

Thursday, September 22nd 2011, 11:49am

Hallo,
alleine schon aus Gründen der Übersichtlichkeit möchte ich das Zusammenfassen der Checkstates der
untergeordneten Nagiosserver im zentralen Monitoring.
Es geht mir bei meinem Posting also wirklich nur darum, ob es dazu schon etwas gibt (Skript o.ä.) oder nicht.

pitchfork

Administrator

Posts: 18,436

Location: Kassel

Occupation: Sysadmin SAP / Linux / AIX

Number of monitoring servers: 2

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

Nagios Version: 3.2.3 ( OMD )

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 360

Number of services: 6700

OS: Debian 6.0

Plugin Version: 1.4.x

Other Addons: SNMPTT, NagTrap, check_mk, PNP-0.6.x. Thruk

6

Thursday, September 22nd 2011, 11:53am

nein, gibt es nicht und ich würde dir auch davon abraten so etwas umsetzen zu wollen.
+++ PNP Developer +++ PNP 0.6.21 ist online ! +++
Hilfreiche Infos gefunden? Dann schnell ein paar Cent flattrn
OMD - Open Monitoring Distribution

Rene Storm

Intermediate

Posts: 521

Gender: male

Location: Hamburg

Number of monitoring servers: some

Hobbies: kitesurfing, buggykiting, snowboard,climbing,sleeping

Nagios Version: 3

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: 800

Number of services: 8000

OS: Linux

Plugin Version: latest

NagVis Version: latest

NDO Version: NO MORE ;o)

7

Thursday, September 22nd 2011, 1:26pm

Hallo Nightfly,

hab ich schon mal gemacht, damals mit einer SQL Abfrage. Würde ich heute aber mit mk_livestatus lösen, aber nsca geht natürlich auch.

Nimm doch einfach im zentralen Nagios-Server:
Nagios-Satellite=Host im zentralen Server
Remote-Host alle Services=Ein Service auf dem zentralen Server


LQL ungefährt

Source code

 
1

echo -e "GET services\nColumns: description state last_check plugin_output\nFilter: host_name = $REMOTE-HOST\n\n" | netcat -c -w 1 -u $REMOTE_NAGIOS $REMOTE_POT

Dann grepst du nach einen Staus > 0 und fertig.

Dann haust du in den Remote Host die action Url deines Remote Nagios+Host URL rein.

Somit 120 Hosts * 100 Services = kein Problem.

Das ganze läßt sich über lql ode sql relativ leicht scripten, so dass du auch die Konfig automatisierst.
Thread


Gruß,
Rene

Nightflight

Beginner

Posts: 38

Number of monitoring servers: 1

Nagios Version: Nagios 3.2.0 und Centreon 2.1.4.

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 15

Number of services: 60

OS: W2K W2K3 NT4 ESXi

Plugin Version: Ndoutils 1.4b8;NRPE 2.9;VMware-VIPerl 1.5.0;NSClient++ 0.3.7

NDO Version: 1

8

Friday, September 23rd 2011, 11:05am

Quoted from "Rene Storm"

hab ich schon mal gemacht, damals mit einer SQL Abfrage. Würde ich heute aber mit mk_livestatus lösen,

Hi,

wenn ich die Beschreibung von mk_Livestatus Multisite richtig verstanden habe (wovon nicht zwingend auszugehen ist)
werden doch dort einfach die Visualisierung der Prüfergebnisse auf der zentralen Monitoringinstanz ermöglicht.
Das bringt zwar die "Checkarbeit" vom zentr. Monitoring weg, benötigt jedoch zugriff vom zentralen Nagios auf die "Untergeordneten" ?!

Das wird bei uns nicht funktionieren - die "untergeordneten" Nagiosserver können zwar über HTTP(s) den zentralen erreichen aber nicht umgekehrt.

Oder meintest du gar nicht Multisite?
Wie genau würdest du Livestatus auf den untergeordneten und dem zentralen Monitoringserver einrichten, wenn nur eine http(s)-Verbindung von "unten" nach "oben" besteht?

Ich entschuldige mich schon im Vorfeld, falls die Frage dämlich ist - Nagios ist bei mir leider nur eine kleine Nebenbeschäftigung die mal ebend so neben den ganzen
Hauptaufgaben abfallen muß ;(

pitchfork

Administrator

Posts: 18,436

Location: Kassel

Occupation: Sysadmin SAP / Linux / AIX

Number of monitoring servers: 2

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

Nagios Version: 3.2.3 ( OMD )

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 360

Number of services: 6700

OS: Debian 6.0

Plugin Version: 1.4.x

Other Addons: SNMPTT, NagTrap, check_mk, PNP-0.6.x. Thruk

9

Friday, September 23rd 2011, 11:36am

Quoted from "Nightflight"

Nagios ist bei mir leider nur eine kleine Nebenbeschäftigung die mal ebend so neben den ganzen
Hauptaufgaben abfallen muß ;(


Das was du vor hast ist aber ein großes Projekt.
Ich habe dir bereits zu einer vorgensweise geraten, die du aber abgeleht hast.

Mit dieser Einstellung muss dein Projekt scheitern!
+++ PNP Developer +++ PNP 0.6.21 ist online ! +++
Hilfreiche Infos gefunden? Dann schnell ein paar Cent flattrn
OMD - Open Monitoring Distribution

Nightflight

Beginner

Posts: 38

Number of monitoring servers: 1

Nagios Version: Nagios 3.2.0 und Centreon 2.1.4.

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 15

Number of services: 60

OS: W2K W2K3 NT4 ESXi

Plugin Version: Ndoutils 1.4b8;NRPE 2.9;VMware-VIPerl 1.5.0;NSClient++ 0.3.7

NDO Version: 1

10

Friday, September 23rd 2011, 1:36pm

Hallo Pitchfork,

ich habe deinen Vorschlag nicht prinzipiell abgelehnt.
Um genau zu sein bin ich selber ein Verfechter von Testumgebungen und fundierten Messungen, bevor man eine Lösung produktiv setzt.

Allerdings wird diesem Vorgehen nicht in jeder Firma die notwendigen zeitlichen und materiellen Ressourcen bereitgestellt.

Ich wüßte einfach nicht, wie ich "auf die Schnelle" eine Testumgebung mit 120*100 Clients aufsetzten soll bzw. deren Kommunikation (SSL-Anfragen von unterschiedlichen
IP's mit unterschiedlichen Zertifikaten) simulieren soll.

Vielleicht gibt es ja irgentwo ein Whitepaper zum Sizing (CPU,RAM) eines Nagiosservers unter beachtung der zu erwartenden Menge an Host- und Servicechecks?

Nochmal - es liegt mir fern, Vorschläge von Personen zu ignorieren, die sicherlich mehr Ahnung von der Materie haben als ich.

Similar threads