Nagios restart mucks with service check schedu le

[Tedman Eng]

Recalculate your nagios.cfg file setting for service inter-check-delay.
Don't use the 's'mart setting in this case.  To accomodate the heavy 1st
minute, you may need to adjust other related values such as max_concurrent,
etc.

Your new formula:
Take 1 minute divide by # services, use result as your inter-check-delay.

Refer to docs for more information about service check scheduling theory.
http://nagios.sourceforge.net/docs/1_0/checkscheduling.html#inter_check_dela
y

Example:
10 services
inter_check_delay = 6 sec
(all checks will complete within first minute.  After that, each uses its
defined interval in  rescheduling)


Caveats:
While your startup is now finishing in time, your service checks will be
"clumped", so this may have adverse affects on resources such as monitored
devices, network load, etc.  The "clump" will  slowly become spread out in
random fashion over time until the next restart.



-----Original Message-----
From: Robert Nelson [mailto:rnelson at windchannel.com]
Sent: Monday, November 01, 2004 11:19 AM
To: nagios-users at lists.sourceforge.net
Subject: [Nagios-users] Nagios restart mucks with service check schedule


Hey,

I'm using Nagios v1.2 and running into a bit of a problem with
scheduling. My template specifies 5 minutes for normal checks, and in
select definitions I've been setting it to 1 minute. Doesn't seem to be
taking that into account on a reload/reschedule, however.

I've got the following services template in use:

# Standard service definition, with standard check options
define service{
	name				standard-service
	active_checks_enabled		1
	passive_checks_enabled		1
	parallelize_check		1
	obsess_over_service		1
	check_freshness			0
	notifications_enabled		1
	event_handler_enabled		1
	flap_detection_enabled		1
	process_perf_data		0
	retain_status_information	1
	retain_nonstatus_information	1
	is_volatile		0
	check_period		24x7
	max_check_attempts	3
	normal_check_interval	5
	retry_check_interval	3
	notification_interval	480
	notification_period	24x7
	notification_options	w,u,c,r
	register			0	}

I then have the following service:

define service{
	use			standard-service
	host_name		westst_cr1.windchannel.com
	service_description	Serial3/0
	contact_groups		router-admins
	check_command		check_iftraffic!Serial3/0
	process_perf_data	1
	normal_check_interval	1
	}




After restarting nagios (service nagios reload), Nagios reschedules
service checks. For someone reason, this check (and others like it) get
scheduled for up to 5 minutes later, depending on where they fall in the
semi-random scheduling. After that first check is processed, the next
check is scheduled for 1 minute later. Normally I wouldn't worry about
it, but I'm processing performance data on this service too.

Is there any known issue with service check scheduling I should be aware
of, or a way around it?

Rob Nelson
Network Engineer
Windchannel Communications
919-538-6326 


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id065&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue. 
::: Messages without supporting info will risk being sent to /dev/null


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null