Saturday, May 25th 2013, 4:05am UTC+2
You are not logged in.
Monitoring-Portal »
Projects
»
PNP
»
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.
- 1
- 2
Birthday: May 23rd
Gender: male
Location: Hessen
Occupation: SysAdmin
Number of monitoring servers: 6
Nagios Version: 3.2.0
Distributed monitoring: Ja
Redundant monitoring: Nein
Number of hosts: 250+
Number of services: 1600+
OS: SLES10
Plugin Version: 1.4.14
Other Addons: PNP 0.6.x; Thruk
Thursday, August 28th 2008, 3:56pm
[solved / oder auch nicht] Perfdata nur für manche Hosts
ich steh bei einer PNP config ein bisschen aufm Schlauch. PNP lief seit Monaten ohne Probleme. Dann hab ich es abgeschaltet, weil ich Distributed Monitoring getestet habe. Jetzt nach dem ich die alte Konifg wieder rein geschoben habe, gibts Probleme. Und zwar:
Ich lasse mir Graphen für die CPU Auslastung zeichnen. Die Perfdaten werden im Nagios Frontend angezeigt.
Und in der status.dat sieht das auch ordentlich aus
Host 1:
|
Source code |
1 2 3 4 5 |
servicestatus {
host_name=lseconnect1.aspuk.rts
service_description=CPU
performance_data=cpu=70%;80;95;0;100
process_performance_data=1
|
Host 2:
|
|
Source code |
1 2 3 4 5 6 |
servicestatus {
host_name=enx1.aspuk.rts
service_description=CPU
performance_data=cpu=0%;80;95;0;100
process_performance_data=1
}
|
Also sollte man meinen dass in Nagios alles ordentlich verarbeitet wird.
Wenn ich jetzt ein tail auf die perfdata.log (debug=2) mitlaufen lasse, wird der eine Host upgedated, der andere nicht.
|
|
Source code |
1 2 3 4 |
tail -f perfdata.log |grep -i cpu 2008-08-28 14:51:24 [8603] Found Performance Data for lseconnect1.aspuk.rts / CPU (cpu=55%;80;95;0;100) 2008-08-28 14:51:24 [8603] RRDs::update /usr/local/nagios/share/perfdata/lseconnect1.aspuk.rts/CPU.rrd 1219931484:55 2008-08-28 14:51:24 [8603] /usr/local/nagios/share/perfdata/lseconnect1.aspuk.rts/CPU.rrd updated |
Der gesamte perdata run sieht folgendermassen aus:
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 |
2008-08-28 14:51:24 [8603] Using Config File /usr/local/nagios/etc/pnp/process_perfdata.cfg parameters 2008-08-28 14:51:24 [8603] process_perfdata.pl-0.4.10 starting in DEFAULT Mode 2008-08-28 14:51:24 [8603] Datatype set to 'SERVICEPERFDATA' 2008-08-28 14:51:24 [8603] Found Performance Data for lseconnect1.aspuk.rts / CPU (cpu=55%;80;95;0;100) 2008-08-28 14:51:24 [8603] No Custom Template found for check_nrpe (/usr/local/nagios/etc/pnp//check_commands/check_nrpe.cfg) 2008-08-28 14:51:24 [8603] RRD Datatype is GAUGE 2008-08-28 14:51:24 [8603] Template is check_nrpe.php 2008-08-28 14:51:24 [8603] data2rrd called 2008-08-28 14:51:24 [8603] RRDs::update /usr/local/nagios/share/perfdata/lseconnect1.aspuk.rts/CPU.rrd 1219931484:55 2008-08-28 14:51:24 [8603] /usr/local/nagios/share/perfdata/lseconnect1.aspuk.rts/CPU.rrd updated 2008-08-28 14:51:24 [8603] PNP exiting (runtime 0.003304s) ... |
Für die enx1.aspuk.rts gibt es gar keinen Eintrag im perfdata.log bezüglich CPU.
Für andere Services schon, aber für die sollen keine Perfdaten gezeichnet werden. Sieht dann so aus:
|
|
Source code |
1 2 3 4 5 |
2008-08-28 14:52:44 [9066] Using Config File /usr/local/nagios/etc/pnp/process_perfdata.cfg parameters 2008-08-28 14:52:44 [9066] process_perfdata.pl-0.4.10 starting in DEFAULT Mode 2008-08-28 14:52:44 [9066] Datatype set to 'SERVICEPERFDATA' 2008-08-28 14:52:44 [9066] No Performance Data for enx1.aspuk.rts / interfaces 2008-08-28 14:52:44 [9066] PNP exiting ... |
Ich steh aufm Schlauch. Könnt ihr mir unter helfen?
Vielen Dank.
Gruß
This post has been edited 3 times, last edit by "Mr.Montesa" (Nov 28th 2008, 4:42pm)
Birthday: May 23rd
Gender: male
Location: Hessen
Occupation: SysAdmin
Number of monitoring servers: 6
Nagios Version: 3.2.0
Distributed monitoring: Ja
Redundant monitoring: Nein
Number of hosts: 250+
Number of services: 1600+
OS: SLES10
Plugin Version: 1.4.14
Other Addons: PNP 0.6.x; Thruk
Wednesday, September 3rd 2008, 12:30pm
und danke für die Antwort. Da man den gesammelten Daten ehh nicht mehr vertrauen konnte habe ich noch mal blank angefangen.
Alles was mit PNP zu tun hatte gelöscht, die 0.4.10 frisch kompiliert und den Bulk Mode konfiguriert.
Ich beobachte immer noch meine beiden Hosts:
Die enx1.aspuk.rts liefert im Webfrontend Perfdaten für check_ping, check_cpu, check_hdd_root, check_hdd_opt und check_load.
Im PNP Frontend kommen gerade mal die beiden Disk checks und check_ping an.
perfdatalog (debug = 2):
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 |
nagios@nagios:/usr/local/nagios/var> tail -f perfdata.log |grep enx1 2008-09-03 11:13:45 [6212] Found Performance Data for enx1.aspuk.rts / Availability (rta=0,157ms;100,000;200,000;0; pl=0%;10;20;;) 2008-09-03 11:13:45 [6212] RRDs::update /usr/local/nagios/share/perfdata/enx1.aspuk.rts/Availability.rrd 1220436810:0.157:0 2008-09-03 11:13:45 [6212] /usr/local/nagios/share/perfdata/enx1.aspuk.rts/Availability.rrd updated 2008-09-03 11:15:30 [6745] Found Performance Data for enx1.aspuk.rts / HDD.opt (/opt=723MB;37914;42653;0;47393) 2008-09-03 11:15:30 [6745] RRDs::update /usr/local/nagios/share/perfdata/enx1.aspuk.rts/HDD.opt.rrd 1220436920:723 2008-09-03 11:15:30 [6745] /usr/local/nagios/share/perfdata/enx1.aspuk.rts/HDD.opt.rrd updated 2008-09-03 11:17:00 [7249] Found Performance Data for enx1.aspuk.rts / HDD.root (/=3341MB;6454;7261;0;8068) 2008-09-03 11:17:00 [7249] RRDs::update /usr/local/nagios/share/perfdata/enx1.aspuk.rts/HDD.root.rrd 1220437010:3341 2008-09-03 11:17:00 [7249] /usr/local/nagios/share/perfdata/enx1.aspuk.rts/HDD.root.rrd updated 2008-09-03 11:18:45 [7792] Found Performance Data for enx1.aspuk.rts / Availability (rta=0,154ms;100,000;200,000;0; pl=0%;10;20;;) 2008-09-03 11:18:45 [7792] RRDs::update /usr/local/nagios/share/perfdata/enx1.aspuk.rts/Availability.rrd 1220437110:0.154:0 2008-09-03 11:18:45 [7792] /usr/local/nagios/share/perfdata/enx1.aspuk.rts/Availability.rrd updated |
Es fehlt also check_cpu und check_load in PNP. Im Anhang ein Screenshot der check_load Perfdaten in Nagios:
Für die lseconnect1.aspuk.rts werden check_load und check_cpu gezeichnet.
Jetzt ist guter Rat teuer. Wie kann ich mich da weiter ran arbeiten?
BTW: Wird im Logfile abgebildet wenn die Perfdaten abgelehnt werden, weil sie nicht konform sind?
Gruß Sebastian
Gender: male
Location: Nähe Frankfurt
Occupation: Sys-Admin
Number of monitoring servers: 1
Nagios Version: 3.2.1
Distributed monitoring: Nein
Redundant monitoring: Nein
Number of hosts: ~ 250
Number of services: ~ 2500
OS: Debian Lenny
Plugin Version: 1.4.15
NagVis Version: 1.5.1
Other Addons: PnP 0.6.11, SNMPTT 0.1.2, NagTrap 0.1.3, DokuWiki, SMSTools, mklivestatus
Wednesday, September 3rd 2008, 1:04pm
Wolvie
--> Wer glaubt das Projektmanager Projekte managen, glaubt auch das Zitronenfalter Zitronen falten.
Birthday: May 23rd
Gender: male
Location: Hessen
Occupation: SysAdmin
Number of monitoring servers: 6
Nagios Version: 3.2.0
Distributed monitoring: Ja
Redundant monitoring: Nein
Number of hosts: 250+
Number of services: 1600+
OS: SLES10
Plugin Version: 1.4.14
Other Addons: PNP 0.6.x; Thruk
Wednesday, September 3rd 2008, 1:13pm
ich hab das mal aus der status.dat raus gezogen. Dann weiss man definitiv, was die running config ist:
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
servicestatus {
host_name=enx1.aspuk.rts
service_description=CPU
modified_attributes=0
check_command=check_nrpe!check_cpu
check_period=24x7
notification_period=24x7
check_interval=8.000000
retry_interval=4.000000
event_handler=
has_been_checked=1
should_be_scheduled=1
check_execution_time=3.067
check_latency=48.003
check_type=0
current_state=0
last_hard_state=0
last_event_id=27227
current_event_id=27229
current_problem_id=0
last_problem_id=12891
current_attempt=1
max_attempts=2
current_event_id=27229
last_event_id=27227
state_type=1
last_state_change=1215867498
last_hard_state_change=1215867498
last_time_ok=1218063416
last_time_warning=0
last_time_unknown=0
last_time_critical=1215867378
plugin_output=CPU OK - CPU 1% in use
long_plugin_output=
performance_data=cpu=1%;80;95;0;100
last_check=1218063416
next_check=1249599699
check_options=0
current_notification_number=0
current_notification_id=0
last_notification=0
next_notification=0
no_more_notifications=0
notifications_enabled=1
active_checks_enabled=1
passive_checks_enabled=1
event_handler_enabled=1
problem_has_been_acknowledged=0
acknowledgement_type=0
flap_detection_enabled=1
failure_prediction_enabled=1
process_performance_data=1
obsess_over_service=0
last_update=1220440040
is_flapping=0
percent_state_change=0.00
scheduled_downtime_depth=0
}
|
und
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
servicestatus {
host_name=lseconnect1.aspuk.rts
service_description=CPU
modified_attributes=0
check_command=check_nrpe!check_cpu
check_period=24x7
notification_period=24x7
check_interval=8.000000
retry_interval=4.000000
event_handler=
has_been_checked=1
should_be_scheduled=1
check_execution_time=2.079
check_latency=0.239
check_type=0
current_state=0
last_hard_state=0
last_event_id=29747
current_event_id=29748
current_problem_id=0
last_problem_id=14093
current_attempt=1
max_attempts=2
current_event_id=29748
last_event_id=29747
state_type=1
last_state_change=1220436660
last_hard_state_change=1220436660
last_time_ok=1220440020
last_time_warning=1220436540
last_time_unknown=0
last_time_critical=1220436420
plugin_output=OK - CPU 27% in use (proc: )
long_plugin_output=
performance_data=cpu=27%;80;95;0;100
last_check=1220440020
next_check=1220440140
check_options=0
current_notification_number=0
current_notification_id=1258
last_notification=0
next_notification=0
no_more_notifications=0
notifications_enabled=1
active_checks_enabled=1
passive_checks_enabled=1
event_handler_enabled=1
problem_has_been_acknowledged=0
acknowledgement_type=0
flap_detection_enabled=1
failure_prediction_enabled=1
process_performance_data=1
obsess_over_service=0
last_update=1220440040
is_flapping=0
percent_state_change=0.00
scheduled_downtime_depth=0
}
|
Die process_perfdata.cfg is default, bis auf den Timeout:
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
# # Config File for process_perfdata.pl # # $Id: process_perfdata.cfg-sample.in 423 2008-04-15 17:35:59Z pitchfork $ # # process_perfdata.pl Timout # TIMEOUT = 15 # # Use RRDs Perl Module # USE_RRDs = 1 # # # RRDPATH = /usr/local/nagios/share/perfdata # # # RRDTOOL = /usr/bin/rrdtool # # # CFG_DIR = /usr/local/nagios/etc/pnp/ # # # RRD_HEARTBEAT = 8460 # # # RRA_CFG = /usr/local/nagios/etc/pnp/rra.cfg # # # RRA_STEP = 60 # # # LOG_FILE = /usr/local/nagios/var/perfdata.log # # Loglevel 0=silent 1=normal 2=debug # LOG_LEVEL = 2 # # XML encoding # The supported encodings are ISO-8859-1, UTF-8 and US-ASCII. # http://www.php.net/xml-parser-create XML_ENC = UTF-8 |
Gruß
Gender: male
Location: Nähe Frankfurt
Occupation: Sys-Admin
Number of monitoring servers: 1
Nagios Version: 3.2.1
Distributed monitoring: Nein
Redundant monitoring: Nein
Number of hosts: ~ 250
Number of services: ~ 2500
OS: Debian Lenny
Plugin Version: 1.4.15
NagVis Version: 1.5.1
Other Addons: PnP 0.6.11, SNMPTT 0.1.2, NagTrap 0.1.3, DokuWiki, SMSTools, mklivestatus
Wednesday, September 3rd 2008, 1:33pm
Source code
servicestatus { host_name=enx1.aspuk.rts ... check_latency=48.003 ... }
und
Source code
servicestatus { host_name=lseconnect1.aspuk.rts ... check_latency=0.239 ... }
Die process_perfdata.cfg is default, bis auf den Timeout:
Source code
hmm... Latenz von 48 Sekunden und Timeout von process_perfdata von 15 Sekunden... könnte es daran liegen??
Wolvie
--> Wer glaubt das Projektmanager Projekte managen, glaubt auch das Zitronenfalter Zitronen falten.
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
Wednesday, September 3rd 2008, 1:34pm
BTW: Wird im Logfile abgebildet wenn die Perfdaten abgelehnt werden, weil sie nicht konform sind?
In Log level 2 ja
Aber schau doch mal in die var/object.cache ob für diesen Host wirklich "process_perf_data 1" gesetzt ist.
Jörg
Hilfreiche Infos gefunden? Dann schnell ein paar Cent flattrn
OMD - Open Monitoring Distribution
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
Wednesday, September 3rd 2008, 1:37pm
Hilfreiche Infos gefunden? Dann schnell ein paar Cent flattrn
OMD - Open Monitoring Distribution
Gender: male
Location: Nähe Frankfurt
Occupation: Sys-Admin
Number of monitoring servers: 1
Nagios Version: 3.2.1
Distributed monitoring: Nein
Redundant monitoring: Nein
Number of hosts: ~ 250
Number of services: ~ 2500
OS: Debian Lenny
Plugin Version: 1.4.15
NagVis Version: 1.5.1
Other Addons: PnP 0.6.11, SNMPTT 0.1.2, NagTrap 0.1.3, DokuWiki, SMSTools, mklivestatus
Wednesday, September 3rd 2008, 1:42pm
Source code
servicestatus { host_name=enx1.aspuk.rts ... last_check=1218063416 next_check=1249599699 ... }
und
Source code
servicestatus { host_name=lseconnect1.aspuk.rts ... last_check=1220440020 next_check=1220440140 ... }
Ist mir auch noch aufgefallen. Die Zeitwerte vom Host "enx1.aspuk.rts" "last_check" und "next_check" liegen ziemlich weit außeinander und passen irgendwie nicht auf das "check_interval" (im direkten Vergleich mit "lseconnect1.aspuk.rts").
Sicher, dass die Checks des Hosts "enx1.aspuk.rts" tatsächlich zeitnah ausgeführt werden (-> Latenz !)
Wolvie
--> Wer glaubt das Projektmanager Projekte managen, glaubt auch das Zitronenfalter Zitronen falten.
Birthday: May 23rd
Gender: male
Location: Hessen
Occupation: SysAdmin
Number of monitoring servers: 6
Nagios Version: 3.2.0
Distributed monitoring: Ja
Redundant monitoring: Nein
Number of hosts: 250+
Number of services: 1600+
OS: SLES10
Plugin Version: 1.4.14
Other Addons: PNP 0.6.x; Thruk
Wednesday, September 3rd 2008, 2:07pm
also der Reihe nach:
Host_perfdata habe ich abgeschaltet. Aber die Serive_perfdata für enx1.aspuk.rts/CPU sieht in der objects.cache wie folgt aus:
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
define service {
host_name enx1.aspuk.rts
service_description CPU
check_period 24x7
check_command check_nrpe!check_cpu
contact_groups aspuk_admins
notification_period 24x7
initial_state o
check_interval 8.000000
retry_interval 4.000000
max_check_attempts 2
is_volatile 0
parallelize_check 1
active_checks_enabled 1
passive_checks_enabled 1
obsess_over_service 0
event_handler_enabled 1
low_flap_threshold 2.000000
high_flap_threshold 15.000000
flap_detection_enabled 1
flap_detection_options o,w,u,c
freshness_threshold 0
check_freshness 0
notification_options u,w,c,r
notifications_enabled 1
notification_interval 5760.000000
first_notification_delay 0.000000
stalking_options n
process_perf_data 1
failure_prediction_enabled 1
retain_status_information 1
retain_nonstatus_information 1
}
|
Und nein, der check soll nicht erst 2009 laufen. check_interval ist 8 was bei einer interval_length=15 alle 2 Minuten ist. (Das sagt auch das Webfrontend)
Die Latenz ist nur bei den beiden checks so hoch, wo keine PNP Graphen gezeichnet werden. Bei check_hdd_root, check_hdd_opt und check_icmp liegen sie bei 0.2 sec.
Das ist in der Tat merkwürdig.
Gender: male
Location: Nähe Frankfurt
Occupation: Sys-Admin
Number of monitoring servers: 1
Nagios Version: 3.2.1
Distributed monitoring: Nein
Redundant monitoring: Nein
Number of hosts: ~ 250
Number of services: ~ 2500
OS: Debian Lenny
Plugin Version: 1.4.15
NagVis Version: 1.5.1
Other Addons: PnP 0.6.11, SNMPTT 0.1.2, NagTrap 0.1.3, DokuWiki, SMSTools, mklivestatus
Wednesday, September 3rd 2008, 2:58pm
Aber warum liegt der letzte Check soweit zurück? Und der nächste Check soweit in der Zukunft? (siehe meinen letzten Post)Und nein, der check soll nicht erst 2009 laufen. check_interval ist 8 was bei einer interval_length=15 alle 2 Minuten ist. (Das sagt auch das Webfrontend)
Wolvie
--> Wer glaubt das Projektmanager Projekte managen, glaubt auch das Zitronenfalter Zitronen falten.
Birthday: May 23rd
Gender: male
Location: Hessen
Occupation: SysAdmin
Number of monitoring servers: 6
Nagios Version: 3.2.0
Distributed monitoring: Ja
Redundant monitoring: Nein
Number of hosts: 250+
Number of services: 1600+
OS: SLES10
Plugin Version: 1.4.14
Other Addons: PNP 0.6.x; Thruk
Wednesday, September 3rd 2008, 3:42pm
Ich habe mal folgendens gemacht:
Per submit_check_result ein CRITICAL für den CPU Service auf der enx1.aspuk.rts eingetragen. Das Webfrontend ging direkt auf Rot.
Innerhalb von ein paar Sekunden ging der Service wieder auf OK. Also muss der reguläre check, meinen Wert überschrieben haben.
Danach in die status.dat geschaut und das hier rausgezogen:
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
servicestatus {
host_name=enx1.aspuk.rts
service_description=CPU
modified_attributes=0
check_command=check_nrpe!check_cpu
check_period=24x7
notification_period=24x7
check_interval=8.000000
retry_interval=4.000000
event_handler=
has_been_checked=1
should_be_scheduled=1
check_execution_time=2.067
check_latency=0.022
check_type=0
current_state=0
last_hard_state=0
last_event_id=29775
current_event_id=29776
current_problem_id=0
last_problem_id=14108
current_attempt=1
max_attempts=2
current_event_id=29776
last_event_id=29775
state_type=1
last_state_change=1220448372
last_hard_state_change=1215867498
last_time_ok=1220448372
last_time_warning=0
last_time_unknown=0
last_time_critical=1220448312
plugin_output=CPU OK - CPU 8% in use
long_plugin_output=
performance_data=cpu=8%;80;95;0;100
last_check=1220448372
next_check=1220448492
check_options=0
current_notification_number=0
current_notification_id=0
last_notification=0
next_notification=0
no_more_notifications=0
notifications_enabled=1
active_checks_enabled=1
passive_checks_enabled=1
event_handler_enabled=1
problem_has_been_acknowledged=0
acknowledgement_type=0
flap_detection_enabled=1
failure_prediction_enabled=1
process_performance_data=1
obsess_over_service=0
last_update=1220448439
is_flapping=0
percent_state_change=0.00
scheduled_downtime_depth=0
}
|
Die Duration ist von 53 Tagen auf 0 Minuten zurück und das Interval ist wieder beisammen.
|
|
Source code |
1 2 |
last_check =1220448372 next_check=1220448492 |
Hmmm, und grad ins PNP geschaut. Jetzt werden Graphen für CPU gezeichnet.
Es geht und ich versteh gar nichts mehr.
Dann hab ich zum testen den check_load auch mal von Hand auf CRITICAL gesetzt und wieder OK werden lassen.
Und siehe da, jetzt gibts auch Graphen für Load.
Ich versteh die Welt nicht mehr.
Im Anhang sieht man die Duration der einzelnen checks.
Gruß
Gender: male
Location: Nähe Frankfurt
Occupation: Sys-Admin
Number of monitoring servers: 1
Nagios Version: 3.2.1
Distributed monitoring: Nein
Redundant monitoring: Nein
Number of hosts: ~ 250
Number of services: ~ 2500
OS: Debian Lenny
Plugin Version: 1.4.15
NagVis Version: 1.5.1
Other Addons: PnP 0.6.11, SNMPTT 0.1.2, NagTrap 0.1.3, DokuWiki, SMSTools, mklivestatus
Wednesday, September 3rd 2008, 4:08pm
Wolvie
--> Wer glaubt das Projektmanager Projekte managen, glaubt auch das Zitronenfalter Zitronen falten.
Gender: male
Location: Nähe Frankfurt
Occupation: Sys-Admin
Number of monitoring servers: 1
Nagios Version: 3.2.1
Distributed monitoring: Nein
Redundant monitoring: Nein
Number of hosts: ~ 250
Number of services: ~ 2500
OS: Debian Lenny
Plugin Version: 1.4.15
NagVis Version: 1.5.1
Other Addons: PnP 0.6.11, SNMPTT 0.1.2, NagTrap 0.1.3, DokuWiki, SMSTools, mklivestatus
Thursday, September 4th 2008, 9:46am
...
Es kommt auf vielen Hosts vor dass PNP keine Graohen zeichnet. Und zwar immer nur bei CPU und Load. Alle anderen Perfdaten werden perfekt geschrieben.
...
Meint ihr ich soll auf die "retain_state_information" und "use_retained_scheduling_info" verzichten und das mal abdrehen?
Ich glaube nicht, dass das was hilft. Da Du laut Deiner Beschreibung wohl generell mit den beiden Checks ein Problem hast, wird es wohl nicht an der Retention liegen. Meine Vermutung von meinem vorherigen Post basiert auch nur rein auf der Annahme, dass jemand händisch versehentlich den "next check" weit in die Zukunft gelegt hat. Das ist aber höchst unrealistisch für eine Vielzahl von Checks.
Woran das aber sonst liegen kann... da stehen wir gemeinsam im Dunkeln.
Aber um mal ein paar Blindschüße loszulassen... klicke doch mal auf den XML-Button bei einem der "Problem-Service" im PnP (also diese hoch-erotische Feature
vom Jörg um die XML-Definition des Services sich anzusehen 
) und paste mal die Ausgabe. Wolvie
--> Wer glaubt das Projektmanager Projekte managen, glaubt auch das Zitronenfalter Zitronen falten.
Birthday: May 23rd
Gender: male
Location: Hessen
Occupation: SysAdmin
Number of monitoring servers: 6
Nagios Version: 3.2.0
Distributed monitoring: Ja
Redundant monitoring: Nein
Number of hosts: 250+
Number of services: 1600+
OS: SLES10
Plugin Version: 1.4.14
Other Addons: PNP 0.6.x; Thruk
Thursday, September 4th 2008, 9:59am
This post has been edited 1 times, last edit by "Mr.Montesa" (Sep 4th 2008, 10:07am)
Birthday: Jun 1st
Gender: male
Number of monitoring servers: 2
Nagios Version: 0.0.0
Icinga Version: 1.8.4
Distributed monitoring: Nein
Redundant monitoring: Nein
Number of hosts: >500
Number of services: >2000
OS: Win200x, RHEL4/5/6, OES2
Plugin Version: 1.4.16
Other Addons: PNP 0.6, Brain 2.0
Thursday, September 4th 2008, 10:18am
Ich gehe schwer davon aus, dass der Nagios Scheduler bei dir ein Problem hat.Einfacher gesagt, als getan: Wo keine Perfdaten in PNP ankommen da kein xml file von dem Service.
greets
Nachtrag: So wie es aussieht sind alle CPU/Load Graphen betroffen. Wird nirgends gezeichnet. Nach dem manuellen Anstoßen läufts wieder normal.
Läuft Nagios bei dir in einer VM oder hast du eventuell einen windigen NTP Server eingetragen?
Ist deine check_period 24x7 wirklich 24x7, oder ist die gekürzt oder über excludes eingeschränkt?
S
Gender: male
Location: Nähe Frankfurt
Occupation: Sys-Admin
Number of monitoring servers: 1
Nagios Version: 3.2.1
Distributed monitoring: Nein
Redundant monitoring: Nein
Number of hosts: ~ 250
Number of services: ~ 2500
OS: Debian Lenny
Plugin Version: 1.4.15
NagVis Version: 1.5.1
Other Addons: PnP 0.6.11, SNMPTT 0.1.2, NagTrap 0.1.3, DokuWiki, SMSTools, mklivestatus
Thursday, September 4th 2008, 10:19am
Nachtrag: So wie es aussieht sind alle CPU/Load Graphen betroffen. Wird nirgends gezeichnet. Nach dem manuellen Anstoßen läufts wieder normal.
Was war denn mit dem Host "lseconnect1.aspuk.rts"? Hier hattest Du ja ganz zu Anfang gesagt, dass die Graphen gezeichnet werden. Oder täusche ich mich da?
Wolvie
--> Wer glaubt das Projektmanager Projekte managen, glaubt auch das Zitronenfalter Zitronen falten.
- 1
- 2