SNMP Trap value в элемент данных

[omgiafs]

Всем доброго дня.

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

Гугл и поиск по форуму сказали, что это можно реализовать с помощью связки snmptrapd > (syslog|trap log) > parser > zabbix-sender.
Лично я застрял на парсере. Никак не могу найти хотя бы пример утилиты, которая мониторила и парсила бы изменения лога snmptrapd или syslog.
Чего-то не догоняю, как это должно выглядеть. Но, по моим скромным понятиям, явно не как tail -f.

Конкретно в моем случае есть элемент данных



Соответственно, требуется, чтобы значение

SW-2212SDAM-MIB::out1.0

, прилетающее в трапе, писалось в элемент данных out1.

Летят трапы, обрабатываются перловым скриптом в Заббиксовский формат.:

19:23:53 2019/04/18 PDU INFO:
  transactionid                  151
  requestid                      14617944
  errorindex                     0
  errorstatus                    0
  receivedfrom                   UDP: [192.168.100.35]:161->[192.168.100.230]:162
  notificationtype               TRAP
  messageid                      0
  version                        1
  community                      public
VARBINDS:
  DISMAN-EVENT-MIB::sysUpTimeInstance type=67 value=Timeticks: (5023034) 13:57:10.34
  SNMPv2-MIB::sysName.0          type=4  value=STRING: "SW-2212SDAM"
  SNMPv2-MIB::sysLocation.0      type=4  value=STRING: "LES-TV"
  SNMPv2-MIB::snmpTrapOID.0      type=6  value=OID: SW-2212SDAM-MIB::control
  SW-2212SDAM-MIB::out1.0        type=2  value=INTEGER: 1
  SW-2212SDAM-MIB::out2.0        type=2  value=INTEGER: 1
  SW-2212SDAM-MIB::state1.0      type=2  value=INTEGER: 3
  SW-2212SDAM-MIB::state2.0      type=2  value=INTEGER: 0
  SW-2212SDAM-MIB::auto1.0       type=2  value=INTEGER: 0
  SW-2212SDAM-MIB::auto2.0       type=2  value=INTEGER: 1

Какую связку лучше сделать чтобы добиться желаемого результата, т.е. и по SNMP опрашивать, и по трапу менять значение элемента данных?
Думается мне что я далеко не первый на этом пути, и что все упрощающие жизнь утилиты для решения данного вопроса уже написаны. Но, видимо, я у Гугла не так спрашиваю.
Потому и прошу помощи, уважаемые. Желательно с примером, как для альтернативно одарённого.
Нашел бы сам - не стал бы вас по пустякам беспокоить.

[oscar]

...опросом по SNMP из трапа...

Это как? Что-то меня от этой фразы переклинило... Это вроде как взаимоисключающие понятия...
Можете прислать миб сей чудесной железки... Или сами откройте каким-нибудь миб браузером - многие вопросы отпадут...

[omgiafs]

Это как? Что-то меня от этой фразы переклинило... Это вроде как взаимоисключающие понятия...
Можете прислать миб сей чудесной железки... Или сами откройте каким-нибудь миб браузером - многие вопросы отпадут...

Там скобки есть. "изменение элемента данных (числовой элемент данных с опросом по SNMP) из трапа". Элемент данных, опрашивается по SNMP.
А мне надо дополнительно чтобы из трапа значение в элемент данных писалось, а не весь трап в почти полностью бесполезный журнал трапов.

Вы хочете песен? Их есть у меня... https://www.dropbox.com/s/8ljqk5482l...M-MIB.MIB?dl=1

[oscar]

В элемент с типом проверки "SNMP агент" принудительно данные не загнать. Или заводите отдельный элемент с типом траппер, или меняйте тип у этого.

[omgiafs]

В элемент с типом проверки "SNMP агент" принудительно данные не загнать. Или заводите отдельный элемент с типом траппер, или меняйте тип у этого.

Да, чтение https://www.zabbix.com/documentation...oncepts/senderясно дало понять, что тип элемента данных должен быть "траппер".
И что, никак не изменить состояние элемента данных? Или опросом, или трапом, или создавать 2 элемента данных?

Блин, это же так логично - опрашивать оборудование или получить от оборудования оповещение о внеплановом изменении параметра... Неужели за все эти годы никто не додумался до реализации этой логичной вещи?

[oscar]

Я ЗНАЮ, что так делают. ЭТО РАБОТАЕТ.
Сторонней утилитой/скриптом парсится трап, значение посылается в Заббикс при помощи zabbix-sender.

Эва как... Документация как бы намекает на обратное... Пробовали послать сендером элементу с типом Агент произвольное значение вручную?

[omgiafs]

Эва как... Документация как бы намекает на обратное... Пробовали послать сендером элементу с типом Агент произвольное значение вручную?

Уже пофиксил

Грустно это, от слова совсем. И что делать в конкретно этом случае? оставлять элемент "траппер"? Но тогда не узнаю состояние параметра, если трап не долетит... Оставлять только периодический опрос - не та специфика, надо отлавливать изменение как можно быстрее. Два элемента данных на один параметр? Это бред какой-то...
Шо, нельзя в данном случае и рыбку съесть и сковородку не помыть?

[oscar]

Уже пофиксил

Грустно это, от слова совсем. И что делать в конкретно этом случае? оставлять элемент "траппер"? Но тогда не узнаю состояние параметра, если трап не долетит... Оставлять только периодический опрос - не та специфика, надо отлавливать изменение как можно быстрее.
Шо, нельзя в данном случае и рыбку съесть и сковородку не помыть?

Ну почему же, можно... Ставьте траппер. Просто опрос тоже скриптом делайте (по крону или привязав как внешнюю проверку) и отправляйте результат сендером в заббикс. Туда же шлите результат парсинга трапов. А парсинг трапов это отдельная (и очень грустная) песня. У меня очень разношерстный зоопарк коммутаторов и почти каждый шлют свои уникальные трапы. Я просто поставил в snmptrapd логирование, руками выделил нужные мне типы, разобрал формат и OID'ы, ну и написал на С++ парсер... Правда получилось не универсально и узкозаточно под конкретные коммутаторы...

[omgiafs]

Хорошо, значит надо делать шиворот навыворот - элемент "траппер", в него сендером пихать результаты опроса внешней проверкой.
Суть остается та же: snmptrapd|snmpbulkget > (syslog|trap log) > parser > zabbix-sender.
Скрипт с snmpbulkget в главной роли я как-нибудь наваяю, и будет он пихать сендером данные в Заббикс.

Но это не приблизило меня к решению проблемы.

0. Трапы надо парсить.
1 .Что лучше парсить - syslog или логи? Если логи, то как лучше их форматировать (хотя понятно, что это зависит от парсера)?
2. Самое главное - чем парсить? Я не настолько крут в программировании (под линукс пишу скрипты на питоне), и на С++ точно не осилю. Потому и попросил пример, желательно в скриптовом виде, чтобы под свои нужды попытаться адаптировать.

Повторюсь, это меня и удивляет. Проблема массовая, но каждый делает свои костыли. Как-то не UNIX-way.

PS. Погуглил еще. Похоже, можно парсить трапы с помощью syslog-ng и получать на выходе JSON или syslog-formatted данные. Это уже интереснее - утилита парсинга уже есть .
Хм-м. Трапы из syslog-ng и результаты snmpbulkget из внешней проверки пихаем в zabbix-sender скриптом, который получает эти данные во входных параметрах.
Похоже это на решение моей проблемы?
Понятно, что программа лучше скрипта в плане быстродействия, но для начала-то сойдет? Или нет?

[oscar]

Я вообще с логами не заморачивался. Они мне были нужны только чтобы разобрать специфичные OID'ы. Сейчас у меня у меня snmptrapd при получении любого трапа запускает дочерний процесс (в данном случае мой парсер) и передает ему на stdin весь трап целиком. Парсер его разбирает, он же запихивает в заббикс, после чего завершает свою работу и процесс убивается. Если пишете на питоне, то этого более чем достаточно. Сам трап технически это набор строк, где каждая строка это ключ/OID - значение через пробел. В трапе нас интересует только IP от кого прилетел и значение нашего искомого OID'а. Они выдергиваются даже простенькими строковыми функциями...
Ну питон со stdin работает легко:

import sys
for line in sys.stdin:
    print line

p.s. Примерно тот же способ описан тут

[Evgeniy]

Я вообще с логами не заморачивался. Они мне были нужны только чтобы разобрать специфичные OID'ы

Любопытно, а почему не стали использовать snmptt (exec)?
И трапы красивее бы были и мудрить не пришлось..
И вообще, имхо, тема о том, "как из пушки по воробьям стрелять", вот массового решения и не нашлось =)