Friday, September 3rd 2010, 11:10am UTC+2

You are not logged in.

  • Login
  • Register

Windows Clients überwachen

  • 1
  • 2

cheese

Beginner

Posts: 3

Number of Nagios server: 1

Nagios Versions: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 50

Number of services: 50

OS: win2003/xp/Vista Linux

Plugin Versions: 1.4.13

NDO Version: 1

1

Thursday, February 5th 2009, 2:57pm

Windows Clients überwachen

Hallo

Ich würde gerne ein paar windows Clients überwachen:

  • Freier Plattenplatz auf C:
  • Prozessorauslastung
  • Speicherauslastung

OK - das ist NICHT das Problem.

Aber wie bekomme ich es hin die Rechner nur zu überprüfen wenn sie UP sind.

Sprich - es ist EIN Fehler wenn C: voll ist.

es ist KEIN Fehlern wenn der Rechner aus ist.

Wie mach ich sowas?

Gruß von der Förde

Cheese

simmerl

Professional

Posts: 985

Gender: male

Location: München

Occupation: Operation Engineer

Number of Nagios server: 3

Nagios Versions: 2.9 / 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: ~250

Number of services: ~2.500

OS: CentOS

Plugin Versions: -

NagVis Version: 1.4.5

Other Addons: Puppet, PNP 0.4, check_multi, NRPE, mk_livestatus

2

Thursday, February 5th 2009, 3:14pm

Hm.... velleicht ein check_multi, in dem Du alle Windows-Checks incl einem check_ping kapselst.
Matthias schreibt hier (klick )

Quoted

Der Gesamtstatus kann anhand beliebiger logischer Bedingungen bestimmt werden (PERL-Syntax).
Anhand des Results von check_ping solltest Du den Gesamt-Status des check_multi beeinflussen können.
Ich habs selbst noch nie gebraucht. Korrigiert mich, wenn das so nicht geht!


Wie kommt es denn, dass die maschine aus ist? Wenn das regulär ist, kannst Du ja über die check_period oder notification_period Einfluss nehmen.

Simon

Quellcode

 
1
2
3

[root@zeus ~]# drink < bottle; opener
bottle: cannot open
opener: not found

predator

Intermediate

Posts: 274

Birthday: Jun 25th 1971 (39)

Gender: male

Occupation: Sys Admin

Number of Nagios server: 2

Hobbies: Sport,PC,Musik

Nagios Versions: 2.7 /3.0a3

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 75

Number of services: 412

OS: Suse 9.3

Plugin Versions: 1.4.13

Other Addons: messpc, NC_Net 4.4.0 , PNP-0.4.14, NRPE v2.12

3

Thursday, February 5th 2009, 3:19pm

hi,

Quoted

Sprich - es ist EIN Fehler wenn C: voll ist.
wenn C: voll ist ,gibt es nach deinen Einstellungen ein ok, Warning oder Criticel

P.S. check_multi?


Quoted

es ist KEIN Fehlern wenn der Rechner aus ist.
wenn der Host down ist , geht auch kein Service mehr..........................

?( Ich bin echt verwirrt.
„Ein Mann, der mit einer einfachen Illusion glücklich zu werden weiß, ist unendlich schlauer als einer, der an der Wirklichkeit verzweifelt.“

This post has been edited 1 times, last edit by "predator" (Feb 5th 2009, 3:32pm)

simmerl

Professional

Posts: 985

Gender: male

Location: München

Occupation: Operation Engineer

Number of Nagios server: 3

Nagios Versions: 2.9 / 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: ~250

Number of services: ~2.500

OS: CentOS

Plugin Versions: -

NagVis Version: 1.4.5

Other Addons: Puppet, PNP 0.4, check_multi, NRPE, mk_livestatus

4

Thursday, February 5th 2009, 3:38pm

Überleg mal, ob das eigentlich Sinn macht, was Du da vor hast.

Monitoring ist doch dazu da, dass Du über Fehler informiert wirst.

Notification => "da stimmt was nicht"
keine Notification => "alles in Ordnung".

In Deinem falle hieße aber
keine Notification => "vielleicht alles in Ordnung, kann aber auch sein, dass die Maschine aus ist."

Ist das Teil so wichtig, dass es übewacht werden muss!?

Simon

Quellcode

 
1
2
3

[root@zeus ~]# drink < bottle; opener
bottle: cannot open
opener: not found

cheese

Beginner

Posts: 3

Number of Nagios server: 1

Nagios Versions: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 50

Number of services: 50

OS: win2003/xp/Vista Linux

Plugin Versions: 1.4.13

NDO Version: 1

5

Thursday, February 5th 2009, 4:15pm

vielen Dank für die Antworten.



Es geht um die Überwachung von Clients. Da ist es ok wenn sie aus sind (sitzt halt niemand davor, weil Feierabend oder Urlaub)

Es ist nicht ok wenn die Platte voll ist oder die Kiste dauernd unter Vollast läuft -> unzufriedener Benutzer.

Ich muss in solchen und ähnlichen Fällen eingreifen. Also - eingreifen nur wenn der Host UP ist. Ist er DOWN ist (meist) alles ok

Gruß von der Förde

Andreas

Lefty

Intermediate

Posts: 472

Birthday: Feb 3rd 1966 (44)

Gender: male

Location: Deutschland

Occupation: Tastendrücker und Mausschubser

Number of Nagios server: 1

Nagios Versions: 3.0.3

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 175

Number of services: 1000+ (viel check_multi)

OS: Centos 5.20

Plugin Versions: 1.4.12

NagVis Version: 1.3

NDO Version: 1.4b7

Other Addons: SNMPTT 1.2, NSCLIENT++, PNP SVN 545, Nagios2Asterisk -> Swyx

6

Thursday, February 5th 2009, 4:37pm

Quoted from "simmerl"

Überleg mal, ob das eigentlich Sinn macht, was Du da vor hast.

Monitoring ist doch dazu da, dass Du über Fehler informiert wirst.

Notification => "da stimmt was nicht"
keine Notification => "alles in Ordnung".

In Deinem falle hieße aber
keine Notification => "vielleicht alles in Ordnung, kann aber auch sein, dass die Maschine aus ist."

Ist das Teil so wichtig, dass es übewacht werden muss!?

Simon


Grundsätzlich ja. Mir geht dieses Thema aber ebenfalls schon lange nach. Mir ist jetzt (außer NC_NET, was ich nicht will) aber auch noch nichts gescheites dazu eingefallen. Zur Frage ob sowas wichtig ist: Nein, grundsätzlich ist es nicht ganz soooooo wichtig. Aber es ist schon schön wenn man im Vorgriff, sozusagen proaktiv tätig werden kann. Ich hab das schon öfter gehabt, daß Clients die Platte abgeraucht ist aber schon eine Woche vorher Fehler aufgetreten sind die nicht bemerkt wurden. Diese Woche vorher hätte man schnell die Platte kopiert, in den speziellen Fällen war aber stundenlanges Neuinstallieren angesagt. Gerade bei nicht Standardsoftware ein ärgerliches Unterfangen.

Ich hab da schon ein paar Ideen zu, aber irgendwie waren die immer etwas wackelig was die Zuverlässigkeit angeht. Daher würden mich Erfahrungen und Möglichkeiten von anderen Admins ebenfalls interessieren.

mess

Professional

Posts: 1,661

Location: Esslingen

Number of Nagios server: 3

Nagios Versions: 3.0.5

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: ~1100

Number of services: > 80 per host (check_multi)

OS: RHEL5.5, CentOS

Plugin Versions: 1.4.14

NagVis Version: 1.5x

NDO Version: livestatus ;)

Perfparse Version: PNP 0.6.x

Other Addons: Dokuwiki, Heartbeat 1, DRBD 8.2.1

7

Thursday, February 5th 2009, 5:03pm

Quoted from "Lefty"

Aber es ist schon schön wenn man im Vorgriff, sozusagen proaktiv tätig werden kann.

Wir haben genau dafuer zwei Bereiche, Incident und Proactive:
  • Incident ist das klassische Nagios-Monitoring mit Notification etc. Hier werden wenige, aber wichtige Systemeigenschaften ueberwacht.

  • Proactive laeuft quasi mit und wird nicht benachrichtigt. Hier wird alles moegliche ueberwacht. Ein Team von Sysadmins kuemmert sich darum, die Probleme proaktiv abzuarbeiten. Quasi als TODO-Liste, wobei Nagios die Erfolgskontrolle mitliefert.
Der schoene Nebeneffekt ist, dass eine Vielzahl von Informationen zu einem Host zur Verfuegung stehen, ohne dass es zu unnoetigen Notifications kommt. Das hilft bei der root-cause-Analysis von Problemen.

Und - bevor wir etwas in den Incident-Bereich schieben, muss es sich im Proactive-Bereich mehrere Wochen bewaehren. Quasi als Feldtest. Das hat schon oft geholfen, Fehler zu vermeiden, die bei Einzel-Tests vorher nicht aufgefallen waren.

Implementiert ist das per check_multi, daher hat der Nagios-Server auch nicht viel Last mit den Checks. ;)

Gruss - Matthias
-> check_multi und check_generic

Froster

Intermediate

Posts: 219

Birthday: May 5th 1981 (29)

Gender: male

Location: H'keil

Occupation: Admin

Number of Nagios server: 1

Nagios Versions: 3.0.3

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 300

Number of services: 700

OS: OpenSuse 10.3

Plugin Versions: 1.4.3

NagVis Version: 1.3 rc1

NDO Version: -

Perfparse Version: -

Other Addons: NAGIOSGRAPGER 1.6.5

8

Friday, February 6th 2009, 12:01am

Also einfacher gesagt ihr habe eine Reihe von Checks die nicht als "incident" relevant gelten und andere checks die ohne Notifications aus reinen Perf.- / Erfolgszwecken mitläuft?
Wenn ich das richtig verstanden habe ist das eine gute idee ^^ . Welche Kriterien habt ihr da?

mess

Professional

Posts: 1,661

Location: Esslingen

Number of Nagios server: 3

Nagios Versions: 3.0.5

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: ~1100

Number of services: > 80 per host (check_multi)

OS: RHEL5.5, CentOS

Plugin Versions: 1.4.14

NagVis Version: 1.5x

NDO Version: livestatus ;)

Perfparse Version: PNP 0.6.x

Other Addons: Dokuwiki, Heartbeat 1, DRBD 8.2.1

9

Friday, February 6th 2009, 7:33am

Quoted from "Froster"

Welche Kriterien habt ihr da?

Zum Beispiel:
  • Redundanz verloren
    Wenn z.B. ein Teil eines Spiegels verloren geht, ein Netzteil von zweien ausfaellt, ist die Funktionalitaet noch ok. Die Redundanz muss aber trotzdem wiederhergestellt werden.
  • Administrative Verfahren
    Wenn in einem Verfahren, dass die Maschine konfiguriert, eine Fehlfunktion auftritt, so muss das noch nicht die Funktionalitaet an sich beeintraechtigen. Es kann aber in naher Zukunft zum Problem werden.
  • Anhaltspunkte
    Wir monitoren auch Dinge, die lediglich Anhaltspunkte fuer eine Fehlfunktion sind, aber nicht eindeutig zugeordnet werden koennen: Anzahl der laufenden Prozesse, Anzahl der bestehenden TCP-Verbindungen etc.
  • Patchlevel
    Fehlende Patches koennen, muessen aber nicht die Funktionalitaet eines Systems beeintraechtigen. Wir koennen so feststellen, welche Maschinen es besonders noetig haben.
  • Wartungsfenster-Monitoring
    Waehrend eines Wartungsfenster werden verschiedene Systemparameter umgestellt, z.B. auto_boot=false, Spiegel aushaengen als Fallback etc. Der (manchmal etwas vergessliche ;)) Admin kann nach dem WF kontrollieren, ob er wieder alles in den Normalbetrieb zurueckkonfiguriert hat.

Wie gesagt - die proaktiven Checks werden schon regelmaessig bearbeitet. Nur nicht so zeitnah und ohne den Druck der Notification im Ruecken.

Mittlerweile stellt sich da sogar ein Motivationseffekt ein - die Admins moechten 'Ihre' Kisten in einem ordentlichen Zustand haben und arbeiten haeufig noch mal eben die Proactive-Liste ab, wenn sie z.B. vor Feierabend noch eine Stunde Zeit haben ;)

Gruss - Matthias

P.S.: wenn man das urspruengliche Thema sieht 'Monitoring von Windows-Clients', sind wir ganz schoen OT geworden ;)
-> check_multi und check_generic

cheese

Beginner

Posts: 3

Number of Nagios server: 1

Nagios Versions: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 50

Number of services: 50

OS: win2003/xp/Vista Linux

Plugin Versions: 1.4.13

NDO Version: 1

10

Friday, February 6th 2009, 9:05am

Sagt mal - würde es nicht eventuell mit passive-checks gehen?

Ich habe es noch nicht ausprobiert, aber da sollte doch nur was kommen wenn der Host UP ist.

Und ob der Host DOWN ist kan nagios dann doch garnicht mitbekommen?

Ist das ein Weg oder habe ich das was total falsch verstanden?



Gruß

Andreas

mess

Professional

Posts: 1,661

Location: Esslingen

Number of Nagios server: 3

Nagios Versions: 3.0.5

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: ~1100

Number of services: > 80 per host (check_multi)

OS: RHEL5.5, CentOS

Plugin Versions: 1.4.14

NagVis Version: 1.5x

NDO Version: livestatus ;)

Perfparse Version: PNP 0.6.x

Other Addons: Dokuwiki, Heartbeat 1, DRBD 8.2.1

11

Friday, February 6th 2009, 11:36pm

Quoted from "cheese"

Sprich - es ist EIN Fehler wenn C: voll ist.

es ist KEIN Fehlern wenn der Rechner aus ist.

Wie mach ich sowas?

Vielleicht so:
  • ein check_dummy OK als Hostcheck
  • ein check_ping/check_icmp als Servicecheck
  • alle anderen Checks mit einer Servicedependency auf den Ping-Check, so dass sie nicht ausgefuehrt werden, wenn der Host down ist.
-> check_multi und check_generic

PANIC!

Beginner

Posts: 14

Number of Nagios server: 1

Nagios Versions: 3.0.2

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 80

Number of services: 500

OS: Ubuntu 8.10 LTS

Plugin Versions: 1.4.11

12

Saturday, February 7th 2009, 10:23pm

Finde das mit dem Proactive eine sehr gute Ide ;-)

Aber back to topic.

Wie wäre es mit send_ncsa vom nscleint++?
Fände ich schon arg schick und für Maschinen die auch mal aus sind der beste Weg.

Lefty

Intermediate

Posts: 472

Birthday: Feb 3rd 1966 (44)

Gender: male

Location: Deutschland

Occupation: Tastendrücker und Mausschubser

Number of Nagios server: 1

Nagios Versions: 3.0.3

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 175

Number of services: 1000+ (viel check_multi)

OS: Centos 5.20

Plugin Versions: 1.4.12

NagVis Version: 1.3

NDO Version: 1.4b7

Other Addons: SNMPTT 1.2, NSCLIENT++, PNP SVN 545, Nagios2Asterisk -> Swyx

13

Sunday, February 8th 2009, 11:05am

@ Mess: Ich mache das ähnlich. Aber die Maschinen sind (bis auf wenige) immer an. Nur zu Clients ist mir noch nichts gescheites eingefallen. Ich glaube auch nicht, daß wir so sehr OT sind. Ich halte Deine Ausführungen für sehr hilfreich. :thumbup:

Topic:
NSCA setzt ja voraus, daß passive Checks Verwendung finden. Das war auch mein erster Gedanke. Unschön ist das, wenn ein Notebook seinen Status übermittelt und dann für Wochen auf die Straße verschwindet. Oder ein Client 100% CPU meldet, dann abgeschaltet wird und der Kollege in den Urlaub abhaut. Bleibt dann alles rot, dann nimmt das nach einer Weile niemand mehr ernst oder die Leute rennen umsonst in der Gegend rum. Ich halte die Nachteile von passiven Checks in diesem Fall für zu groß. Werden keine Ergebnisse gemeldet, dann kann es sein, daß der Client nicht läuft. Es kann aber auch sein, daß die Checks gar nicht funktionieren. Bei aktiven Checks wird der Client schon selbst anrufen wenn er nicht ins Netz kommt. Das ist dann schon ein Incident.

Eine Möglichkeit wäre es, den Status immer auf OK zu setzen wenn der Host nicht erreichbar ist. Unabhängig davon ob einer der Service Checks auf NIO steht. Aber auch das hat Nachteile. Gangbar wäre das vieleicht über Check_Multi. Da fand ich das Beispiel von Mess schon ganz gut.

mess

Professional

Posts: 1,661

Location: Esslingen

Number of Nagios server: 3

Nagios Versions: 3.0.5

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: ~1100

Number of services: > 80 per host (check_multi)

OS: RHEL5.5, CentOS

Plugin Versions: 1.4.14

NagVis Version: 1.5x

NDO Version: livestatus ;)

Perfparse Version: PNP 0.6.x

Other Addons: Dokuwiki, Heartbeat 1, DRBD 8.2.1

14

Sunday, February 8th 2009, 11:55am

Quoted from "Lefty"

Eine Möglichkeit wäre es, den Status immer auf OK zu setzen wenn der Host nicht erreichbar ist. Unabhängig davon ob einer der Service Checks auf NIO steht. Aber auch das hat Nachteile. Gangbar wäre das vieleicht über Check_Multi.

Zum Beispiel mit der folgenden Konstruktion:

Source code

 
1
2
3
4
5
6
7
8

# check_client.cmd
# Call:  check_multi -f check_client.cmd -s HOSTNAME=<host>
command [ ping     ] = check_icmp -H $HOSTNAME$ -w 500,5% -c 1000,10%
eval    [ offline  ] = if ($STATE_ping$ != $OK) { print "Host offline"; exit 0; }
# execute these commands only if host online
command [ command1 ]  = ...
command [ command2 ]  = ...
...

Wenn der Host online ist, werden alle Kommandos unten ausgefuehrt. Wenn nicht, wird einfach "Host offline" ausgegeben und 0 - OK zurueckgegeben. Das eval-Kommando ist quasi eine Art dynamischer Notausgang ;)

Ansonsten wuerde ich im Hostcheck tatsaechlich immer OK setzen, damit mir die offline Hosts im Tactical overview nicht den Blick auf die wirklichen Probleme verstellen. Wenn ich wissen will, wann der Host online war. koennte ich ja die Performance-Daten des ping checks mitloggen.

Gruss - Matthias

EDIT: ups, kleiner Fehler im eval ;)
-> check_multi und check_generic

This post has been edited 2 times, last edit by "mess" (Feb 8th 2009, 11:28pm)

Lefty

Intermediate

Posts: 472

Birthday: Feb 3rd 1966 (44)

Gender: male

Location: Deutschland

Occupation: Tastendrücker und Mausschubser

Number of Nagios server: 1

Nagios Versions: 3.0.3

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 175

Number of services: 1000+ (viel check_multi)

OS: Centos 5.20

Plugin Versions: 1.4.12

NagVis Version: 1.3

NDO Version: 1.4b7

Other Addons: SNMPTT 1.2, NSCLIENT++, PNP SVN 545, Nagios2Asterisk -> Swyx

15

Monday, February 9th 2009, 5:20pm

Sodele, ich habe das heute mal so wie vorgeschlagen eingebaut. Schön mit 10% Plattenplatz als Warnung (6 checks insgesamt). Pünktlich zum Feierabend haben sich alle Probleme sozusagen in Luft aufgelöst bzw. wurden erfolgreich verdrängt. Ist der Client online kann man gleich die Platte aufräumen oder das Eventlog prüfen. So muss das sein.

Vielen Dank mess! Das war genau was ich gesucht habe. :thumbsup: Jetzt hab ich gleich einen Grund mich noch näher mit check_multi zu beschäftigen.

@ cheese: Ich kann Dir die von mess vorgeschlagene Vorgehensweise nur ans Herz legen. Es klappt wirklich einwandfrei und der Konfigurationsaufwand ist recht gering. Optimal für alles was öfter mal abgeschaltet wird (Clients, Drucker usw.) und nur "wichtig" ist aber nicht kritisch.

simmerl

Professional

Posts: 985

Gender: male

Location: München

Occupation: Operation Engineer

Number of Nagios server: 3

Nagios Versions: 2.9 / 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: ~250

Number of services: ~2.500

OS: CentOS

Plugin Versions: -

NagVis Version: 1.4.5

Other Addons: Puppet, PNP 0.4, check_multi, NRPE, mk_livestatus

16

Monday, February 9th 2009, 5:22pm

Nice to know. Danke auch von meiner Seite.

Simon

Quellcode

 
1
2
3

[root@zeus ~]# drink < bottle; opener
bottle: cannot open
opener: not found

mess

Professional

Posts: 1,661

Location: Esslingen

Number of Nagios server: 3

Nagios Versions: 3.0.5

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: ~1100

Number of services: > 80 per host (check_multi)

OS: RHEL5.5, CentOS

Plugin Versions: 1.4.14

NagVis Version: 1.5x

NDO Version: livestatus ;)

Perfparse Version: PNP 0.6.x

Other Addons: Dokuwiki, Heartbeat 1, DRBD 8.2.1

17

Monday, February 9th 2009, 6:09pm

Quoted from "Lefty"

Das war genau was ich gesucht habe. Jetzt hab ich gleich einen Grund mich noch näher mit check_multi zu beschäftigen.

Danke fuer die Blumen ;)

By the way - auf diese Art und Weise implementieren wir auch dynamisches Monitoring. Ich habe weder Lust und Zeit, Nagios-Konfigurationen zu aendern, weil ein Host z.B. eine neue Applikation bekommen hat. Also wird einmal eine generische check_multi-Regel fuer jeden Host implementiert und die schlaegt dann zu, wenn die Trigger-Werte stimmen. Sonst laeuft sie nur leer mit. Die Performance auf dem Remote Server und Load auf dem Nagios Server sind nur minimal beeintraechtigt.

Anders sind solche grossen Environments IMHO gar nicht mehr zu bewaeltigen.

Gruss - Matthias
-> check_multi und check_generic

tekk-raver

Beginner

Posts: 1

Number of Nagios server: 1

Nagios Versions: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 10 Server 150 Clients

Number of services: noch am erstellen und testen

OS: Windows Server 2003, Windows XP, Freebsd, Debian

Plugin Versions: check_multi, nssclient++ mit nrpe

NDO Version: 1

18

Wednesday, May 13th 2009, 12:12pm

Hallo,
das ist genau das, was ich gesucht habe.
hab das gleich mal übernommen.

Source code

 
1
2
3
4
5

command [ ping 	] = check_icmp -H $HOSTNAME$ -w 500,5% -c 1000,10%
eval	[ offline  ] = if ($STATE_ping$ != $OK) { print "Host offline"; exit 0; }
#--- status
command[ status_windows_updates ]		= check_nrpe -H $HOSTADDRESS$ -c check_windows_updates -t 300
command[ status_nt_check_disk_c ]		= check_nrpe -H $HOSTADDRESS$ -c nt_check_disk_c


Frage: Wenn der Host erreichbar ist, liefert er folgende
Statusinformation: WARNING - 4 plugins checked, 1 warning (status_nt_check_disk_c), 3 ok
– 1


pingOK - ber-pc-060: rta 0.267ms, lost 0% 3


status_windows_updatesThere is no critical updates
Number of software or driver updates not installed: 0 4


status_nt_check_disk_cUsed: 14280 MB (71%) Free: 5714 MB (28%)

Ist der host aber nicht erreichbar bekomme ich die alten statusinformationen nicht mehr angezeigt.
Statusinformation: Host offline
Wie kann ich das einstellen, dass die alten statusinformatitonen noch sichtbar sind kombiniert mit den neuen ping Status
Host offline
1 ping failed
3 status-windows_updates There is no critical updates....
4 status_nt_check_disc_c Used:........

Vielen dank

Quoted from "mess"

Quoted from "Lefty"

Eine Möglichkeit wäre es, den Status immer auf OK zu setzen wenn der Host nicht erreichbar ist. Unabhängig davon ob einer der Service Checks auf NIO steht. Aber auch das hat Nachteile. Gangbar wäre das vieleicht über Check_Multi.

Zum Beispiel mit der folgenden Konstruktion:

Source code

 
1
2
3
4
5
6
7
8

# check_client.cmd
# Call:  check_multi -f check_client.cmd -s HOSTNAME=<host>
command [ ping     ] = check_icmp -H $HOSTNAME$ -w 500,5% -c 1000,10%
eval    [ offline  ] = if ($STATE_ping$ != $OK) { print "Host offline"; exit 0; }
# execute these commands only if host online
command [ command1 ]  = ...
command [ command2 ]  = ...
...

Wenn der Host online ist, werden alle Kommandos unten ausgefuehrt. Wenn nicht, wird einfach "Host offline" ausgegeben und 0 - OK zurueckgegeben. Das eval-Kommando ist quasi eine Art dynamischer Notausgang ;)

Ansonsten wuerde ich im Hostcheck tatsaechlich immer OK setzen, damit mir die offline Hosts im Tactical overview nicht den Blick auf die wirklichen Probleme verstellen. Wenn ich wissen will, wann der Host online war. koennte ich ja die Performance-Daten des ping checks mitloggen.

Gruss - Matthias

EDIT: ups, kleiner Fehler im eval ;)

ulange

Trainee

Posts: 66

Gender: male

Location: in NRW

Occupation: E-Techniker

Number of Nagios server: 3

Hobbies: Bogenschiessen

Nagios Versions: 3.0X

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 250

Number of services: 500

OS: Ubuntu 8.04

Plugin Versions:

19

Tuesday, June 30th 2009, 8:16am

Hallo,

ich habe da noch eine Frage.

Ist das normal das wenn der eval Befehl in eine Zeile der CMD-Datei einfügt wird die Ausgabenummerierung eine "Loch" hat .

Siehe Zitat.

Quoted from "tekk-raver"



Host offline
1 ping failed
3 status-windows_updates There is no critical updates....
4 status_nt_check_disc_c Used:........



Gruss

ulange

mess

Professional

Posts: 1,661

Location: Esslingen

Number of Nagios server: 3

Nagios Versions: 3.0.5

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: ~1100

Number of services: > 80 per host (check_multi)

OS: RHEL5.5, CentOS

Plugin Versions: 1.4.14

NagVis Version: 1.5x

NDO Version: livestatus ;)

Perfparse Version: PNP 0.6.x

Other Addons: Dokuwiki, Heartbeat 1, DRBD 8.2.1

20

Tuesday, June 30th 2009, 10:01am

Quoted from "ulange"

Ist das normal das wenn der eval Befehl in eine Zeile der CMD-Datei einfügt wird die Ausgabenummerierung eine "Loch" hat .

Jein ;)

Es gibt im check_multi ja zwei Arten von eval:
  1. eval - kein Output
  2. eeval (echo eval) - mit Output

Die Idee war, die Zaehlung beim Eval ohne Output mitlaufen zu lassen, um deutlich zu machen , dass im Hintergrund etwas passiert, das das Gesamtergebnis beeinflussen kann.

Ich gebe zu, dass die Luecke auch verwirren kann ;)

Gibt es dazu Meinungen? Soll ich 'eval'-Befehle komplett verstecken / maskieren?

Gruss - Matthias
-> check_multi und check_generic
  • 1
  • 2

Similar threads