Ad Widget

Collapse

Зависимости триггеров в группах хостов.

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • sergeyarl
    Junior Member
    • Jul 2010
    • 24

    #1

    Зависимости триггеров в группах хостов.

    Всем привет!

    Предположим есть группа хостов. На всех хостах в группе через UserParameter сконфигурирована определенная метрика, которая возвращает примерно одинаковые значения на всех хостах.

    В случае превышения определенного трешхолда триггер, прикрепленный к этой метрике, выстреливает алерт. Т.к. значение метрики на всех хостах примерно одинаковое, то и триггеры на всех хостах срабатывают одновременно, выстреливая по алерту на хост.

    Соответсвенно вопрос - возможно ли настроить зависимости так, чтобы при срабатывании триггера, алерт выстреливался только для одного хоста в группе? Хотелось бы сконфигурировать это в темплейте, чтобы не настраивать на каждом новом хосте дополнительно.
  • aib
    Senior Member
    • Jan 2014
    • 1615

    #2
    Настроить зависимость одного триггера от других в конфигурации хоста можно. Но сложно.

    Настроить зависимость "шаблона" от другого "шаблона" нельзя. Особенно для Discovered элементов.
    Sincerely yours,
    Aleksey

    Comment

    • Semiadmin
      Senior Member
      • Oct 2014
      • 1625

      #3
      Похоже, вам нужны не зависимости, а Aggregate checks и триггеры для них.

      Comment

      • yukra
        Senior Member
        • Apr 2013
        • 1359

        #4
        Originally posted by semiadmin
        Похоже, вам нужны не зависимости, а aggregate checks и триггеры для них.
        Скорее всего человек нуждается в том, что бы "однотипные" триггеры в веб интерфейсе на разных хостах не занимали по одной строчке каждый, а сворачивались в одну строчку.

        Comment

        • Semiadmin
          Senior Member
          • Oct 2014
          • 1625

          #5
          Originally posted by yukra
          Скорее всего человек нуждается в том, что бы "однотипные" триггеры в веб интерфейсе на разных хостах не занимали по одной строчке каждый, а сворачивались в одну строчку.
          И эта цель достигается при помощи aggregate checks и триггеров для них.
          Заодно, в качестве бонуса.

          Comment

          • sergeyarl
            Junior Member
            • Jul 2010
            • 24

            #6
            Semiadmin, да, кажется это то, что мне нужно. спасибо.

            плохо правда пока представляю, что делать в этом случае с LLD. там же по сути придется создавать виртуальный хост и на него цеплять аггрегированные чеки.

            моя цель - чтобы алерты не валились для каждого хоста в кластере.

            вот представим, что есть какой-нибудь редис, или скуэль какой-нибудь.или лучше rabbitmq. кластер состоит из, скажем, 3 хостов. на каждом хосте настроено LLD для обнаружения новых очередей и, настроек трешхолдов для каждой rabbitmq очереди. и все это прекрасно работает.

            единственная проблема - если на rabbitmq очередь переполняется, то, т.к. в данный момент очереди реплицируются на все сервера кластера, то переполняется она на всех нодах. и тут приходит 3 алерта, вместо одного. с 3 серверами это не такая уж и проблема, но если серверов, скажем, 50, то проблема уже довольно серьезная, т.к. становится очень сложно разобраться во всем этом флуде.

            решить эту проблему действительно можно при помощи аггрегированных чеков. но как быть с LLD? сейчас на всех агентах настроены дискавери ключи. в случае с аггрегейт чеками наверное придется использовать zabbix_sender ? и при этом только с одного хоста? или возможно есть более элегантное решение?

            Comment

            • Semiadmin
              Senior Member
              • Oct 2014
              • 1625

              #7
              Самый простой способ - дать виртуальному хосту такой же ip, как у одной из нод. Дело в том, что соответствие имени хоста имени в zabbix agent критично только для айтемов типа Zabbix agent (active). Тогда можно использовать то же самое LLD, только с другими прототипами айтемов (типа Aggregate checks) и триггеров.
              Есть неудобство - в случае выхода из строя именно этой ноды придется оперативно менять ip виртуального хоста на ip одной из оставшихся. Если это проблематично - тогда да, sender со всех нод поочередно, а ip у виртуального хоста - как у zabbix server или proxy.

              Comment

              • sergeyarl
                Junior Member
                • Jul 2010
                • 24

                #8
                Подниму тему.

                В Заббиксе появились корреляции событий. Пытаюсь их как-то прикрутить. Но ими, насколько я понимаю, эту проблему не решить. Верно?

                Особенно настораживает в "известных проблемах"


                Глобальная корреляция событий События могут быть некорректно скоррелированы, если промежуток времени между первым и вторым событиями очень мал, к примеру пол секунды или меньше.

                Comment

                Working...