Thursday, May 23rd 2013, 6:35am UTC+2

You are not logged in.

  • Login
  • Register

mod_gearman+icinga timout=critical

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.

noone123

Beginner

Posts: 31

Gender: male

Number of monitoring servers: 2

Nagios Version: icinga1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: +8k

Number of services: +80k

OS: debian

Plugin Version: 1.4.15-3

Other Addons: mod_gearman, livestatus

1

Tuesday, August 7th 2012, 3:58pm

mod_gearman+icinga timout=critical

Hallo,

ich probiere gerade ein bischen mit mod_gearman rum und hätte ein paar fragen bzgl. config und verhalten.

System: Debian Squeeze
mod_gearman 1.3.6
gearmand 0.25
icinga 1.7.0.4
thruk 1.34
livestatus 1.2.0p2

CPU: 2x Xeon L5520 @ 2,27 (4 cores + ht pro cpu)
8GB Ram

Im Moment prüfe ich gerade 6k hosts und ca 66k servicechecks

Problem:
Ich bekomme im worker log nach einiger zeit auf einmal z.b. 20 einträge des gleichen checks der einen timeout wirft.

Source code

 
1

 [2012-08-07 15:48:06][13790][INFO ] timeout (10s) hit for servicecheck: HOSTNAME- PING


Meine mod_gearman new und worker config ist eigentlich ziehmlihc default.
Habe worker min auf 400 und max auf 750...
Jobtimeout=20
workaround_rc_25=off

Es scheint so als würden die Servicechecks mit timeout pro Zyklus immer öfter ausgeführt. Die waiting queue läuft nach einiger Zeit voll und ich bekomme immer mehr einträge des selben checks im worker log.
Jemand ne idee was man da machen kann?


Ich habe auch noch ein 2test setup (anderer hardware und weniger checks)
Hier passiert das gleiche. Z.b.

Source code

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[2012-08-07 16:00:46][17040][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:00:52][17000][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:00:58][31363][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:01:04][17445][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:01:10][15652][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:01:16][15518][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:01:22][17793][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:01:28][18013][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:01:34][17790][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:01:40][16897][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:01:46][19445][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:01:52][19632][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:01:58][19632][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:02:04][17858][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:02:10][19257][INFO ] timeout (5s) hit for hostcheck: myhost
[2012-08-07 16:02:16][19662][INFO ] timeout (5s) hit for hostcheck: myhost


Keine ahnung wiese der alle 6 sec nen hostcheck macht... hoffe ihr habt ne idee :D

Wenn ihr noch mehr infos braucht einfach sagen.. ich liefere alles was geht :D

This post has been edited 2 times, last edit by "noone123" (Aug 7th 2012, 4:28pm)

dnsmichi

Super Moderator

Posts: 5,986

Birthday: May 30th 1983 (29)

Gender: male

Location: Nürnberg

Occupation: Consultant / Developer beim besten Arbeitgeber der Welt @netways

Number of monitoring servers: Icinga: 4x dev, 10++ prod, Icinga2: 2x dev

Nagios Version: s/nagios/icinga/

Icinga Version: 1.9.1 / GIT

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: 1000+

Number of services: 15000+

OS: RHEL, Debian, SUSE

Plugin Version: 1.4.16

IDO-Version: 1.9.1 / GIT MySQL/Postgresql/Oracle

Other Addons: Icinga Web, PNP, check_multi, inGraph, EventDB, LConf

2

Tuesday, August 7th 2012, 5:14pm

ohne die konfiguration (main sowie beispielhost) zu kennen, wirds schwierig.
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

noone123

Beginner

Posts: 31

Gender: male

Number of monitoring servers: 2

Nagios Version: icinga1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: +8k

Number of services: +80k

OS: debian

Plugin Version: 1.4.15-3

Other Addons: mod_gearman, livestatus

3

Tuesday, August 7th 2012, 6:19pm

nehmen wir mal das kleine setup.

icinga, mod_german und germand laufen dort (als local worker)

mod_gearman_neb.cfg

Source code

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

debug=0
logfile=/var/log/mod_gearman/mod_gearman_neb.log
server=localhost:4730
eventhandler=yes
services=yes
hosts=yes
do_hostchecks=yes
encryption=yes
key=123
use_uniq_jobs=on
localhostgroups=
localservicegroups=
result_workers=1
perfdata=no
perfdata_mode=1
orphan_host_checks=yes
orphan_service_checks=yes
accept_clear_results=no


worker.cfg

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

debug=0
logfile=/var/log/mod_gearman/mod_gearman_worker.log
server=localhost:4730
eventhandler=yes
services=yes
hosts=yes
timeout_return=3
do_hostchecks=yes
encryption=yes
key=123
job_timeout=60
min-worker=400
max-worker=700
idle-timeout=30
max-jobs=1000
spawn-rate=1
fork_on_exec=no
show_error_output=yes
enable_embedded_perl=on
use_embedded_perl_implicitly=off
use_perl_cache=on
p1_file=/usr/local/share/mod_gearman/mod_gearman_p1.pl
workaround_rc_25=off


icinga.cfg (auszug)

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
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

command_check_interval=-1
external_command_buffer_slots=16384
event_broker_options=-1
broker_module=/usr/local/lib/mod_gearman/mod_gearman.o config=/etc/mod_gearman/mod_gearman_neb.conf
broker_module=/usr/local/lib/mk-livestatus/livestatus.o /var/lib/icinga/rw/live log_file=/var/log/icinga/livestatus.log
service_inter_check_delay_method=s
max_service_check_spread=10
service_interleave_factor=s
host_inter_check_delay_method=s
max_host_check_spread=5
max_concurrent_checks=0
check_result_reaper_frequency=2
max_check_result_reaper_time=20
max_check_result_file_age=3600
cached_host_check_horizon=60
cached_service_check_horizon=60
enable_predictive_host_dependency_checks=1
enable_predictive_service_dependency_checks=1
soft_state_dependencies=0
auto_reschedule_checks=0
sleep_time=0.00001
service_check_timeout=10
host_check_timeout=5
event_handler_timeout=10
notification_timeout=10
ocsp_timeout=2
perfdata_timeout=2
retain_state_information=1
retention_update_interval=60
use_retained_program_state=1
dump_retained_host_service_states_to_neb=0
use_retained_scheduling_info=1
retained_host_attribute_mask=0
retained_service_attribute_mask=0
retained_process_host_attribute_mask=0
retained_process_service_attribute_mask=0
retained_contact_host_attribute_mask=0
retained_contact_service_attribute_mask=0
interval_length=60
use_aggressive_host_checking=0
execute_service_checks=1
accept_passive_service_checks=1
execute_host_checks=1
accept_passive_host_checks=1
enable_notifications=1
enable_event_handlers=1
process_performance_data=0
allow_empty_hostgroup_assignment=0
obsess_over_services=0
obsess_over_hosts=0
translate_passive_host_checks=0
passive_host_checks_are_soft=0
check_for_orphaned_services=0
check_for_orphaned_hosts=0
service_check_timeout_state=u
check_service_freshness=1
service_freshness_check_interval=60
check_host_freshness=1
host_freshness_check_interval=60
additional_freshness_latency=600
enable_flap_detection=1
low_service_flap_threshold=10.0
high_service_flap_threshold=40.0
low_host_flap_threshold=5.0
high_host_flap_threshold=20.0
p1_file=/usr/lib/icinga/p1.pl
enable_embedded_perl=1
use_embedded_perl_implicitly=1
stalking_event_handlers_for_hosts=0
stalking_event_handlers_for_services=0
stalking_notifications_for_hosts=0
stalking_notifications_for_services=0
use_large_installation_tweaks=1
enable_environment_macros=0
free_child_process_memory=0
child_processes_fork_twice=0
event_profiling_enabled=0


Das problem besteht nach wie vor.
Worker_log:

Source code

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

[2012-08-07 18:00:42][2701][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:00:48][1968][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:00:54][1817][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:05:24][25169][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:05:30][25065][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:05:36][25163][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:05:42][24974][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:05:48][25304][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:05:54][25006][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:06:00][26314][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:10:24][14483][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:10:30][14400][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:10:36][14546][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:10:42][31580][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:10:48][14379][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:10:54][14425][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:11:00][15545][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:11:06][15880][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:15:30][1491][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:15:36][1522][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:15:42][18868][INFO ] timeout (5s) hit for hostcheck: 123
[2012-08-07 18:15:48][2246][INFO ] timeout (5s) hit for hostcheck: 123


Mein Host_check sieht zur Zeit so aus:

Source code

 
1

command_line	/usr/lib/nagios/plugins/check_ping -H '$HOSTADDRESS$' -w 5000,100% -c 5000,100% -p 1


keine Ahnung wieso er immer wieder checkt... auf der grossen kiste läuft mir durch die häufigen checks bei Timeout (Host und Service) total die queue voll... weil ja immer 5 oder 10sec timeout... das läppert sich ganz schön

pitchfork

Administrator

Posts: 18,440

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

Tuesday, August 7th 2012, 7:01pm

Also ich glaube ja nicht das man ein 60000 Services System so einfach analysieren kann.
Just my 2 cent
+++ PNP Developer +++ PNP 0.6.21 ist online ! +++
Hilfreiche Infos gefunden? Dann schnell ein paar Cent flattrn
OMD - Open Monitoring Distribution

noone123

Beginner

Posts: 31

Gender: male

Number of monitoring servers: 2

Nagios Version: icinga1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: +8k

Number of services: +80k

OS: debian

Plugin Version: 1.4.15-3

Other Addons: mod_gearman, livestatus

5

Tuesday, August 7th 2012, 7:21pm

das kleine system hat nur 6k service checks und ca 1,5k hosts.

Es ist ja normal, das Host-checks automatisch retried werden soweit ich weiss... Dazu gibs ja auch keine Einstellung.
Es verwundert mich nur das mal 3 retrys mal 5 da sind... und das troz alledem noch servicechecks ausgeführt werden.
Sollten nicht eigentlich servicechecks nicht ausgeführt werden, wenn hostchecks fehlschlagen?

Der host 123 ist z.b. im Hardstate ... alle services die er hat ebenfalls.
Aber es werden immernoch alle servicechecks normal gescheduled. Sollte nicht nur der hostcheck laufen und sobald er wieder up ist erst die servicechecks?

dnsmichi

Super Moderator

Posts: 5,986

Birthday: May 30th 1983 (29)

Gender: male

Location: Nürnberg

Occupation: Consultant / Developer beim besten Arbeitgeber der Welt @netways

Number of monitoring servers: Icinga: 4x dev, 10++ prod, Icinga2: 2x dev

Nagios Version: s/nagios/icinga/

Icinga Version: 1.9.1 / GIT

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: 1000+

Number of services: 15000+

OS: RHEL, Debian, SUSE

Plugin Version: 1.4.16

IDO-Version: 1.9.1 / GIT MySQL/Postgresql/Oracle

Other Addons: Icinga Web, PNP, check_multi, inGraph, EventDB, LConf

6

Tuesday, August 7th 2012, 8:36pm

ich wiederhole meine frage nach configs ... und entsprechenden logs, auch von icinga seite. ggf debug logs vom scheduler.
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

noone123

Beginner

Posts: 31

Gender: male

Number of monitoring servers: 2

Nagios Version: icinga1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: +8k

Number of services: +80k

OS: debian

Plugin Version: 1.4.15-3

Other Addons: mod_gearman, livestatus

7

Wednesday, August 8th 2012, 12:23pm

hi nochmal :D

bin gerade am debuggen... scheduler etc...
Hatte gehofft, dass es vielleicht nen "Trick 17" oder so gibt, oder das Problem bekannt ist :D

Nur noch mal so ne Verständnisfrage... alle jobs die in mod_gearman landen, müssen vom icinga scheduler kommen oder?
Mod_gearman interpretiert also keine ergebnisse und handelt dann eigentständig wie z.b. hostcheck ->timeout ->retry.. Das retry muss von icinga kommen oder sehe ich das falsch?

noone123

Beginner

Posts: 31

Gender: male

Number of monitoring servers: 2

Nagios Version: icinga1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: +8k

Number of services: +80k

OS: debian

Plugin Version: 1.4.15-3

Other Addons: mod_gearman, livestatus

8

Wednesday, August 8th 2012, 2:00pm

hmm... es scheint so als würde mein Problem irgendwie mit einem Plugin abbruch zusammenhängen...

z.b der servicecheck PING. Commando ist:

Source code

 
1

/usr/lib/nagios/plugins/check_ping -H 'xxx.xxx.xxx.xxx' -w 5000,100% -c 5000,100% -p 1


Der host ist nicht erreichbar.... und ich bekomme von mod_gearman folgenden Output:
"Return code of 130 is out of bounds. Plugin exited by signal SIGINT"

Das Problem besteht nicht bei allen hosts die nicht erreichbar sind.

Kann jemand mit dem output was anfangen?
Wenn ich den Ping check manuell ausführe, bekommt ich die richtigen exticodes...

Kann ich den check irgendwie manuell über den gearmanserver schicken, damit ich mal genau sehe was da passiert?

noone123

Beginner

Posts: 31

Gender: male

Number of monitoring servers: 2

Nagios Version: icinga1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: +8k

Number of services: +80k

OS: debian

Plugin Version: 1.4.15-3

Other Addons: mod_gearman, livestatus

9

Wednesday, August 8th 2012, 3:46pm

hier ie debugausgabe vom gearman_worker. Hab 1.3.4 und 1.3.6 probiert... bei beiden das gleiche

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
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95

[2012-08-08 15:33:13][15246][TRACE] get_job()
[2012-08-08 15:33:13][15246][TRACE] got new job H:icinga-test2:17
[2012-08-08 15:33:13][15246][TRACE] 344 +++>
ZhROr23lbWm6lKhdw61tW2AdXy89qd3ALUUWaoK/MtHkkQ4+Lsd9bsfo61h/QltE2Vs4+3ThTCdEQE45ZbYolyCuf8xsl3STnLnIFq2+PHscjOS2iFbLHKqPqZvfW09OJjguAIinusi2KD9p9Q+tm3w2BOcYu85gqVEXxMkA4WE6jVEHbXMYRTSShY2yDhd9tzRpOT3olhqarMt055bmI8jLYYKBC5EA8h2MY7K/Jgnalj3dR8/9423elS2tibpkWGwuyh+yNtSeY1y4Cpi2H42eCPj5lzBeKYwbiRruzhfUrgqv64nQrcEW7Io0RPm0OkyOWzrK3dWabbkl3rc4cA==
<+++
[2012-08-08 15:33:13][15246][TRACE] 240 --->
type=host
result_queue=check_results
host_name=testhost
start_time=1344432793.0
next_check=1344432793.0
timeout=5
core_time=1344432793.174068
command_line=/usr/lib/nagios/plugins/check_ping -H 'xx.xx.xx.xx' -w 5000,100% -c 5000,100% -p 1



<---
[2012-08-08 15:33:13][15246][TRACE] do_exec_job()
[2012-08-08 15:33:13][15246][DEBUG] got host job: testhost
[2012-08-08 15:33:13][15246][TRACE] timeout: 5, core latency: 0
[2012-08-08 15:33:13][15246][TRACE] command: /usr/lib/nagios/plugins/check_ping -H 'xx.xx.xx.xx' -w 5000,100% -c 5000,100% -p 1
[2012-08-08 15:33:13][15246][TRACE] execute_safe_command()
[2012-08-08 15:33:13][15246][TRACE] using popen, found shell characters
[2012-08-08 15:33:18][15246][TRACE] check_alarm_handler(14)
[2012-08-08 15:33:18][15246][INFO ] timeout (5s) hit for hostcheck: testhost
[2012-08-08 15:33:18][15246][TRACE] send_timeout_result()
[2012-08-08 15:33:18][15246][TRACE] send_result_back()
[2012-08-08 15:33:18][15246][TRACE] queue: check_results
[2012-08-08 15:33:18][15246][TRACE] data:
host_name=testhost
core_start_time=1344432793.0
start_time=1344432793.174901
finish_time=1344432798.175154
return_code=3
exited_ok=1
output=(Host Check Timed Out On Worker: icinga-test2)





[2012-08-08 15:33:18][15246][TRACE] add_job_to_queue(check_results, (null), 2, 1, 1, 1)
[2012-08-08 15:33:18][15246][TRACE] 192 --->host_name=testhost
core_start_time=1344432793.0
start_time=1344432793.174901
finish_time=1344432798.175154
return_code=3
exited_ok=1
output=(Host Check Timed Out On Worker: icinga-test2)




<---
[2012-08-08 15:33:18][15246][TRACE] 280 +++>
JD4wsRgaoqoszVsKOGFHyZ3VDGs0/PyELbwU/PrKXN0grn/MbJd0k5y5yBatvjx7dlJioc6lCgFU8qnYiZtEleLETRuhffMQF7gEs76Xc/F0qjANW6nimLkr5u50xSXJFFhwh6io2sA3GNn8KkN2IWz42ifmy73Vg1mgGf2MjfrKAuQG5UgZfszVbdczXyAZqfUYvYkhXcSO4yjnrjFpllTngi2hM5VY2gnTyr6HZ71BchhkQduyL28t35wq3yKnOkyOWzrK3dWabbkl3rc4cA==
<+++
[2012-08-08 15:33:18][15246][TRACE] add_job_to_queue() finished successfully: 0 0
[2012-08-08 15:33:18][15246][TRACE] send_result_back() finished successfully
[2012-08-08 15:33:18][15246][TRACE] send_result_back() has no duplicate servers to send to.
[2012-08-08 15:33:18][15246][TRACE] send SIGINT to 15246
[2012-08-08 15:33:18][15246][TRACE] send_result_back()
[2012-08-08 15:33:18][15246][TRACE] queue: check_results
[2012-08-08 15:33:18][15246][TRACE] data:
host_name=testhost
core_start_time=1344432793.0
start_time=1344432793.174901
finish_time=1344432798.176812
return_code=2
exited_ok=1
output=CRITICAL: Return code of 130 is out of bounds. Plugin exited by signal SIGINT. (worker: icinga-test2)\n




[2012-08-08 15:33:18][15246][TRACE] add_job_to_queue(check_results, (null), 2, 1, 1, 1)
[2012-08-08 15:33:18][15246][TRACE] 248 --->host_name=testhost
core_start_time=1344432793.0
start_time=1344432793.174901
finish_time=1344432798.176812
return_code=2
exited_ok=1
output=CRITICAL: Return code of 130 is out of bounds. Plugin exited by signal SIGINT. (worker: icinga-test2)\n



<---
[2012-08-08 15:33:18][15246][TRACE] 344 +++>
JD4wsRgaoqoszVsKOGFHyZ3VDGs0/PyELbwU/PrKXN0grn/MbJd0k5y5yBatvjx7dlJioc6lCgFU8qnYiZtEleLETRuhffMQF7gEs76Xc/F0qjANW6nimLkr5u50xSXJqh5bYbv/Sz5Mzji9ByJQErEH7SaJc88RY92SVVSMvvBKhPX66ny+Yt5u48DgOw9nJffh6Q9EjMQyUqBP8Y26wVTTVMMIh8LQbNNaJ7XFw786cooLKrMKrXZ7r9PTSPvXSjeMEmF90A+fbvFC7w4Noj6MSKNciFc/J027sv/GefbftxJqp2CEazEszRQ//0BSXdZfEklVZMTT8uU7agkyHg==
<+++
[2012-08-08 15:33:18][15246][TRACE] add_job_to_queue() finished successfully: 0 0
[2012-08-08 15:33:18][15246][TRACE] send_result_back() finished successfully
[2012-08-08 15:33:18][15246][TRACE] send_result_back() has no duplicate servers to send to.
[2012-08-08 15:33:18][15246][TRACE] set_state(1)

noone123

Beginner

Posts: 31

Gender: male

Number of monitoring servers: 2

Nagios Version: icinga1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: +8k

Number of services: +80k

OS: debian

Plugin Version: 1.4.15-3

Other Addons: mod_gearman, livestatus

10

Wednesday, August 8th 2012, 7:58pm

for all who have the same trouble with checks that duplicated until mod_gearman queue is full.

In my case the service_interleave_factor in icinga.cfg makes the trouble.
So make sure to set this to 1.

Haven't found a solution to prevent the error_code 130 from check_ping if not reachable or timeout... will wirte if i find something.

sni

Professional

Posts: 1,298

Gender: male

Location: München

Number of monitoring servers:

Nagios Version: 2.* / 3

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts:

Number of services:

OS:

Plugin Version:

Other Addons: Thruk, ModGearman

11

Wednesday, August 8th 2012, 9:44pm

Ein Problem ist vermutlich, dass check_ping per default einen 10sec timeout hat, deine hostchecks aber nur 5. D.h. mod_gearman muss nach 5 sec das plugin killen welches sich eigentlich besser selbst beenden sollte. Die Checks selbst sind vermutlich on-demand-host checks. Aber Details weiß nur das logfile.
--
Thruk - Monitoring Webinterface - Mod Gearman - Münchner Stammtisch - Consol* Labs

noone123

Beginner

Posts: 31

Gender: male

Number of monitoring servers: 2

Nagios Version: icinga1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: +8k

Number of services: +80k

OS: debian

Plugin Version: 1.4.15-3

Other Addons: mod_gearman, livestatus

12

Thursday, August 9th 2012, 1:01pm

ok... bin der sache mal ein bischen näher auf den grund gegangen.

Das problem betrifft nur plugins, deren Status anhand von performance daten festgelegt wird.
z.b. check_ping, check_http

Is ja auch eigentlich klar... denke mal nagios/icigna haben für diese plugins spezielle timeout regeln im code oder so.

Mod gearman könnte ja nun eigentlich den timeout_return code zurückgeben... allerdings ist das ja bei pings, http nicht erwünscht... besonders nicht wenn man einen timout als unknown behandelt.

Lösung ist also bei checks, deren status anhand von performancedaten ermittelt wird, den timeout innerhalb des checks zu setzen, so dass mod_gearman diesen nie abbrechen muss.

Dabei verhält sich check_ping ein bischen merkwürdig... wenn man die rta werte gleichgross wie den timeout setzt, brauch der ping 1sec länger und wirft wieder den returncode 130
Hier mal ein beispiel:

Source code

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14

time ./check_ping -H xx.xx.xx.xx -w 5000,100% -c 5000,100% -p 1 -t 5
PING CRITICAL - Packet loss = 100%|rta=5000.000000ms;5000.000000;5000.000000;0.000000 pl=100%;100;100;0

real	0m6.003s
user	0m0.004s
sys	0m0.000s


time ./check_ping -H xx.xx.xx.xx -w 4999,100% -c 4999,100% -p 1 -t 5
PING CRITICAL - Packet loss = 100%|rta=4999.000000ms;4999.000000;4999.000000;0.000000 pl=100%;100;100;0

real	0m5.003s
user	0m0.004s
sys	0m0.000s


Ich habe es jetzt einfach mit 4999ms als rta gelöst
Selbiges gilt für check_htttp.

Ich bin mir jetzt aber immernoch nicht sicher ob das ein feature ist (damit man nicht hostchecks z.b. als unknown ausweist), oder irgendwie ein bug.
Bei checks wie nrpe sollte man bei dem ganzen timeout eingestelle darauf achten, das diese per default nach 10sec nen timeout schmeissen, und mod_gearman dieses als critical interpretiert.
Um das zu verhindern, kann man sein check_nrpe commando einfach mit -t x auf eine zeitspanne grösser als die service_timout spanne im der icinga.cfg setzen.

This post has been edited 2 times, last edit by "noone123" (Aug 9th 2012, 4:29pm)

sni

Professional

Posts: 1,298

Gender: male

Location: München

Number of monitoring servers:

Nagios Version: 2.* / 3

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts:

Number of services:

OS:

Plugin Version:

Other Addons: Thruk, ModGearman

13

Thursday, August 9th 2012, 9:28pm

Alle Plugins sollten sich selbst beenden und selbst einen Timeout setzen. Der Timeout sollte logischerweise kleiner sein, als der globale Timeout der nagios.cfg.
Dass Nagios oder Mod-Gearman das Plugin irgendwann abschießt ist nur der Notnagel. Wenn das der Fall ist, sollte eigentlich eine Meldung
ala "(Service Check Timed Out On Worker: ...)" angezeigt werden. Wenn das nicht der Fall ist,
wäre das ein Bug in Mod-Gearman. Letzlich würde sich aber nur die Meldung ändern, das Verhalten wäre das gleiche.
Welchen Status ein Timeout Ergebniss haben soll, kann man beim Worker über 'timeout_return=' einstellen.
--
Thruk - Monitoring Webinterface - Mod Gearman - Münchner Stammtisch - Consol* Labs

noone123

Beginner

Posts: 31

Gender: male

Number of monitoring servers: 2

Nagios Version: icinga1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: +8k

Number of services: +80k

OS: debian

Plugin Version: 1.4.15-3

Other Addons: mod_gearman, livestatus

14

Tuesday, August 14th 2012, 12:31pm

danke für eure antworten :D

mod_gearman schmeisst immer einen "Return code of 130 is out of bounds. Plugin exited by signal SIGINT" wenn folgendes gilt:
1. mod_gearman killt den prozess wegen des globalen timeouts
2. der check benötigt performance_daten um den aktuellen state festzulegen (z.b. check_ping, check_http)


ich hab jetzt mal so weit wie möglich timeouts innerhalb des check_commands definiert, die natürlich unterhalb des globalen timeouts von icinga liegen.

z.b. mein Hostcheck_command (host_check_timout = 6 in der icinga.cfg)

Source code

 
1

check_ping -H xx.xx.xx.xx -w 4999,100% -c 4999,100% -p 1 -t 5


Das scheint soweis auch ganz gut zu funktionieren... allerdings sehe ich ab und an im mod_gearman_worker_log

Source code

 
1

timeout (6s) hit for hostcheck: TESTHOST


Eine Grundlegende Frage hätte ich noch zu Mod_gearman.

Wenn ein check einen Timeout wirft (mod_gearman terminiert den check), macht mod_gearman dann automatisch den retry_check, sofern ein retry_check_intervall angegeben ist, oder muss der retry von icinga gescheduled werden?

Ich habe nämlich immernoch das Problem das ein check (noch keinen timeout im check_command) immer wieder dupliziert wird, bis er irgendwann 25 mal zur gleichen Zeit ausgeführt werden soll...
Vielleicht liegt das PRoblem ja darin, das mod_gearman icinga erst nach z.b. 11.5sec sagt "timeout" aber icinga schon nach 11sec den check neu gescheduled hat. Wenn mod_gearman dann das ergebnis liefert, scheduled icinga den nochmal... und das ganze wiederholt sich dann bis die queue voll ist.... im log sieht das fast so aus.

Ist leider nicht so einfach zu debuggen, da das Problem nicht immer auftritt... sondern eher zufällig irgendwann und dann killt es die queue.
Hab nicht so viel plattenplatz um den scheduler debug von icinga tagelang mitlaufen zu lassen, werde das aber mal auf nem testsystem checken.

Wenn jemand vielleicht schon nen idee hat, wäre ich dankbar :D

noone123

Beginner

Posts: 31

Gender: male

Number of monitoring servers: 2

Nagios Version: icinga1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: +8k

Number of services: +80k

OS: debian

Plugin Version: 1.4.15-3

Other Addons: mod_gearman, livestatus

15

Tuesday, August 14th 2012, 4:33pm

nach langem debuggen glaube ich das problem gefunden zu haben.

Das problem scheint auf seite von mod_gearman zu liegen.

Versuchsaufbau:
check_http auf host, der nicht innerhalb des globalen timeouts antwortet.
return_timeout in der mod_gearman_worker.cfg ist auf 3

Ablauf nach initialem startup ohne retained infos:

T=0:
Icinga: Schduled den servicecheck
Gearman_neb: Fängt check ab und gibt an worker weiter
Gearman_worker: führt den check aus und hier ist das erste problem:

der worker sendet 2 verschiedene check_results
1. Service Check Timed Out On Worker: icinga-test2 mit returncode: 3 (dieses ist eigentlich das richtige result)
2. Return code of 130 is out of bounds. Plugin exited by signal SIGINT. (worker: icinga-test2) mit returncode: 2 (return_code 130 schmeisst der servicecheck, wenn er gekillt wird)

T=1
- Icinga erhält nun zuerst den returncode 3, merkt das der state sich verändert hat und rescheduled je nach retry_intervall den check sofort.
- Sofort danach erhält icinga das 2te checkresult mit dem returncode 2 ( Plugin exited by signal SIGINT. (worker: icinga-test2)).
- jetzt merkt icinga, das sich der state wieder verändert hat, und rescheduled den check nochmal....

Es sind nun also 2 check_http innerhalb von 1-2 sec gescheduled worden, die beide wieder jeweils einen returncode von 2 und einen returncode von 3 zurückgeben.
Das führt dann dazu, das icinga im nächsten anlauf gleich 4 checks in 1 sec rescheduled und so weiter...
da alle checks einen timeout werfen, also z.b. min 10sec laufen, wird die queue immer voller und voller.

Dieses verhalten tritt bei allen checks auf, die einen anderen exitcode als 0-3 werfen wenn sie gekillt werden.

sni

Professional

Posts: 1,298

Gender: male

Location: München

Number of monitoring servers:

Nagios Version: 2.* / 3

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts:

Number of services:

OS:

Plugin Version:

Other Addons: Thruk, ModGearman

16

Tuesday, August 14th 2012, 10:36pm

Ich hab eben einen Fix eingecheckt: https://github.com/sni/mod_gearman/commi…7b441a7ecbbca7b
Du könntest morgen bitte mal den daily snapshot probieren: http://mod-gearman.org/daily/
--
Thruk - Monitoring Webinterface - Mod Gearman - Münchner Stammtisch - Consol* Labs

noone123

Beginner

Posts: 31

Gender: male

Number of monitoring servers: 2

Nagios Version: icinga1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: +8k

Number of services: +80k

OS: debian

Plugin Version: 1.4.15-3

Other Addons: mod_gearman, livestatus

17

Wednesday, August 15th 2012, 8:17am

super, vielen dank :D

werde heute leider nicht dazu kommen den fix zu probieren.
Morgen hab ich aber zeit und werde dir sofort berichten ob es läuft :D

noone123

Beginner

Posts: 31

Gender: male

Number of monitoring servers: 2

Nagios Version: icinga1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: +8k

Number of services: +80k

OS: debian

Plugin Version: 1.4.15-3

Other Addons: mod_gearman, livestatus

18

Thursday, August 16th 2012, 3:22pm

hab eben den daily_build mod_gearman-1.3.7_beta_20120815 getestet.
Das Problem scheint behoben.
Der worker schmeisst jetzt nur noch den timeout mit richtigem returncode in die resultqueue.

Werde deinen fix mal in die stable 1.3.6 version schmeissen und auf nem kleineren production system laufen lassen bis 1.3.7 stable ist

1000 dank für deine Hilfe :D

sni

Professional

Posts: 1,298

Gender: male

Location: München

Number of monitoring servers:

Nagios Version: 2.* / 3

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts:

Number of services:

OS:

Plugin Version:

Other Addons: Thruk, ModGearman

19

Thursday, August 16th 2012, 10:55pm

1.3.7 wird nie released, das ist immer die test version. Nächstes Release wird die 1.3.8, die kommt irgendwann nächste Woche wenn ich aus dem Urlaub zurück bin.
--
Thruk - Monitoring Webinterface - Mod Gearman - Münchner Stammtisch - Consol* Labs

Similar threads