traps за и против

[tuban]

С прошедшим новым годом, господа и дамы (если таковые присутсвуют).

Собственно, прошло около трех месяцев, как я разобрался и стал использовать trap. Сеть небольшая, около 100 устройсв - в основном сиськи, джунихеры.

Сейчас, trap срабатывает только на падение/поднятие линка. Сначала, моему счастью не было предела, аварии отрабатывают мгновенно (не считая задержки на доставку сомого trap). Но, я знал, что trap - это udp, что делает возможным ситауцию, когда сообщение просто не будет дставлено. Однако, не смотря на это, я переделал все шаблоны под trap'ы.

По прошесвию времени, хочу сказать:
- Очень часто возникают ситуации, когда trap просто не доходят. Допустим, пришел trap на падение линка, а на поднятие - нет. И смена в шоке, как так все работает, а на мониторинге "красненькое".
- Если падают uplink интерфейсы, то трапы на падение, возможно и дойдут, а вот на поднятие, по понятным причинам, вы их уже не дожетесь. Была нехорошая ситуация с падением магистрального маршрутизатора. Пришлось генерировать trap вручную.

Вывод: да, trap позволяет максимально быстро, практически мгновенно выявить проблему, но использовать trap для мониторинга состояния линков я больше не хочу, лучше использовать соответсвующие oid. Разница в 30, путь даже 60 секунд не так уж и сущесвенна, в сравнении с моими нервами...

Хотя, совсем от использование trap я бы не стал отказываться. Кто-нибудь заморачивался обработкой trap на отказ вентиляторов, блоков питания итд?

У кого-какие мысли по данному вопросу в целом? Кто-то ещё использует trap в своем мониторинге, если - да, то как?

Спасибо.

[OKyHb]

Похоже используем и у себя snmp трапы (snmptrapd, snmptt, zabbix_sender).
По состоянию портов - ещё сами не определились, как сделать лучше, пока используем такую схему:

• трапы link up/down включены только на коммутаторах агрегации и выше
• в шаблоне для коммутаторов есть один айтем link_trap (Zabbix trapper) и триггер вида link_trap.nodata(60)}=0
• создан action отсылки сообщений в jabber для noc'a при срабатывании этого триггера

А просто мониторить состояние портов (ifOperStatus) - затратно по ресурсам. И профита особого нет - проще и надёжнее пинговать железки, которые в этот порт включены. А вот питание от ИПБ - тут уже опрашиваем (раз в 5 минут), а snmp трапы просто пишем в snmptt.log.

Тоже есть желание красиво настроить триггеры на различные snmp трапы, но всё никак нет времени. Поэтому пока всё собирается, расшифровывается и пишется в snmptt.log, но вот мониторить через zabbix - не сделали. Хотя есть желание. Но только с использованием дополнительной прослойки в виде sec (simple event correlator).

[gdgsoft]

У себя использую трапы по полной. Всего порядка 3500 хостов, на большей половине из них настроены трапы.

Для компенсации потери UDP-пакета использую скрипт для синхронизации состояний интерфейсов, который может запускаться с разной периодичностью на разных железках. Например, раз в 20минут, вместо опроса всех интерфейсов каждые 30сек.

Профит от трапа есть!!!
С помощью активного SNMP-опроса вы никогда не узнаете о флапании порта. В то время как трап вам это покажет четко.
Даже если будете опрашивать раз в 30сек. высока вероятность того, что вы всегда будете попадать на момент, когда порт в апе.

Плюс как к этому отнесется железка? Они же разные есть. Кто в состоянии отдать 2(Admin+Oper) х48 (кол портов) х2 (два раза в минуту) состояний, а кто и нет.

[tuban]

Идея интересная, а не могли бы приложить скрипт? Как происходит синхронизация. Спасибо.

У себя использую трапы по полной. Всего порядка 3500 хостов, на большей половине из них настроены трапы.

Для компенсации потери udp-пакета использую скрипт для синхронизации состояний интерфейсов, который может запускаться с разной периодичностью на разных железках. Например, раз в 20минут, вместо опроса всех интерфейсов каждые 30сек.

Профит от трапа есть!!!
С помощью активного snmp-опроса вы никогда не узнаете о флапании порта. В то время как трап вам это покажет четко.
Даже если будете опрашивать раз в 30сек. высока вероятность того, что вы всегда будете попадать на момент, когда порт в апе.

Плюс как к этому отнесется железка? Они же разные есть. Кто в состоянии отдать 2(admin+oper) х48 (кол портов) х2 (два раза в минуту) состояний, а кто и нет.

[gdgsoft]

Идея интересная, а не могли бы приложить скрипт? Как происходит синхронизация. Спасибо.

Не поймите неправильно, но я думаю, что Вам подобный скрипт полезней будет написать самостоятельно. Как минимум, по двум причинам:
1) сможете реализовать ту логику, которая устроит Вас;
2) разберетесь с API, что позволит Вам готовить под Zabbix скрипты в значительной степени расширяющие его функционал.

И всем этим счастьем поделитесь с нами
Удачи.

[tuban]

Тогда, хотя бы на словах опишите логику работы и синхрнизации

[gdgsoft]

Честно сказать, даже не знаю, что тут можно рассказать...

По сути, у Вас есть:
1) железо со своим состоянием портов;
2) есть Zabbix, с элементами хоста (для этого железа).

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

Вот пожалуй и все.

Но в Zabbix-е есть баг, как по мне, даже репорт открыл, но пока увы...
Суть его в том, что не всегда Заббикс корректно отрабатывает те значения, которые пришли от железа через трапы (по отношению к Забиксу они пассивны, т.к. как он не сам их вычитывает). В результате получается такая ерунда, когда триггер в авариях висит (порт в Дауне), а последнее значение по порту показывает, что порт в Up-е. Начинаешь смотреть, действительно, элементом был принят трап о том, что порт поднялся, но триггер почему то не сбросился.

Мой скрипт это, к сожалению, не отрабатывает. Возможно, если брать из Заббикса активные триггера для данной железки и уже с ними сравнивать состояние портов, то от этой проблемы получится избавиться.

[tuban]

Не знаю, у меня трапы отрабатывает корректно. Главное, правильно написать триггер.

Если все так, как вы говорите, причем тут тогда zabbix-api?

Я долго думал, как должен выглядеть триггер. Что только не придумывал...
Есть трап, приходящий мгновенно. Есть ifOperStatus который опрашивает значение раз в 20 минут. А теперь вопрос, как будет выглядеть триггер, который заменит состояние порта с down на up, если трап не дойдет? Даже при использовании гистерезиса получается ерунда.

[gdgsoft]

Не знаю, у меня трапы отрабатывает корректно. Главное, правильно написать триггер.

Если все так, как вы говорите, причем тут тогда zabbix-api?

Я долго думал, как должен выглядеть триггер. Что только не придумывал...
Есть трап, приходящий мгновенно. Есть ifoperstatus который опрашивает значение раз в 20 минут. А теперь вопрос, как будет выглядеть триггер, который заменит состояние порта с down на up, если трап не дойдет? Даже при использовании гистерезиса получается ерунда.

Очевидно, у нас абсолютно разные подходы в приеме трапов.

[tuban]

И как же их принимаете Вы?

К тому же, Вы так и не ответили на вопрос. А то что я писал относится к синхронизации trap и oid.

[gdgsoft]

У меня используется ловушка snmptrapd.
Она принимает трапы, парсит, анализирует и посылает в хост Забикса знаяения в элементы типа:
ifAdminStatus.10001
ifOperStatus.10001

Триггера:
1) Админ состоние:
{Cisco_C2960-LANBASE-M_Fa24Gi2_Trap:ifAdminStatus.10001.last(0)}=0
2) Опер состояние:
{Cisco_C2960-LANBASE-M_Fa24Gi2_Trap:ifOperStatus.10013.last(0)}=0

Синхронизатор выбирает ifAdminStatus.10001 и ifOperStatus.10001 с железа, смотрит в каком состоянии эти же элементы в Забиксе и если они отличаются, то пуляет в Забикс то что получил с железа. Вся обвязка по взаимодействию с Забиксом написана на API.

[tuban]

Но в такой ситуации, если порт поднялся через 5 минут после того, как упал, а трап не дошел, то и заббикс ничего не покажет. Так, как нет повода проверить ifoperstatus, трапер ничего не получил же...

[gdgsoft]

Но в такой ситуации, если порт поднялся через 5 минут после того, как упал, а трап не дошел, то и заббикс ничего не покажет. Так, как нет повода проверить ifoperstatus, трапер ничего не получил же...

А для чего тогда я использую синхронизатор состояний?

[OKyHb]

Но в Zabbix-е есть баг, как по мне, даже репорт открыл, но пока увы...
Суть его в том, что не всегда Заббикс корректно отрабатывает те значения, которые пришли от железа через трапы (по отношению к Забиксу они пассивны, т.к. как он не сам их вычитывает). В результате получается такая ерунда, когда триггер в авариях висит (порт в Дауне), а последнее значение по порту показывает, что порт в Up-е. Начинаешь смотреть, действительно, элементом был принят трап о том, что порт поднялся, но триггер почему то не сбросился.

Тоже такое замечали. Довольно редко, но бывает.

Коллеги, а у вас создаётся по отдельному айтему и триггеру на каждый физический порт коммутатора? (ifOperStatus)
Без всяких discovery для айтемов, просто используются шаблоны с соответствующим к-вом портов?

[gdgsoft]

Тоже такое замечали. Довольно редко, но бывает.

Коллеги, а у вас создаётся по отдельному айтему и триггеру на каждый физический порт коммутатора? (ifoperstatus)
Без всяких discovery для айтемов, просто используются шаблоны с соответствующим к-вом портов?

1) Да, бывает редко.
2) Да, именно. Только на каждый порт два итема: АдминСтатус и ОперСтатус. И зависимость триггеров: Опер от Админ.