Doh! Sorry about the mail footer in my previous mail. Begin forwarded message:
> From: Michael Van Wesenbeeck <[email protected]> > Date: 23 Jan 2013 12:13:43 GMT+01:00 > To: [email protected] > Subject: Re: [omd-users] omd-users Digest, Vol 23, Issue 4 > > 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 >>
_______________________________________________ omd-users mailing list [email protected] http://lists.mathias-kettner.de/mailman/listinfo/omd-users
