трапы

[martcell]

Приветствую, прошу указания, куда копать. Стоит задача получать трапы с сетевого оборудования. Вроде бы настроил как должно через zabbix_trap_receiver.pl, тзаббикс трапы видит, но не могу понять, как правильно их форматировать для дальнейшего создания триггеров. В базу они падают в виде

18.07.2017 17:28:57		
17:28:56 2017/07/18 PDU INFO:
  requestid                      20188
  community                      itws
  transactionid                  14
  errorstatus                    0
  receivedfrom                   UDP: [10.26.11.6]:65339->[10.26.10.21]:162
  notificationtype               TRAP
  messageid                      0
  errorindex                     0
  version                        1
VARBINDS:
  iso.3.6.1.2.1.1.3.0            type=67 value=Timeticks: (147358478) 17 days, 1:19:44.78
  iso.3.6.1.6.3.1.1.4.1.0        type=6  value=OID: iso.3.6.1.6.3.1.1.5.4
  iso.3.6.1.2.1.2.2.1.1.10045    type=2  value=INTEGER: 10045
  iso.3.6.1.2.1.2.2.1.2.10045    type=4  value=STRING: "FastEthernet0/45"
  iso.3.6.1.2.1.2.2.1.3.10045    type=2  value=INTEGER: 6
  iso.3.6.1.4.1.9.2.2.1.1.20.10045 type=4  value=STRING: "up"

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

[wins]

Привет.
Какой айтем используешь?

Попробуй начать с простого айтема:

snmptrap["SNMPv2-MIB::coldStart"]

и триггера:

{tpl_name:snmptrap["SNMPv2-MIB::coldStart"].nodata(5m)}=0

[anG]

Приветствую, прошу указания, куда копать. Стоит задача получать трапы с сетевого оборудования. Вроде бы настроил как должно через zabbix_trap_receiver.pl, тзаббикс трапы видит, но не могу понять, как правильно их форматировать для дальнейшего создания триггеров. В базу они падают в виде

18.07.2017 17:28:57		
17:28:56 2017/07/18 PDU INFO:
  requestid                      20188
  community                      itws
  transactionid                  14
  errorstatus                    0
  receivedfrom                   UDP: [10.26.11.6]:65339->[10.26.10.21]:162
  notificationtype               TRAP
  messageid                      0
  errorindex                     0
  version                        1
VARBINDS:
  iso.3.6.1.2.1.1.3.0            type=67 value=Timeticks: (147358478) 17 days, 1:19:44.78
  iso.3.6.1.6.3.1.1.4.1.0        type=6  value=OID: iso.3.6.1.6.3.1.1.5.4
  iso.3.6.1.2.1.2.2.1.1.10045    type=2  value=INTEGER: 10045
  iso.3.6.1.2.1.2.2.1.2.10045    type=4  value=STRING: "FastEthernet0/45"
  iso.3.6.1.2.1.2.2.1.3.10045    type=2  value=INTEGER: 6
  iso.3.6.1.4.1.9.2.2.1.1.20.10045 type=4  value=STRING: "up"

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

В статьях написаны очень "легкие" варианты трапов. На деле же они могут быть очень различными и весьма большими.
Кстати, в обобщенном варианте вы никогда не узнаете, каким по счету параметром будет нужное вам "up" или "down" (трапы удобны не только для сетевой темы) Например, наш с оборудования DPI:

17:31:52 UDP: [10.192.200.54]:42334->[10.192.161.15]:162 UDP: [10.192.200.54]:42334->[10.192.161.15]:162 DISMAN-EXPRESSION-MIB::sysUpTimeInstance 67:12:53:25.14 SNMPv2-MIB::snmpTrapOID.0 SANDVINE-SPB-APP-MIB::svSpbAppScsProgressSummaryLagNotification SANDVINE-MIB::svClusterConfigName.0 SANDVINE-1 RFC1213-MIB::sysName.0 "name_of_server" SANDVINE-MIB::svSeverity.0 minor SANDVINE-SPB-APP-MIB::svSpbAppScsProgressSummaryMaxLag.0 1271229

Этот трап сообщает о проблеме svSpbAppScsProgressSummaryLagNotification и важность трапа в классификации самого оборудования minor


19:31:52 UDP: [10.192.200.54]:42334->[10.192.161.15]:162 UDP: [10.192.200.54]:42334->[10.192.161.15]:162 DISMAN-EXPRESSION-MIB::sysUpTimeInstance 67:14:53:24.69 SNMPv2-MIB::snmpTrapOID.0 SANDVINE-SPB-APP-MIB::svSpbAppScsProgressSummaryOkNotification SANDVINE-MIB::svClusterConfigName.0 SANDVINE-1 RFC1213-MIB::sysName.0 "name_of_server" SANDVINE-MIB::svSeverity.0 cleared SANDVINE-SPB-APP-MIB::svSpbAppScsProgressSummaryMaxLag.0 11232.

Этот трап сообщает о решении вышеуказанной проблемы. Главное для нас svSpbAppScsProgressSummaryOkNotification (ок notification)

Наше оборудование "умное" - оно шлет трапы и подтверждения о том, что проблема устранена. На основании вот этих слов (svSpbAppScsProgressSummaryLagNotification и svSpbAppScsProgressSummaryOkNotification) мы и парсим. Ну и триггеры, соотвественно, завязаны на них.

Не всякое оборудование обладает таким интеллектом- кто-то просто шлет трапы, но не шлет подтверждения об устранении неполадки. Для таких трапов нужен вариант ручного "погашения" триггеров.

Для начала вам все-таки стоит заменить численные оиды (iso.3.6.1.4.1.9.2.2.1.1.20.10045 type=4 value=STRING: "up") на буквенные (это нужно на сервер закинуть мибы от вашего оборудования). А потом уже посмотрите, что да как.
Лично у нас используется парсинг именно по "ключевым" для нас словам из самого трапа. И у нас элемент данных, который попадает в заббикс- это сам целый трап, целая такая портянка. Будьте осторожны- такие портянки способны быстро забить БД. К сожалению, мы не придумали иного способа отлова и парсинга трапов. Он не идеален, но для работы практичсеки любого оборудования вполне пригоден.