Часть моего сетевого состояния имеет довольно важную зависимость от хоста, доступность которого трудно проверить. У меня есть несколько хостов, и у моего провайдера NAGIOS VPS иногда возникают проблемы с маршрутизацией, которые отключают провайдера, на котором расположены все эти хосты. Когда он недоступен, я бы предпочел, чтобы ведущие за ним показали UNAVAILABLE чем DOWN, потому что они не ВНИЗ.
Но его наличие трудно обнаружить, потому что его нельзя пинговать.
[me@nagios systems]$ ping -c 1 -w 1 205.251.232.153
[...]
1 packets transmitted, 0 received, 100% packet loss, time 1000ms
и, похоже, на нем нет сетевых служб, отвечающих на запросы:
[me@nagios systems]$ nmap -P0 -sT 205.251.232.153
[...]
All 1000 scanned ports on 205.251.232.153 are filtered
Однако он участвует и отвечает на traceroutes, в результате чего я обнаружил, что он будет возвращать ICMP-port-unreachable, когда я пытаюсь поговорить с выбранным диапазоном портов UDP. Это tcpdump вывод, пока я делаю echo foo|nc -u 205.251.232.197 33459:
[me@nagios systems]$ sudo tcpdump -n -n -i p1p1 host 205.251.232.197
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on p1p1, link-type EN10MB (Ethernet), capture size 65535 bytes
15:04:01.278269 IP a.b.c.d.36139 > 205.251.232.197.33459: UDP, length 4
15:04:01.448659 IP 205.251.232.197 > a.b.c.d: ICMP 205.251.232.197 udp port 33459 unreachable, length 36
Мне кажется, что мне нужен тест, который отправляет UDP-пакет на хост и порт и рассматривает ICMP-port-unreachable как свидетельство успеха (ничего не слышно - это неудача). Кто-нибудь знает, как это сделать? Как другие справляются с аналогичными проблемами мониторинга?
Я, наконец, с опозданием понял, что если я смогу проследить маршрут через хост, я также должен иметь возможность трассировать маршрут к этот хост и при тестировании подтвердили, что это действительно так.
Все плагины, связанные с traceroute, которые я мог найти в таких местах, как Биржа NAGIOS более сложные, чем это; они хотят проверить такие вещи, как идентификация первого или второго перехода в цепочке и т. д. Все, что мне нужно, это плагин, который проверяет, могу ли я проследить маршрут до хоста и получить ответ. Я нашел плагин, который (примерно) сделал это, и придал ему форму для использования с Linux (в частности, CentOS 6); он появляется ниже на тот случай, если он кому-то пригодится.
#!/bin/sh
#set -vx
################################################################################
# AUTHOR: Vladimir Vuksan
# E-mail: Check http://vuksan.com/linux/
# License: GPL
# changes by Tom Yates, http://www.teaparty.net/
################################################################################
if [ $# -ne 1 ]; then
echo "Usage: $0 <ip.address>"
exit;
fi
IP=${1}
TRACEROUTE=`/bin/traceroute -n ${IP} 2>&1 | grep "${IP} "`
RESULT=`echo $TRACEROUTE | grep -c ms`
if [ $RESULT -eq 1 ]; then
echo TRACERT OK: `echo $TRACEROUTE | cut -f4- -d" "`
exit 0
else
echo TRACERT CRITICAL: Host unreachable
exit 2
fi
С тех пор этот хост несколько раз становился недоступным, и мой NAGIOS поступил правильно: все хосты на противоположной стороне получили предупреждение как НЕДОСТУПНО вместо DOWN.
Независимо от того, какой протокол вы используете для проверки доступности хостов, если есть проблемы с маршрутизацией к хосту, он будет отображаться как неработающий. Если вы хотите проверить доступность хостов и не хотите включать ICMP, вы можете выполнить check_tcp или check_udp для любой из запущенных там служб. Например. check_tcp -p 80 для HTTP или check_tcp -p 22 для ssh.
Хотя, похоже, более серьезная проблема, которую вы пытаетесь решить, - это не предупреждение для хостов за шлюзом, когда шлюз недоступен. Это можно решить, указав зависимости в nagios. Хосты (или службы) за шлюзом должны зависеть от шлюза. Затем, если шлюз не работает, он не будет предупреждать вас о других хостах. (http://nagios.sourceforge.net/docs/3_0/dependencies.html)