$HOSTNAME$ in commands? (Was: Re: Monitoring a matrix of load-balanced VirtualHosts?)

[JB Segal]

On 8/30/05, Chris Wilson <chris at aidworld.org> wrote:
> 
> Hi JB,
> 
> > As Chris Wilson noted, hostgroups do the right thing in 1.2... but I
> > really have no idea how I'd make the right host entries for a series
> > of VirtualHosts.
> 
> define service {
> use vhost-service
> service_description www.bar.com <http://www.bar.com>
> check_command my_check_http!www.bar.com
> hostgroup_name bar_com_servers
> }
> 
> define command {
> command_name my_check_http
> command_line $USER1$/check_http -I $HOSTADDRESS$ -H $ARG1$
> }
> 
> This will call check_http with the host address (hostname) of each
> server in the group "bar_com_servers". I've used a template,
> vhost-service, to inherit the check interval and notification options
> (not shown here).
> 
> > But if I'm trying to check the website "www.bar.com <http://www.bar.com>" 
> on the host
> > "a.foo.com <http://a.foo.com>", the -u is not, as near as I can tell, 
> optional, no?
> 
> As long as www.bar.com <http://www.bar.com> actually has a "/" page (it 
> doens't return an
> error or a redirect code).
> 
> Hope this helps,


It absolutely has. Thank you. (Especially: Thanks for prompting me to dig 
more into cfg recursion. I've been able to clean up things even more.)

Now comes the final part of this particular task:

I've been told to check '{machinename}.foo.com', but - according to 
docs/macros.html - I can't use $HOSTNAME$ or $HOSTALIAS$ in either host or 
service checks.

My 1st instinct is to do just that - something like
check_command check_lb_vhost!$HOSTNAME$.foo.com

but it seems I can't. This is more than a bit annoying, and seems a very odd 
design decision. I can't be the only one who wants this functionality.

Cheers, Chris.
> --
> (aidworld) chris wilson | chief engineer (chris at aidworld.org)
> 
> 
Thanks again,
JB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20050830/9a0ea182/attachment.html>