Ad Widget

Collapse

Обмен опытом. Наиболее оптимальные вариа

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • timon_is_timon
    Senior Member
    • Dec 2012
    • 117

    #1

    Обмен опытом. Наиболее оптимальные вариа

    Всем привет. Хотелось бы узнать у кого как организована структура мониторинга. Структура в плане - по какому признаку группы, темплейты, зависимости триггеров.

    У меня на данный момент так: есть грубо говоря компания с 5 удаленными подразделениями. Между ними туннели. Мониторится все пока что одним заббикс сервером порядка 7200 элементов и 100 хостов. узлы разделены в группы:
    1 - по принадлежности к структурному подразделению (чтобы было удобно отправлять сообщения админу данного подразделения)
    2 - по типу устройства - роутеры, серверы, свитчи, принтеры и тп
    для сетевых устройств есть темплейт snmp с обнаружением и т.п. для винды то же самое, и для принтеров.

    Основной затык у меня сейчас с зависимостями..пытаюсь сделать так, чтобы когда падает роутер головного подразделения приходило сообщение только о нем и все....делаю зависимость...имитирую его падение...все ок пришло сообщение о его падении....но! стоит мне восстановить связь с ним...приходит сообщение о том что он стал ОК...и 50 сообщений о том что хосты за ним лежат....и сразу следом 50 сообщений о том что эти хосты стали ОК (Очередей более 15 секунд как правило не бывает)

    Сейчас столкнулся с той трудностью что надо делать зависимости триггеров, делать прокси в подразделениях. Делитесь опытом как лучше все организовать чтобы и зависимости правильно работали и прокси просто админить и т.п. в общем как то так))
  • OttoV
    Junior Member
    • Jul 2014
    • 14

    #2
    Originally posted by timon_is_timon
    Основной затык у меня сейчас с зависимостями..пытаюсь сделать так, чтобы когда падает роутер головного подразделения приходило сообщение только о нем и все....делаю зависимость...имитирую его падение...все ок пришло сообщение о его падении....но! стоит мне восстановить связь с ним...приходит сообщение о том что он стал ОК...и 50 сообщений о том что хосты за ним лежат....и сразу следом 50 сообщений о том что эти хосты стали ОК (Очередей более 15 секунд как правило не бывает)
    Точно такое же поведение с зависимостями, недавно создавал тему:
    Code:
    Проблема в том, что если в компании надолго пропадает интернет, то в почту приходят уведомления вроде таких (время отправки сохранено):
    - Проблема: пропал интернет (12:15)
    - ОК: пропал интернет (13:10)
    - Проблема: недоступен хост Server (13:11)
    - ОК: недоступен хост Server (13:11)
    Наверное, это не лечится.

    Comment

    • Jimson
      Senior Member
      • Jan 2008
      • 1327

      #3
      В общем случае это лечится гистерезисом. Нужно "отложить" возвращение триггера в нормальное состояние (ok) на такой интервал времени что бы все зависимые от него триггеры успели обновить свое значение.

      Comment

      • yukra
        Senior Member
        • Apr 2013
        • 1359

        #4
        Мой опыт: уведомления использую только как сигнал "Что то пошло не так", что именно - смотрю в веб-интерфейсе, то что иногда приходит несколько уведомлений по одной проблеме воспринимаю по принципу "лучше перебдеть чем недобдеть"

        Comment

        • timon_is_timon
          Senior Member
          • Dec 2012
          • 117

          #5
          Originally posted by Jimson
          В общем случае это лечится гистерезисом. Нужно "отложить" возвращение триггера в нормальное состояние (ok) на такой интервал времени что бы все зависимые от него триггеры успели обновить свое значение.
          ХМ а ведь это мысль... прочитал про гистерезис в мануале...и почти нихера не понял.

          Есть к примеру триггер{template:icmppingsec[,10,500,32,1000,avg].last(1m)}=0 как его нужно переделать чтобы он возвращался в ок не моментально а допустим через 30 секунд успешных опросов или типа того.

          пишу так: ({TRIGGER.VALUE}=0&{template:icmppingsec[,10,500,32,1000,avg].last(1m)}=0)| ({TRIGGER.VALUE}=1&{template:icmppingsec[,10,500,32,1000,avg].last(1m)#0}) выдает ошибку:
          Некорректное выражение триггера. Проверьте часть выражения начиная с "&{Kemoil_Amp_router_ping:icmppingsec[,10,500,32,1000,avg].last(2m)#0})".
          Last edited by timon_is_timon; 18-08-2014, 12:54.

          Comment

          • Jimson
            Senior Member
            • Jan 2008
            • 1327

            #6
            Originally posted by timon_is_timon
            ХМ а ведь это мысль... прочитал про гистерезис в мануале...и почти нихера не понял.

            Есть к примеру триггер{template:icmppingsec[,10,500,32,1000,avg].last(1m)}=0 как его
            Во первых прочитать про гистерезис еще раз, там всего 1 абзац, на сколько я помню, и отличный пример с температурой. "Нихера не понять" там можно только "нихера не прочитав".

            Во вторых, вам нужно прочитать раздел про функции триггеров. И поводом к этому послужило две вещи: параметры функции last() игнорируются, это явно описано в документации, и как получить значение со сдвигом времени там тоже описано, для всех функций поддерживающих сдвиг.

            Comment

            Working...