We have a bunch of McAffee Web Gateways. Each Gateway has two IP addresses (plus the VIP). One IP is for the Listener interface, TCP 8080 and on the other port the management interface with SNMP, SSH, HTTPS-4712 is running. We want only one Host Object in Monitoring.
At the host object we can add additional IP addresses and its mentioned in the online help:
“These can be used in some active checks like ICMP.”
What we are missing is the macro name we can use at these “active checks” and what from the various active checks are supporting this?
In the nagios plugin configuartion the following list is mentioned:
$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
Unfortunately not the additional IPs.
Does anyone has complete list of available Macros and in what check plugins are these Macros supported?
The ping check has an explicit rule option “Alternative address to ping”. I guess that’s what the inline help is referring to (not a macro, I’m afraid).
You probably need to set up those http checks manually, one for each address.
Thats a nightmare, not practicable and prone to fail. Sorry but we cannot work like that. Its back to ancient times with nagios templates. Furthermore we push host configuration from CMDB automatically.
Maybe you can use custom variables in the active checks. These variables could be filled manually or automatically with the IPs from the CMDB.
You can then define a check for each gateway with the appropriate custom variable. After that you only need to assign this set of 2,3 checks to all your McAffee gateways.
Yes, I thought about that also. Need to think about the consequence’s.
Anyway I am interested to find a way to show all available macros because its worth to have it.
I tried the ICMP config. At least it tells me the macro name.
But for me its not working if I am not totally wrong.
Can one confirm its a bug in 2.0.0p31?
After poking around I found out that at least $_HOSTADDRESSES_4$ is usable accross ICMP, HTTP and TCP checks.
The difficulty is if more than 1 additional IPs added it builds a list whihc will fail the check:
MyHost;HTTP apache web page;check_mk_active-http!'-u' '/beta' '--sni' '10.20.30.40 127.0.0.1'
Are you sure the index for the first additional address is “0”? When I create a new rule, it offers me index “1” by default. (haven’t tried if this works since I do not use additional addresses)
I passed idea along, as it looks like something great to have, but potentially rather complex to implement. So promises here, I am merely the messenger.
Someone from the docs team here: I’ve got a ticket on documenting macros across the Official User Guide as well as one on rewriting the article on Developing Your Own Check Plugins. Given limited resources, guess which one I’d prefer to do.
Let me explain my motivations: Macros are prone to errors, especially regarding escaping and thus pose some risk to attacks. Next is that check_http is an executable, thus every time it is called, a process is spawn. Last is that check_http is taken vanilla from monitoringplugins.org to maintain Nagios compatibility. This also means bug and limitation compatibility. And there are plenty of bugs and limitations…
Personally I would recommend that, if you run into trouble with check_http, write a Checkmk check plugin that does your task and nothing more. Depending on your setup this might be a “special agent plugin”.
Going back to the initial task, that is to check if the web interface on the secondary IP address answers in time, this check would just be iterating over IP addresses and returning a positive result, if exactly one IP address provides the management interface and answers in time. This wouldn’t even need GUI components, a single check plugin should be sufficient.
This is the wrong approach for active checks. Macros for active checks are a key component you need for all checks you need to do like HTTP/SMTP/NTP/FTP and so on.
Special Agents for problems that are already solved is like inventing the wheel again.
I Do not fully agree. Especially with the example of check_http: The functionality of this check has been extended over the years, resulting in a command line interface that gets harder to map to GUI with each change. Plus there a re bugs like string search: If the string you look for is contained across the border of chunked output, it is not found. There are also various bugs when a proxy should be used.
We could either fork check_http, to like check_http_ng, fixing bugs, cleaning up, breaking compatibility and still have the limitations of an active check.
In case of monitoring devices like web gateways with a full embedded operating system, one might also move to monitoring the firmware version in not so distant future or a REST API might provide better and more performant information than SNMP. In this case an active check is needed anyway. So why not start now?
Going back to the problem in post 11 with the list:
A quick fix might be not calling check_http directly, but creating a wrapper (shell script should be enough) that iterates over the list items, calling check_http for each IP address and then return the output for the IP with the web interface. But I would consider this a hack that is not much quicker to implement than a special agent.
Nice, if you have the time and patience to tinker around with that why not but my time and my resources are limited, so have I to use what is available.
Sorry, at this point I do not see a better fix than either a wrapper or a rather simple special agent. Sure, extending active checks to iterate over all IPs and then either return, best, worst or failover (only one must be OK) would be appreciated by many users, but (I guess) less by our developers. Still, if you prefer such a solution in the long term you might propose it in the features portal: https://features.checkmk.com/
I guess there is a misunderstanding.
Basically there is a bug in checmk because the macros $_HOSTADDRESSES_4_0$, $_HOSTADDRESSES_4_1$ and so on are not available even that at least the check Ping is using it.
