Ad Widget

Collapse

Итем в имени прототипа триггера или двойной snmpindex

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Lurker
    Member
    • Nov 2016
    • 83

    #16
    При выполнении условий триггера создаётся событие "триггер перешёл в состояние ПРОБЛЕМА" и генерируется собственно проблема, имя которой наследуется от триггера.
    если всё происходит ИМЕННО ТАК, то значит возникает следующая проблема:
    триггер срабатывает по одному из двух условий на 2 разных итема, но в название триггера идёт только первый итем.
    Соответственно если проблема по второму итему вылезет до того как опросится первый, то событие создастся с кривым именем. Но я попробую это костылями поправить.

    если для создания прототипа триггера вам всё же требуется предобработанный индекс (например, от имеющегося индекса в формате "X.Y" откусывать только часть "X"), то это можно сделать с помощью предобаботки на уровне правила LLD
    а какой смысл? если я уже регекспом режу его непосредственно в OID итема. А предобработка, несмотря на то, что она называется предобработкой, всё равно похоже выполняется ПОСЛЕ дискавера.(что логично т.к. что обрабатывать, пока дискавер не прошёл)
    Если вы таки покажете пример того, что возвращается вашим правилом дискаверинга
    Так я же показал в сообщении в 14:12

    Прикольное оборудование:
    я с вами соглашусь. Но это циска. Я подозреваю такое сделанно для совместимости с каким-то экзотическим оборудованием или ситуациями. В примере с процессором такое будет если одно и то-же место ЦП будут проверять несколько датчиков температуры.

    Comment

    • Lurker
      Member
      • Nov 2016
      • 83

      #17
      Добавил в триггер проверку на nodata для итемов, так что проблема не создаётся до того, как все итемы будут опрошены. Ну и следовательно я могу в имя проблемы пихать {ITEM.VALUE<1-9>}
      Проблема решена.

      Comment

      Working...