Thanks all for the comments and I’m glad you agree with one of the proposed 
approaches! ☺

I’ll take a look at using an env var first and then look at a check_mk.d style 
directory if I get a chance later on.

Thanks again,

Matt

From: Robert Collins [mailto:[email protected]]
Sent: 29 April 2014 23:04
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [tripleo] Location of Monitoring Checks


Or have a check-mk.d directory and pull stuff on from there automatically
On 30 Apr 2014 04:03, "Gregory Haynes" 
<[email protected]<mailto:[email protected]>> wrote:
> > Hi all,
> >
> > I have a patch in flight at the moment [0] to install check_mk server and 
> > compliment the already merged installation of check_mk agent [1] so my 
> > thoughts are now turning to how we would recommend adding new service 
> > checks.
> >
> > The concept behind check_mk makes this really simple to do.  You just place 
> > a script that outputs "<status_code> <check_name> <performance_data> 
> > <message>" into the agent's "local" directory 
> > (/usr/lib/check_mk_agent/local on Ubuntu for example) and it will be picked 
> > up the next time an inventory of the system is run.
> >
> > There are two ways that we can recommend doing this:
> >
> > 1) We ask users to update the check_mk_agent T-I-E every time they wish to 
> > add a new check
> > 2) We ask users to distribute checks from their own T-I-E into the correct 
> > location
> >
> > In my opinion, requiring an update to check_mk_agent for every new check is 
> > the wrong way of doing this as it means that all systems get all checks 
> > regardless of function.  Far more preferable would be option 2, however I'm 
> > open to other ideas, especially if they mean that organisations using this 
> > don't have to go through the review process if they have checks they wish 
> > to keep "behind the firewall" for IP/Licensing reasons.
>
> Agreed.  Option 2 sounds like the only way to go here.  Adding
> instructions on how and where to add a check to the README file and
> maybe having a sample check element that users can look at for reference
> should be sufficient, I would think.
>

++ This is a common pattern in many of the elements. Additionally, It
might be worth exporting a variable in check_mk's environment.d for
other elements to use as the agent local directory if this path isnt
entirely consistent across distros.

> >
> > Thanks in advance for any help people can give on this,
> >
> > Matt
> >
> > [0] https://review.openstack.org/#/c/87226/
> > [1] https://review.openstack.org/#/c/81485/
> >

_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to