Version 2.2.0p9
Please enter the complete shell command including path name and arguments to execute. If the plugin you like to execute is located in either ~/local/lib/nagios/plugins or ~/lib/nagios/plugins within your site directory, you can strip the path name and just configure the plugin file name as command check_foobar. You can use monitoring macros here. The most important are:
$HOSTADDRESS$: The IP address of the host
$HOSTNAME$: The name of the host
$_HOSTTAGS$: List of host tags
$_HOSTADDRESS_4$: The IPv4 address of the host
$_HOSTADDRESS_6$: The IPv6 address of the host
$_HOSTADDRESS_FAMILY$: The primary address family of the host
**All custom attributes defined for the host are available as $_HOST[VARNAME]$. Replace [VARNAME] with the upper case name of your variable. For example, a host attribute named foo with the value bar would result in the macro $_HOSTFOO$ being replaced with bar**
(I wrote a post about this a while ago already but noone responded - it also included a false observation because tag-based variables are not actually resolving, the non-resolution just didn’t actually make a difference in the context I tried it in because the particular parameter I tested it on turns out to be effectively optional)
The predefined variables like $HOSTNAME$ work. However, when trying to use the $_HOSTVARNAME$ variant, it just doesn’t.
Both for Tags and Custom Host Attributes, the expression $_HOSTVARNAME$ only ever seems to resolve to a $ character - never the value assigned to it. This is the same whether the variable exists or not.
This applies to using both Tags (which look to me like they have issues with some special characters) and Custom Host Attributes.
The in-GUI documentation above says just “Custom Attributes”, I found that’s a CHA topic, tried using that instead of a custom topic, doesn’t make a difference. The only post looking pretty similar I managed to find (but just going for $HOSTNAME$ which I don’t actually have an issue with) said to use single quotes, this just causes the variable string to just be taken literally without an attempt at resolution though.
I don’t get it. Even if my CHA name is short, all-uppercase and not having underscores like FOO → $_HOSTFOO$ (although I’d rather have some separators in it if possible…), it still resolves to the f$cking $ sign. Not to “bar” or whatever the content or anything. Either this piece of documentation is seriously misleading, or simply not true? 
According to this, it should be possible to define variables in [omd root]/etc/nagios/resource.cfg, but this does not provide a host-to-variable-content mapping.
There is this 2 year old post which actually does use a CHA, but it advises for a syntax that I’ve already tried (still doesn’t work if I retry) - the single quotes which for me just lead to the variable not being resolved and staying as $_HOSTVARNAME$ (instead of just $… or its actual content) @skomo83 , is your setup still working that way in the current version if still around?
Does anyone know about this?
I’ve tried so many syntax variants and I’m seriously out of ideas how to get this variable resolution to actually work. (instead of resorting to the really ugly and hard to maintain workaround of manually defining every possible combination as a unique service)
