Ложное срабатывающие тригеры!!!

[sergeyfromkomi]

После переезда с версии 1.8.2 на 2.0.3 обнаружилась проблема ложного срабатывания тригеров.

После того, как узел становится физически не доступен (обесточен или произошел обрыв кабеля) Zabbix это регистрирует(тригер срабатывает). Но после этого с интервалом примерно в 2 минуты сообщает о поднятии узла и через это-же время о его падении, это продолжается вплоть до устранения аварии. CPU не загружен. RAM достаточно.

CPU: 12.4% user,  0.0% nice,  4.3% system,  0.8% interrupt, 82.5% idle
Mem: 140M Active, 365M Inact, 177M Wired, 112M Buf, 1313M Free
Swap: 4096M Total, 4096M Free

Список узлов,итемов и тригеров импортировали из 1.8.2 в 2.0.3.

Ни каких хитрых способов проверки нет.
Отслеживается только доступность узлов сети с помощью ping-ов.
выражение тригера такое :
{HOSTNAME:icmpping.sum(#3)}=0

Zabbix мониторит ISP сеть. Устранени проблемы идёт уже более 2-ух недель, пока безрезультатно... Подобные проблемы наводят руководство о смене системы мониторинга и оповещения... , а так не хочется отказываться от zabbix-а

[dima_dm]

А Item на закладке Последние данные что показывает?

[sergeyfromkomi]

А Item на закладке Последние данные что показывает?

Данные изменяются соответственно состоянию тригера. График в "Последние данные" это подтверждает.

Естественно всё это время хост не пингуется...

 # ping 172.16.250.20
PING 172.16.250.20 (172.16.250.20): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down

[neogan]

А в логе zabbix сервера что? Есть возможность включить отладку? Debug=4

[sergeyfromkomi]

А в логе zabbix сервера что? Есть возможность включить отладку? Debug=4

В режиме Debug=4 вылетело:

 # cat /tmp/zabbix_server.log.old | grep 172.16.250.20
 11708:20130430:133102.477 In add_pinger_host() addr:'172.16.250.200'
 11708:20130430:133102.477 In add_pinger_host() addr:'172.16.250.20'
 11708:20130430:133102.477 172.16.250.200
 11708:20130430:133102.477 172.16.250.20
 11708:20130430:133105.270 read line [172.16.250.200 : 0.66 0.97 0.66]
 11708:20130430:133105.270 read line [172.16.250.20  : - - -]
 11708:20130430:133105.271 Host [172.16.250.200] cnt=3 rcv=3 min/max/avg=0.000660/0.000970/0.000763
 11708:20130430:133105.271 Host [172.16.250.20] cnt=3 rcv=0 min/max/avg=0.000000/0.000000/0.000000
 11708:20130430:133132.156 In add_icmpping_item() addr:'172.16.250.20' count:3 interval:0 size:0 timeout:0
 11708:20130430:133132.156 In add_icmpping_item() addr:'172.16.250.200' count:3 interval:0 size:0 timeout:0
 11708:20130430:133132.157 In add_pinger_host() addr:'172.16.250.200'
 11708:20130430:133132.157 In add_pinger_host() addr:'172.16.250.20'
 11708:20130430:133132.157 172.16.250.200
 11708:20130430:133132.157 172.16.250.20
 11708:20130430:133134.952 read line [172.16.250.200 : 1.00 0.66 0.98]
 11708:20130430:133134.952 read line [172.16.250.20  : - - -]
 11708:20130430:133134.953 Host [172.16.250.200] cnt=3 rcv=3 min/max/avg=0.000660/0.001000/0.000880
 11708:20130430:133134.953 Host [172.16.250.20] cnt=3 rcv=0 min/max/avg=0.000000/0.000000/0.000000

вот ещё ..

# cat /tmp/zabbix_server.log | grep 172.16.250.20
 16676:20130430:143433.159 In add_icmpping_item() addr:'172.16.250.20' count:3 interval:0 size:0 timeout:0
 16676:20130430:143433.160 In add_icmpping_item() addr:'172.16.250.200' count:3 interval:0 size:0 timeout:0
 16676:20130430:143433.160 In add_pinger_host() addr:'172.16.250.20'
 16676:20130430:143433.160 In add_pinger_host() addr:'172.16.250.200'
 16676:20130430:143433.161 172.16.250.20
 16676:20130430:143433.161 172.16.250.200
 16676:20130430:143435.692 read line [172.16.250.20  : - - -]
 16676:20130430:143435.692 read line [172.16.250.200 : 0.81 0.66 0.97]
 16676:20130430:143435.692 Host [172.16.250.20] cnt=3 rcv=0 min/max/avg=0.000000/0.000000/0.000000
 16676:20130430:143435.693 Host [172.16.250.200] cnt=3 rcv=3 min/max/avg=0.000660/0.000970/0.000813
 16681:20130430:143439.103 process_rule() IP:'172.16.250.20'
 16681:20130430:143439.118 172.16.250.20
 16681:20130430:143441.147 read line [172.16.250.20 : - - -]
 16681:20130430:143441.147 In discovery_update_service() ip:'172.16.250.20' port:0 status:1
 16681:20130430:143441.147 In discovery_register_host() ip:'172.16.250.20' status:1 value:''
 16681:20130430:143441.147 query [txnlev:1] [select dh.dhostid,dh.status,dh.lastup,dh.lastdown from dhosts dh,dservices ds where ds.dhostid=dh.dhostid and dh.druleid=2 and ds.ip='172.16.250.20' order by dh.dhostid]
 16681:20130430:143441.149 host at 172.16.250.20 is already in database
 16681:20130430:143441.149 In discovery_separate_host() ip:'172.16.250.20'
 16681:20130430:143441.149 query [txnlev:1] [select dserviceid from dservices where dhostid=23 and ip<>'172.16.250.20' limit 1]
 16681:20130430:143441.149 In discovery_register_service() ip:'172.16.250.20' port:0 key:''
 16681:20130430:143441.149 query [txnlev:1] [select dserviceid,dhostid,status,lastup,lastdown,value,dns from dservices where dcheckid=1 and type=12 and key_='' and ip='172.16.250.20' and port=0]

ip 172.16.250.20 узла который не доступен.

[sergeyfromkomi]

Странно, что в "последних данных" данных забикс пишет о изменении статуса тригера.
Есть шансы раскрыть тайну?

[Heilig]

Надежда умирает последней.

Как вариант, можно написать небольшой скрипт и собирать данные параллельно и с правами аналогичными пользователю zabbix, а потом сверить...

Или попытаться "устранить" последствия (при условии что на хосте есть zabbix агент). В конце этой темы, есть пример триггера у которого вероятность ложного срабатывания очень низкая... Чтобы не дошло до смены системы мониторинга, предлагаю сменить выражение триггера.

[sergeyfromkomi]

Напомните пожалуйста, как указать zabbix-у на каком интерфейсе работать.
Тут?:

### Option: ListenPort
#       Listen port for trapper.
#
# Mandatory: no
# Range: 1024-32767
# Default:
# ListenPort=10051

### Option: SourceIP
#       Source IP address for outgoing connections.
#
# Mandatory: no
# Default:
 SourceIP=172.16.250.240

Перенёс zabbix на другой интерфейс,со сменой ip, но говорит что не запущен, и ссылается на не существующий уже ip

Zabbix сервер запущен	Нет	10.14.6.13:10051

[neogan]

Напомните пожалуйста, как указать zabbix-у на каком интерфейсе работать.
Тут?:

### Option: ListenPort
#       Listen port for trapper.
#
# Mandatory: no
# Range: 1024-32767
# Default:
# ListenPort=10051

### Option: SourceIP
#       Source IP address for outgoing connections.
#
# Mandatory: no
# Default:
 SourceIP=172.16.250.240

Да верно сделано, можно проверить через netstat

Перенёс zabbix на другой интерфейс,со сменой ip, но говорит что не запущен, и ссылается на не существующий уже ip

Zabbix сервер запущен	Нет	10.14.6.13:10051

Это я так понимаю у вас в Веб Интерфейсе смущает надпись, ИП нужно еще поменять в /каталог_веб_интерфейса/conf/zabbix.conf.php, выглядит примерно так

$ZBX_SERVER      = '127.0.0.1';
$ZBX_SERVER_PORT = '10051';
$ZBX_SERVER_NAME = '';

[Jimson]

Она не просто смущает, именно по этим "координатам" веб-интерфейс и детектит работу сервера.

P.S. а использование SourceIP отличного от 0.0.0.0 в сервере/проксе ломает SNMP, наглухо

[sergeyfromkomi]

Выяснил, что при мониторинге по snmp данная проблема не обнаруживается... Ложные аварии срабатываю только на узлах с icmp мониторингом.

[Jimson]

Ну из треда не видно где эти "ложные срабатывания". Соберите дебаг, как вы это делали выше, и дождитесь момента этого "срабатывания", затем найдите тот же timestamp в дебаге и выясните что парсится на выходе fping.

Вероятнее всего у вас "ложные icmp replay" случаются, а не "срабатывания тригера". Выражение sum(#3) в тригере слишком уж резвое.

Прикладываю в качестве примера и наглядного пособия по использованию макросов свои шаблоны, из 4 штуки: основной шаблок только собирает данные
icmppingloss[,{$ICMP_COUNT},100,{$ICMP_SIZE},4000]
icmppingsec[,{$ICMP_COUNT},100,{$ICMP_SIZE},4000]
4 sec таймаута я использую потому что что большая часть "хостов" у меня за спутнитниковыми каналами, перегруженный линк в легкую дает до 3000 RTT, вы можете использовать значение меньше

Далее делаются три темплейта, каждый из которых только определяет триггер, выражение везде одинаковое, а вот "важность" разная, параметры же проверки так же задаются макросами, что дает возможность гибко настраивать триггер не плодя при этом лишних темплейтов и не пересоздавая триггер. Собственно выражение:

{ICMP_Check_1:icmppingloss[,{$ICMP_COUNT},100,{$ICMP_SIZE},4000].avg({$ICMP_CHECK_TIME})}>{$ICMP_CHECK_THRESHOLD}

Дефолтные параметры всех макросов определяются в темплейтах, т.о. переопределяются на хостах они только при необходимости.

Экспорт в атаче.

[sergeyfromkomi]

Спасибо огромное, что не оставляете без внимания мою проблему...

В логе проскакивает:

 58963:20130507:140028.386 In DBget_trigger_update_sql() triggerid:13555 value:0(0) new_value:0
 58963:20130507:140028.386 End of DBget_trigger_update_sql():FAIL
 58963:20130507:140028.386 In DBget_trigger_update_sql() triggerid:13556 value:0(0) new_value:0
 58963:20130507:140028.386 End of DBget_trigger_update_sql():FAIL
 58963:20130507:140028.386 In DBget_trigger_update_sql() triggerid:13581 value:0(0) new_value:0
 58963:20130507:140028.386 End of DBget_trigger_update_sql():FAIL

Может проблема в том, что он не может записать данные в БД?


С вашим шаблоном поэксперементирую.
Мой итем на скриншоте

[sergeyfromkomi]

Использовал ваш шаблон.... Сутки. Полёт нормальный..
Спасибо.

[Jimson]

58963:20130507:140028.386 End of DBget_trigger_update_sql():FAIL

ну эти фейлы явно не нормальное поведение сервера/базы