тригер на недоступность узла

[Dusty]

Я думаю, что Zabbix просто не успевает опрашивать устройства.

tcpdump говорит, что успевает. Вот обрабатывать успевает ли?

Если есть очередь Администрирование-> Очередь, нужно увеличивать количество Pollers.

SNMP поллеров 50 штук. Запросы отправляются в срок, ответы приходят.

/etc/zabbix/zabbix_server.conf
StartPollers
Посмотрите в последних данных по Item ровно ли 30 секунд, между опросами, есть ли пропуски более 65 секунд, это верный признак.

Нету пропусков - специально смотрел. Ну может 1 или 2 на сотню.

Решение: Увеличивать количество Pollers, увеличивать интервал наблюдения не 65 секунд, а например 120 и т.д.

Что конкретно делают поллеры? Кто входные данные обрабатывает?

[dima_dm]

Что конкретно делают поллеры? Кто входные данные обрабатывает?

Собирают данные и записывают их в базу данных. Триггеры уже работают с данными в базе данных.

[gdgsoft]

Был у меня момент как-то... Что пошло все в разнос. Сыпались ошибки по триггерам безпорядочно и т.д.
В результате пришлось тюнинговать БД(my.cnf) на предмет выделения памяти, конкурентности очередей и т.д.
Примеры брал на форуме.

[Sanki]

Советую не использовать ключ status, плохо он работает.
Для серверов с zabbix_agent я использую
{host:agent.ping.nodata(150)}=1
Для всех остальных
{host:icmpping.max(90)}=0

А можно по-подробнее рассказать что делается в обоих случаях?

[dima_dm]

А можно по-подробнее рассказать что делается в обоих случаях?

А документацию почитать?
{host:agent.ping.nodata(150)}=1
Хост с Zabbix Agent недоступен 150 секунд.

{host:icmpping.max(90)}=0
за последние 90 секунд все ping не прошли.

Интервалы опросов задаются в Item agent.ping и icmpping соответственно.
Т.к. для icmpping запускается программа с ключами /usr/sbin/fping -q -C3, т.е. один опрос icmpping это отправка 3 пакетов.
Т.е. если опрос icmpping идёт каждые 30 секунд, то триггер вернёт 0, если за 3 попытки по 3 icmp пакета, т.е. на все 9 icmp пакетов не было получено ответа. Если будет хотя бы один ответ, то значение триггера будет 1.

[Sanki]

А документацию почитать?

Там по другому написано, нежели Вы объяснили.
Может быть суть одна и та же, но Ваша интерпретация куда понятнее

[zalex_ua]

Добавлен элемент данных "NAME" (SNMPv1) - sysName.0 с периодом опроса 30"

Добавлен триггер "No Data" - {HOSTNAME:sysName.0.nodata(65)}=1

Т.е., если я всё правильно понял - если последние 2 (65") значения не получены, то триггер срабатывает.

До поры до времени всё это замечательно работало (таким образом наблюдение велось примерно на 20 хостах), конфигурация сети не менялась.

С определённого момента триггер начал срабатывать при каждом опросе хоста - то с проблемой, то с её снятием.

Получается, что триггер не успевает считать значение из базы?

Куда смотреть?

Нет, дело в другом.

Мои личные записки:
функции ключей, которые пересчитываются автоматически каждые 30 секунд
немного укороченый запрос: [select distinct ... from hosts h,items i,functions f where h.hostid=i.hostid and h.status=0 and i.status=0 and f.function in ('nodata','date','dayofweek','time','now') and i.itemid=f.itemid]
может быть добавить это как колонку в таблицу документации ?

Нодата вычисляется каждых 30 секунд и если задать например 40,50 то все равно функция пересчитывается каждых 30 сек. Может это тоже добавить в доку?

Дискуссии в IRC:
[02.06.2011 11:38] * zalex * Richlv, translation to human readable - all nodata() funtions recalculated every 30 seconds. Even if you set the 40 or 50 or 180 seconds, etc as parameter fo function, it still will be recalculated every 30 seconds (with corresponding aggregation period 40 or 50 or 180 of course). Maybe this is also should add to the documentation?
[02.06.2011 11:54] * Richlv * zalex, oh, but for other trigger functions period is not recalc period either
[02.06.2011 20:51] * zalex * but i spoke about nodata() function only! and maybe i don't understand you

В итоге, это как повезет - зависит от момента реального времени. Тоесть:
Функция НОДАТА вычисляется каждых 30 секунд точно в начале минуты и на 30-ой секунде. Поэтому если у вас данные пришли например на 5-ой секунде минуты (время по заббикс серверу) тогда функция {Хост:eventlog[Test].nodata(30)} даст положительный результат аж через 55 реальных секунд, тоесть в конце этой минуты, так как при просчете на 30 секунде она еще будет видеть ваше событие, пришедшее на 5-ой секунде и будет давать отрицательный результат.


Момент вычисления триггера, в котором присутствует функция nodata() не зависит от моментов опроса !!!
В вашем случае вполне вероятно что когда идут одиночные пропуски и после них некоторые задержки, то отсутствуют данные больше 65 секунд и если так случилось что триггер вычисляется близко к моментам опроса - тогда ваш случай.
Нет желания долго это разжевывать, надеюсь вы поймете.

Рекомендую увеличить период например до 75 или больше секунд. Вероятность может сразу снизится если причиной было возникновение очереди в пуллерах.

Недавно страницу немного подправили (пока что только англ), теперь она более точно объясняет суть дела.

[zalex_ua]

В итоге, это как повезет - зависит от момента реального времени. Тоесть:
Функция НОДАТА вычисляется каждых 30 секунд точно в начале минуты и на 30-ой секунде. Поэтому если у вас данные пришли например на 5-ой секунде минуты (время по заббикс серверу) тогда функция {Хост:eventlog[test].nodata(30)} даст положительный результат аж через 55 реальных секунд, тоесть в конце этой минуты, так как при просчете на 30 секунде она еще будет видеть ваше событие, пришедшее на 5-ой секунде и будет давать отрицательный результат.

Цитирую сам себя, так как эту часть своего поста я изменил, и теперь она соответствует действительности. Прошу прощения у всех успевших прочитать мой частично ошибочный пост.

[mkolomiets]

Привет!
Долго боролся с частыми срабатываниями триггера по доступности, в результате пришел к такому

Итем "agent.ping" интервал установлен 10 секунд

По нему триггер с таким выражением:
{Template_OpenWrt:agent.ping.nodata(60)}=1|{Templa te_OpenWrt:agent.ping.count(90,1)}<4

Задержка включения/выключения триггера получается - приблизительно 1 минута, реальную задержку оповещения регулируем установкой номера шага 2 и нужным значением периода в действии.

ЗЫ. Из-за логики работы у "нодата" есть одна неприятная особенность - на коротких провалах доступности узла возврат состояния триггера в состояние "ОК" фиксируется раньше по времени чем переход в состояние "проблема", в списке событий получается реальная каша. Поэтому пришлось поэкспериментировать с выражением и параметрами функций триггера.