zabbix_sender в item c типом "SNMPv2 agent"

[fredushka]

Есть на сети пачка свичей связанных в кольца. В zabbix мониторятся основные порты на предмет up/down по snmp, скажем, раз в 5 мин.
Хочу оптимизировать этот процесс и вместо опроса состояния порта решил ловить трапы. Но на кольцевых STP свичах при падении линка трапы иногда теряются во время перестроения кольца. Значит, иногда все же надо опрашивать состояния портов не надеясь на трапы, но интервал опроса можно существенно увеличить.

Собственно проблема: zabbix отказывается принимать сообщения от zabbix_sender в item с типом "SNMPv2 agent". А хочется иметь такой item, который будет не только сам по snmp мониторить, но и будет принимать данные от zabbix_sender.

Сталкивался кто с такой "хотелкой"? Решение - только в правке исходников?

[fredushka]

Как и оказалось - в сырцах разрешено значения от zabbix_sender принимать только в item с типом "zabbix trapper"
Я ковырнул сырцы и все заработало.
Теперь жду комментариев - почему мне это не стоило делать
Эта проверка стояла для "формализации поступающих данных" или для безопасности?

--- proxy.c.org 2010-08-02 22:07:10.000000000 +0400
+++ proxy.c     2010-08-23 16:26:03.000000000 +0400
@@ -1278,10 +1278,7 @@
                if (item.type == ITEM_TYPE_INTERNAL || item.type == ITEM_TYPE_AGGREGATE || item.type == ITEM_TYPE_CALCULATED)
                        continue;

-               if (0 == proxy_hostid && item.type != ITEM_TYPE_TRAPPER && item.type != ITEM_TYPE_ZABBIX_ACTIVE)
-                       continue;
-
-               if (item.type == ITEM_TYPE_TRAPPER && 0 == proxy_hostid &&
+               if (0 == proxy_hostid &&
                                FAIL == zbx_tcp_check_security(sock, item.trapper_hosts, 1))
                {
                        zabbix_log(LOG_LEVEL_WARNING, "Process data failed: %s", zbx_tcp_strerror());

[zalex_ua]

Собственно проблема: zabbix отказывается принимать сообщения от zabbix_sender в item с типом "SNMPv2 agent". А хочется иметь такой item, который будет не только сам по snmp мониторить, но и будет принимать данные от zabbix_sender.

Сталкивался кто с такой "хотелкой"? Решение - только в правке исходников?

править исходники всегда плохо Вскоре вы это поймете (месяца через два).
Мне интересно увидеть те ваши триггера, которые будут корректно отрабатывать и полученные данные сервером и трапы
Вам этого точно не стоило бы делать. Делайте два отдельных Элемента данных для этого с правильными параметрами.

[fredushka]

править исходники всегда плохо Вскоре вы это поймете (месяца через два).

Тем и хорош опенсорс, что поиск багов и добавление фич всеми желающими облегчает жизнь разаработчикам . Я оформил себе эту фичу как патч - буду применять на следующих версиях. Если когда нибудь патч перестанет накладываться - мне не лениво будет опять по сырцам пройтись

Мне интересно увидеть те ваши триггера, которые будут корректно отрабатывать и полученные данные сервером и трапы

Уже. Вполне себе работает, и триггеры взводятся как надо.

Вам этого точно не стоило бы делать. Делайте два отдельных Элемента данных для этого с правильными параметрами.

на ~400 коммутаторов, на одно событие при таком раскладе будут срабатывать по два триггера (один по трапу, другой по snmp опросу). А зачем два, если можно обойтись одним

[zalex_ua]

Тем и хорош опенсорс, что поиск багов и добавление фич всеми желающими облегчает жизнь разаработчикам . Я оформил себе эту фичу как патч - буду применять на следующих версиях. Если когда нибудь патч перестанет накладываться - мне не лениво будет опять по сырцам пройтись

Отлично. Нет вопросов.

Уже. Вполне себе работает, и триггеры взводятся как надо.

Гм. Обычно трапы выглядят совсем не так как числовые данные например с ОИД .1.3.6.1.2.1.2.2.1.8 так как же вы их сравниваете в одном триггере? Или у вас особенный скрипт, который парсит полученный трап и отсылает только число 1 или 0 в зависимости от содержания трапа?

Опубликуйте сюда параметры Элемента данных и триггера. Интересно все же их увидеть, и дайте информацию о скрипте вашем - штатный или переделан?

на ~400 коммутаторов, на одно событие при таком раскладе будут срабатывать по два триггера (один по трапу, другой по snmp опросу). А зачем два, если можно обойтись одним

Действительно. Зачем два если можно одним опросом обойтись вам же надежность важна? Вы же опрос все равно не отключаете, тем более у вас периодичность не такая большая чтобы сильно задумываться над оптимизацией производительности ИМХО.

[fredushka]

Или у вас особенный скрипт, который парсит полученный трап и отсылает только число 1 или 0 в зависимости от содержания трапа?

Конечно. Непарсенный трап - ничуть не лучше лог-файла. Что-то в этом духе

    case "$oid" in
        linkDown|linkUp)
        if [ "$oid" == "linkDown" ]
           then
        /usr/local/zabbix/bin/zabbix_sender -z 127.0.0.1 -s $hostname  -k ifOperStatus.$ifIndex -o 2 >/dev/null 2>&1
        fi
        if [ "$oid" == "linkUp" ]
           then
        /usr/local/zabbix/bin/zabbix_sender -z 127.0.0.1 -s $hostname  -k ifOperStatus.$ifIndex -o 1 >/dev/null 2>&1
        fi

Опубликуйте сюда параметры Элемента данных и триггера.

Все как обычно

Интересно все же их увидеть, и дайте информацию о скрипте вашем - штатный или переделан?

От штатного осталась лишь "шапка" . Общий принцип: определяем от какой железки прилетел трап, потом классифицирую трап, затем задвигаю по адресу

Действительно. Зачем два если можно одним опросом обойтись вам же надежность важна? Вы же опрос все равно не отключаете, тем более у вас периодичность не такая большая чтобы сильно задумываться над оптимизацией производительности ИМХО.

Скорее важна оперативность. Можно раз в 30 сек опрашивать по 2 порта на 400 свичах (их количество будет расти) - 800/30=26 запросов в секунду, но это не есть "гуд" - заббиксу и без того забот хватает