traps за и против

[Jimson]

Как по мне, нужно:
1) взять состояние портов непосредственно на железе
2) сравнить с тем, что содержится в элементах этого хоста для данных портов;
3) там где значения отличаются, закинуть в элементы Zabbix-а те значения, которые были вычитаны из железа.

А не могли бы вы пояснить зачем это нужно делать через скрипты и API, вместо того что бы настроить элемент данных ifOperStatus с требуемым вам интервалом и использовать значение этого элемента в условии триггера?

Так же в теме не раскрыта причина дропа UDP трафика в сети. Либо у вас свичи по какой то причине не генерируют трапы, например, перегруженный CPU, либо вы не настраиваете QoS для management трафика в сети.

[gdgsoft]

А не могли бы вы пояснить зачем это нужно делать через скрипты и API, вместо того что бы настроить элемент данных ifOperStatus с требуемым вам интервалом и использовать значение этого элемента в условии триггера?

Так же в теме не раскрыта причина дропа UDP трафика в сети. Либо у вас свичи по какой то причине не генерируют трапы, например, перегруженный CPU, либо вы не настраиваете QoS для management трафика в сети.

1) Вы имеете ввиду настроить элемент с типом snmp v(1, 2c, 3) ?
Если да, то таким образом, на мой взгляд, я не получу флапающие порты. Да и на мой взгляд железку насиловать активными опросами не совсем хорошая идея, тем более что часть вещей по портам и так снимается активным snmp опросом. Но основной момент - флапы портов. ИМХО.

2) Две причины:
* "вы не настраиваете QoS для management трафика в сети";
* не все железки при админ блокировке порта посылают трап. А у меня на это состояние еще кое какой функционал прикручен.

В общем, у каждого свой путь

[Mikhail2]

1) Вы имеете ввиду настроить элемент с типом snmp v(1, 2c, 3) ?
Если да, то таким образом, на мой взгляд, я не получу флапающие порты. Да и на мой взгляд железку насиловать активными опросами не совсем хорошая идея, тем более что часть вещей по портам и так снимается активным snmp опросом. Но основной момент - флапы портов. ИМХО.

Как я понял Jimson предлагает сделать и трапы и активные опросы (например в те же 20 минут, что у вас делается при синхронизации состояний). И сделать один триггер с использованием и трапов и snmp-опроса. Если был даун порта, зажегся триггер, при поднятии порта трап не дошел - значит триггер все еще горит, но тут раз в 20 минут опрашивается snmp, опрос прошел - статус ап - значит триггер выключается. Получается тоже самое, что и у вас с синхронизацией состояния каждые 20 минут (они же тоже кстати по snmp?), только встроенными средствами без лишних скриптов.

[Jimson]

1) Вы имеете ввиду настроить элемент с типом snmp v(1, 2c, 3) ?
Если да, то таким образом, на мой взгляд, я не получу флапающие порты. Да и на мой взгляд железку насиловать активными опросами не совсем хорошая идея, тем более что часть вещей по портам и так снимается активным snmp опросом. Но основной момент - флапы портов. ИМХО.

Я спрашивал не про триггер как таковой, условие которого у вас вычисляется по содержимому трапа, а про ваш скрипт, который по вашим словам "собирает регулярно данные ifOperStatus и через zabbix API" чего то там "синхронизирует". Вот мне и не понятен смысл этого скрипта, если можно собирать средствами zabbix пулера с тем же самым интервалом тот же самый ifOperStatus, а в условие вашего триггера расширить.

[tuban]

Я спрашивал не про триггер как таковой, условие которого у вас вычисляется по содержимому трапа, а про ваш скрипт, который по вашим словам "собирает регулярно данные ifOperStatus и через zabbix API" чего то там "синхронизирует". Вот мне и не понятен смысл этого скрипта, если можно собирать средствами zabbix пулера с тем же самым интервалом тот же самый ifOperStatus, а в условие вашего триггера расширить.

А как будет выглядеть триггер, который, грубо говоря "синхронизирует" полученные данные от trap и oid. Я вот думал, так и не придумал. Хотя, идея хорошая...

[Jimson]

например, при активированном триггере если кол-во ifOperStatus равных 1 за интервал X секунд больше 0/1, а кол-во трапов linkDown равно нулю за тот же интервал X, то значит у нас потерялся linkUp
ну и соответсвенно можно и ситуацию с потерей linkDown предусмотреть

[tuban]

Да, похоже на правду, надо попробовать. Спасибо.

[Evgeniy]

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

[tuban]

Попробовал вчера. Единственной, хотел прикрутить не к ifoperstatus, а к исходящему трафику. Когда линка нет он равен нулю, когда есть, он генерирует около 200б/с служебной информации.
Сам триггер срабатывающий на trap выглядит так:

({TRIGGER.VALUE}=0&{sw01.lan.cus.khb:snmptrap[value=STRING: "Ethernet1/4"].str("iso.3.6.1.6.3.1.1.5.3")}=1) | ({TRIGGER.VALUE}=1&{sw01.lan.cus.khb:snmptrap[value=STRING: "Ethernet1/4"].str("iso.3.6.1.6.3.1.1.5.4")}=0)

Теперь, ради проверки создал такую конструкцию:

({TRIGGER.VALUE}=0&{sw01.lan.cus.khb:ifOutOctets.[Ethernet1/4].last(0)}=0) | ({TRIGGER.VALUE}=1&{sw01.lan.cus.khb:ifOutOctets.[Ethernet1/4].last(0)}#0)

Но, отчего-то она отрабатывает некорректно. Т.е, трафик упал до 0 = проблема. Потом, триггер переходит в состояние "ОК" и снова "Проблема". Хотя, в состояние "ОК" он должен переходить только при наличии трафика...
Пробовал по разному: avg, min итд. Результат такой же. Пробовал указывать:

({TRIGGER.VALUE}=1&{sw01.lan.cus.khb:ifOutOctets.[Ethernet1/4].last(0)}>20)

Не помогает.

Не могу понять, почему так...

[Jimson]

Да потому что условие триггера это ОДНО условие, возьмите листочек и решите ваше логическое выражение. Постоянно одна и таже ошибка в триггерах с гистерезисом: вы составляете его так как-будто у вас два несвязных условия переключения триггера в противоположное значение, а на самом деле это одно условие.

Для примера возьмем задачу из документации - триггер переходит в состоянии проблема при 20 градусах, а возвращается в состояние OK при 15. Вы решили эту задачу так:

({TRIGGER.VALUE=0} & {temp.last(0) > 20}) | ({TRIGGER.VALUE=1} & {temp.last(0) < 15})

это не правильно, правильно будет {temp.last(0) > 15}

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

[tuban]

Тогда, триггер будет выглядеть так:

({TRIGGER.VALUE}=0&{sw01.lan.cus.khb:ifOutOctets.[Ethernet1/4].last(0)}=0) | ({TRIGGER.VALUE}=1&{sw01.lan.cus.khb:ifOutOctets.[Ethernet1/4].min(160)}=0)

Все работает. Но, когда пытаюсь их скрестить:

({TRIGGER.VALUE}=0&{sw01.lan.cus.khb:snmptrap[value=STRING: "Ethernet1/4"].str("iso.3.6.1.6.3.1.1.5.3")}=1) | ({TRIGGER.VALUE}=1&{sw01.lan.cus.khb:snmptrap[value=STRING: "Ethernet1/4"].str("iso.3.6.1.6.3.1.1.5.4")}=0 | {sw01.lan.cus.khb:ifOutOctets.[Ethernet1/4].min(160)}=0)

Он работает следующим образом:
Когда трафик не упал до 0 - работает корректно. Когда трафик упал до 0 - трап не обрабатывается, приходится ждать 160 секунд. Не могу понять, почему так?..

[Jimson]

Возможно потому что надо добавить скобки ({trigger.value}=1 & ( ... | ... ))

[tuban]

Нет, не помогло.

[Jimson]

Ну значит в данных чтото не то, что вы ожидаете. Сделайте несколько триггеров проверочных, отдельно {sw01.lan.cus.khb:snmptrap[value=STRING:"Ethernet1/4"].str("iso.3.6.1.6.3.1.1.5.3")}=1, {sw01.lan.cus.khb:snmptrap[value=STRING:"Ethernet1/4"].str("iso.3.6.1.6.3.1.1.5.4")}=0 и {sw01.lan.cus.khb:ifOutOctets.[Ethernet1/4].min(160)}=0 и смотрите что получается: 1 & 1 = 1, 1 | 0 = 1. Пытайтесь отлаживать свою проблему, а не ждите телепатов на форуме.

[tuban]

Дык, отдельно они корректно отрабатывают, пробовал уже...