У нас есть небольшая проблема с нашими Nagios check_icmp мониторы ... наша сеть страдает от микропроцессоров, которые могут пропускать 1-2 миллисекунды трафика через наш брандмауэр. Мы работаем над проблемой микровзрывов через брандмауэр, но микропорывы фактически вызывают ложные срабатывания сигнализации об отключении хоста от nagios ...
Sun Jul 14 00:00:37 CDT 2013 [1373778037] HOST ALERT: host1;DOWN;SOFT;1;CRITICAL - 105.195.240.6: rta nan, lost 100%
Sun Jul 14 00:00:37 CDT 2013 [1373778037] HOST ALERT: host2;DOWN;SOFT;1;CRITICAL - 105.195.115.33: rta nan, lost 100%
Sun Jul 14 00:00:37 CDT 2013 [1373778037] HOST ALERT: host3;DOWN;SOFT;1;CRITICAL - 105.193.26.8: rta nan, lost 100%
Sun Jul 14 00:00:37 CDT 2013 [1373778037] HOST ALERT: host4;DOWN;SOFT;1;CRITICAL - 105.193.221.73: rta nan, lost 100%
Sun Jul 14 00:00:37 CDT 2013 [1373778037] HOST ALERT: host5;DOWN;SOFT;1;CRITICAL - 105.194.18.91: rta nan, lost 100%
Причина в том, что check_icmp использует абсурдные значения межпакетного интервала по умолчанию ... интервал между пакетами по умолчанию настолько мал, что весь цикл ping может уместиться в пространстве одного микропакета через брандмауэр ... это то, что мы видим, когда используем check_icmp -n 5 -t 3 -v 10.19.26.29
[mpenning@target1 ~]$ sudo tshark -i eth0 icmp and host nagios.domain.local
[sudo] password for mpenning:
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
0.000000 10.19.20.16 -> 10.19.26.29 ICMP Echo (ping) request
0.000028 10.19.26.29 -> 10.19.20.16 ICMP Echo (ping) reply
0.000348 10.19.20.16 -> 10.19.26.29 ICMP Echo (ping) request
0.000358 10.19.26.29 -> 10.19.20.16 ICMP Echo (ping) reply
0.000572 10.19.20.16 -> 10.19.26.29 ICMP Echo (ping) request
0.000581 10.19.26.29 -> 10.19.20.16 ICMP Echo (ping) reply
0.000792 10.19.20.16 -> 10.19.26.29 ICMP Echo (ping) request
0.000801 10.19.26.29 -> 10.19.20.16 ICMP Echo (ping) reply
0.001017 10.19.20.16 -> 10.19.26.29 ICMP Echo (ping) request
0.001025 10.19.26.29 -> 10.19.20.16 ICMP Echo (ping) reply
Пока check_icmp имеет -i переключатель, который якобы контролирует межпакетный интервал, он по какой-то причине не допускает интервал между пакетами 500 мс ... даже когда я запускаю его как check_icmp -n 5 -t 3 -i 2000 -v 10.19.26.29, сроки существенно не меняются ...
[mpenning@target1 ~]$ sudo tshark -i eth0 icmp and host nagios.domain.local
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
0.000000 10.19.20.16 -> 105.19.26.29 ICMP Echo (ping) request
0.000018 10.19.26.29 -> 105.19.20.16 ICMP Echo (ping) reply
0.000327 10.19.20.16 -> 105.19.26.29 ICMP Echo (ping) request
0.000338 10.19.26.29 -> 105.19.20.16 ICMP Echo (ping) reply
0.000540 10.19.20.16 -> 105.19.26.29 ICMP Echo (ping) request
0.000552 10.19.26.29 -> 105.19.20.16 ICMP Echo (ping) reply
0.000813 10.19.20.16 -> 105.19.26.29 ICMP Echo (ping) request
0.000824 10.19.26.29 -> 105.19.20.16 ICMP Echo (ping) reply
0.001075 10.19.20.16 -> 105.19.26.29 ICMP Echo (ping) request
0.001087 10.19.26.29 -> 105.19.20.16 ICMP Echo (ping) reply
Есть ли способ заставить нагиос? check_icmp или check_ping методы увеличения расстояния между пакетами до 500 мс между эхо-запросами? Я понимаю, что могу попросить nagios отправить 5000 эхо-запросов на каждый хост, но это похоже на настоящую трату системных и сетевых ресурсов только для решения этой проблемы.
check_icmp предлагает несколько настроек командной строки, которые могут помочь. Запустите check_icmp -h из командной строки, чтобы узнать больше.
-i
max packet interval (currently 80.000ms)
-I
max target interval (currently 0.000ms)
-m
number of alive hosts required for success
-l
TTL on outgoing packets (currently 0)
-t
timeout value (seconds, currently 10)
Из моего понимания
-i максимальный интервал пакета (в настоящее время 80,000 мс)
-i 2000 (2.000 мс)
-i 80000 (80,000 мс)
-i 500000 (500.000 мс)