> > 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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to