Open Stack

> > 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/
> >