Hello,
today I tried to follow the docs to monitor my internet connection with ping all ip addresses but I only got
check_icmp: Failed to resolve $HOST_ADDRESSES_4$: Name or service not known
I saw an old topic with 1.6 with the same issue and now I have it with 2.0.0p4. Did I miss something or is it still broken?
If I didn’t miss anything I followed Best practices, tips & tricks this guide.
Maybe someone knows what I missed.
Thank you.
Hello @marass,
i just tried to recreate the issue on my site and got the same result as you.
The problem seems to be with the commandline that is being built when you configure the check to use multiple ip-addresses. The commandline is built with $HOST_ADDRESS_4, which should be resolved to the configured IP-address. This variable (or macro, as it is caled in the nagios world) however does not exist. The correct one, as i see it, would be _HOSTADDRESS_4.
If you need a quick fix and don’t mind using the commandline, you can try the following:
It is basically the same @mjorgensen described in the other forum-post related to this problem: Issues with pinging multiple IPv4 Addresses - #9 by mjorgensen
I tweaked his solution a little bit so you don’t have to mess around in the /opt/omd/version/-directory and we make use of the local-hierarchy.
check_icmp-check to the local-hierarchy:# as the site-user
cp share/check_mk/checks/check_icmp local/share/check_mk/checks/
......
41 elif target == "all_ipv4addresses":
42 args += ["$_HOSTADDRESSES_4$", "$_HOSTADDRESS_4$"]
......
After that, execute cmk -R and the check should work after that.
There are a couple more occurences in this file where this is an issue, e.g. with the macros regarding IPv6-addresses, so the gist would be, everywhere where you see $HOST_ you could replace it with $_HOST
As @mjorgensen also said in his post, this unfortunately breaks the graphs for this check. I don’t have a quick solution for that right now as this seems to be a problem with the performance-data that is returned in a different format when multiple addresses are being processed by the check.
Hope that helps!
Cheers,
Lorenz
Hi @lkoenig
thanks for your response. I was confused why it was not working when it is a best practice that’s why I first asked here if others had the same problem.
I’ll try the workaround later and will check if it works for HOSTADDRESS_6 too.
Cheers
Marcus
It seems the problem with $HOST_ADDRESSES_4 is only present in the RAW-edition. I just tested it with the Free-edition (which is basically the enterprise one with the CMC) and the check works out of the box there. So the CMC apparently knows how to resolve that macro, the Nagios-core doesn’t.
And - the other way around - with the fix described above it apparently breaks the check in the Enterprise edition.
I was also a bit surprised as to how this problem hasn’t been discussed more often, but the documentation for the best practices was obviously written with the Enterprise-edition in mind.
The broken graphs however are present in the RAW- and Enterprise-edition.
Thank you very much for your effort in this!
So after some tests I can say that the fix didn’t work for me.
With the fixed variable, now I have the IPs in the error message but it says again,
check_icmp: Failed to resolve 8.8.8.8 9.9.9.9: Name or service not known
The same with IPv6
check_icmp: Failed to resolve 2001:4860:4860::8888 2620:fe::fe: Name or service not known
How does your Nagios-Config (in ~/etc/nagios/conf.d/check_mk_objects.cfg) for that host look like?
I tried it with the addresses you supplied and it looks like this:
define host {
_ADDRESSES_4 9.9.9.9
_ADDRESS_4 8.8.8.8
_ADDRESS_4_1 9.9.9.9
_ADDRESS_6
_ADDRESS_FAMILY 4
.....
.....
check_command check-mk-host-ping!-w 200.00,80.00% -c 500.00,100.00%
....
}
And for the PING-Check:
define service {
active_checks_enabled 1
check_command check_mk_active-icmp!'-w' '200.00,80%' '-c' '500.00,100%' '$_HOSTADDRESSES_4$' '$_HOSTADDRESS_4$'
check_interval 1.0
host_name test-dns
service_description PING
use check_mk_perf,check_mk_default
}
This is my nagios config:
define host {
_ADDRESSES_4 8.8.8.8 9.9.9.9
_ADDRESSES_6 2001:4860:4860::8888 2620:fe::fe
_ADDRESS_4 1.1.1.1
_ADDRESS_4_1 8.8.8.8
_ADDRESS_4_2 9.9.9.9
_ADDRESS_6 2606:4700:4700::1112
_ADDRESS_6_1 2001:4860:4860::8888
_ADDRESS_6_2 2620:fe::fe
...
check_command check-mk-host-ping!-w 200.00,80.00% -c 500.00,100.00%
...
define service {
active_checks_enabled 1
check_command check_mk_active-icmp!'-m' '1' '-w' '200.00,80%' '-c' '500.00,100%' '$_HOSTADDRESSES_4$' '$_HOSTADDRESS_4$'
check_interval 1.0
host_name internet
max_check_attempts 3
process_perf_data 1
service_description Internet connection v4
use check_mk_perf,check_mk_default
}
I see as only difference the “-m 1” option in my config.
Test from command line:
./check_icmp -m 1 -w 200.00,80% -c 500.00,100% 1.1.1.1 8.8.8.8 9.9.9.9
OK - 1.1.1.1: rta 22.910ms, lost 0% :: 8.8.8.8: rta 9.563ms, lost 0% :: 9.9.9.9: rta 11.268ms, lost 0%|1.1.1.1rta=22.910ms;200.000;500.000;0; 1.1.1.1pl=0%;80;100;; 1.1.1.1rtmax=27.487ms;;;; 1.1.1.1rtmin=21.240ms;;;; 8.8.8.8rta=9.563ms;200.000;500.000;0; 8.8.8.8pl=0%;80;100;; 8.8.8.8rtmax=12.278ms;;;; 8.8.8.8rtmin=8.499ms;;;; 9.9.9.9rta=11.268ms;200.000;500.000;0; 9.9.9.9pl=0%;80;100;; 9.9.9.9rtmax=17.039ms;;;; 9.9.9.9rtmin=9.546ms;;;;
Ah, this seems to be yet another problem. I didn’t try it with more than 1 additional addresses, so i didn’t have this issue.
This problem was already acknowledged and fixed upstream, see check_icmp: Failed to resolve multiple addresses
This bug apparently is present in CMK 2.0 up until 2.0.0p5 and should be fixed in 2.0.0p6. You can however apply the fix to line 62 to your version of check_icmp as seen in the Commit here: 12897 FIX check_icmp: Failed to resolve multiple addresses · tribe29/checkmk@f1d1c26 · GitHub
Then it should also work on your site and that problem should be fixed in the next version.
But the problem with $HOST_ADDRESSES_4 will probably still be present in the next version…
Thanks for the hint with the werk. This finally solves my issue. I let the “Solution” on the other answer, because this bug will be fixed in the next version.
Thank you again for your effort!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.