Or have a check-mk.d directory and pull stuff on from there automatically On 30 Apr 2014 04:03, "Gregory Haynes" <[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] > 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
