Open Stack

Or have a check-mk.d directory and pull stuff on from there automatically
On 30 Apr 2014 04:03, "Gregory Haynes" <greg at greghaynes.net> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140430/48b3aa66/attachment.html>