Thanks for your reply Lars.

As I understand it, we have no way of kicking a service check into existence 
without adding it in the config and reloading nagios (which in turn causes the 
initial state to be logged).
The same applies for removing a service check I assume.
I was looking at the external commands that can be sent to nagios here: 
http://www.nagios.org/developerinfo/externalcommands/
I thought I might use 
DISABLE_PASSIVE_SVC_CHECKS;<host_name>;<service_description> to exclude a 
service from the monitoring (for example a disk or VM that is gone and doesn't 
need monitoring anymore), until nagios needs to be reloaded for something else 
to avoid a reload. I did some tests with this command, but I'm not sure what 
exactly it does?

My goal is to keep the number of reloads or restart needed to a minimum as it 
might impact SLA reporting performance via mk-livestatus.
Is this potentially a problem in environments with lots of services (+/-10k) 
where lots of reloads are done? What is the groups experience with this? 

On second thought, it might be better to combine monitoring of dynamic 
resources in a few custom service checks that combine stuff based on resource 
type.
For example a check combining the status of all VMs on a compute node, where 
the check status is updated to critical when a VM on the node is having issues.
So in this way, we move some of the intelligence to the check to avoid adding 
and removing services all the time.

all feedback is appreciated :)

Regards,
Michael Van Wesenbeeck

On 22 Jan 2013, at 20:16, [email protected] wrote:

> 
> Date: Tue, 22 Jan 2013 11:36:42 +0100
> From: Lars Michelsen <[email protected]>
> To: [email protected]
> Subject: Re: [omd-users] log_initial_states impact in a dynamic
>       monitoring environment
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hi Michael,
> 
> there are two options for us: restarting or reloading the nagios 
> process. But there are no differences related to the initial states 
> logging. Seems we have  no real chance to change this behavior.
> 
> Regards
> Lars
> 



<<inline: Oxopia_small.jpg>>

Oxopia NV
Michael Van Wesenbeeck
Consultant

M +32 (0)489 84 64 91 | [email protected]
--
IMPORTANT NOTICE : This email (including any attachments) is confidential, may 
be legally privileged and is for the intended recipient only. Please notify the 
sender by return email and delete this message from your system, if you have 
received it by mistake. Any unauthorized use or dissemination of this message 
in whole or in part is strictly prohibited and may be a criminal offence. 
Please note that the sender nor his/her employer accepts any responsibility for 
viruses. It is your responsibility to scan the email and attachments (if any).

_______________________________________________
omd-users mailing list
[email protected]
http://lists.mathias-kettner.de/mailman/listinfo/omd-users

Reply via email to