Ad Widget

Collapse

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

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

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

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

    Click image for larger version  Name:	les.png Views:	1 Size:	15.2 KB ID:	377841

    Соответственно, требуется, чтобы значение
    Code:
    SW-2212SDAM-MIB::out1.0
    , прилетающее в трапе, писалось в элемент данных out1.

    Летят трапы, обрабатываются перловым скриптом в Заббиксовский формат.:
    Code:
    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 опрашивать, и по трапу менять значение элемента данных?
    Думается мне что я далеко не первый на этом пути, и что все упрощающие жизнь утилиты для решения данного вопроса уже написаны. Но, видимо, я у Гугла не так спрашиваю.
    Потому и прошу помощи, уважаемые. Желательно с примером, как для альтернативно одарённого.
    Нашел бы сам - не стал бы вас по пустякам беспокоить.
    Last edited by omgiafs; 18-04-2019, 20:06.

    #2
    Originally posted by omgiafs View Post
    ...опросом по SNMP из трапа...
    Это как? Что-то меня от этой фразы переклинило... Это вроде как взаимоисключающие понятия...
    Можете прислать миб сей чудесной железки... Или сами откройте каким-нибудь миб браузером - многие вопросы отпадут...

    Comment


      #3
      Originally posted by oscar View Post
      Это как? Что-то меня от этой фразы переклинило... Это вроде как взаимоисключающие понятия...
      Можете прислать миб сей чудесной железки... Или сами откройте каким-нибудь миб браузером - многие вопросы отпадут...
      Там скобки есть. "изменение элемента данных (числовой элемент данных с опросом по SNMP) из трапа". Элемент данных, опрашивается по SNMP.
      А мне надо дополнительно чтобы из трапа значение в элемент данных писалось, а не весь трап в почти полностью бесполезный журнал трапов.

      Вы хочете песен? Их есть у меня... https://www.dropbox.com/s/8ljqk5482l...M-MIB.MIB?dl=1
      Last edited by omgiafs; 18-04-2019, 19:57.

      Comment


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

        Comment


          #5
          Originally posted by oscar View Post
          В элемент с типом проверки "SNMP агент" принудительно данные не загнать. Или заводите отдельный элемент с типом траппер, или меняйте тип у этого.
          Да, чтение https://www.zabbix.com/documentation/3.0/ru/manual/concepts/sender ясно дало понять, что тип элемента данных должен быть "траппер".
          И что, никак не изменить состояние элемента данных? Или опросом, или трапом, или создавать 2 элемента данных?

          Блин, это же так логично - опрашивать оборудование или получить от оборудования оповещение о внеплановом изменении параметра... Неужели за все эти годы никто не додумался до реализации этой логичной вещи?
          Last edited by omgiafs; 18-04-2019, 20:14.

          Comment


            #6
            Originally posted by omgiafs View Post
            Я ЗНАЮ, что так делают. ЭТО РАБОТАЕТ.
            Сторонней утилитой/скриптом парсится трап, значение посылается в Заббикс при помощи zabbix-sender.
            Эва как... Документация как бы намекает на обратное... Пробовали послать сендером элементу с типом Агент произвольное значение вручную?

            Comment


              #7
              Originally posted by oscar View Post
              Эва как... Документация как бы намекает на обратное... Пробовали послать сендером элементу с типом Агент произвольное значение вручную?
              Уже пофиксил

              Грустно это, от слова совсем. И что делать в конкретно этом случае? оставлять элемент "траппер"? Но тогда не узнаю состояние параметра, если трап не долетит... Оставлять только периодический опрос - не та специфика, надо отлавливать изменение как можно быстрее. Два элемента данных на один параметр? Это бред какой-то...
              Шо, нельзя в данном случае и рыбку съесть и сковородку не помыть?
              Last edited by omgiafs; 18-04-2019, 20:24.

              Comment


                #8
                Originally posted by omgiafs View Post
                Уже пофиксил

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

                Comment


                  #9
                  Хорошо, значит надо делать шиворот навыворот - элемент "траппер", в него сендером пихать результаты опроса внешней проверкой.
                  Суть остается та же: 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 скриптом, который получает эти данные во входных параметрах.
                  Похоже это на решение моей проблемы?
                  Понятно, что программа лучше скрипта в плане быстродействия, но для начала-то сойдет? Или нет?
                  Last edited by omgiafs; 19-04-2019, 07:10.

                  Comment


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

                    Comment


                      #11
                      Originally posted by oscar View Post
                      Я вообще с логами не заморачивался. Они мне были нужны только чтобы разобрать специфичные OID'ы
                      Любопытно, а почему не стали использовать snmptt (exec)?
                      И трапы красивее бы были и мудрить не пришлось..
                      И вообще, имхо, тема о том, "как из пушки по воробьям стрелять", вот массового решения и не нашлось =)

                      Comment

                      Announcement

                      Collapse
                      No announcement yet.
                      Working...
                      X