Ad Widget

Collapse

Как получать алармы только от it сервисов?

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

    Как получать алармы только от it сервисов?

    Есть ли встроенные варианты или более-менее продуктивные сторонние?
    Идея в чем, есть ИТ сервис, и в случае возникновения сбоя, влияющиего на этот сервис, получать и/или отправлять по email аларм/сообщение только по ИТ сервису. Например в заббиксе заведены 2 web-хоста, которые образуют корневой "web-сервис"(с условием что у сервиса проблема, если у обоих web-серверов проблема). Соотв-но в ИТ сервисе "web-сервис" завел подсервисы с определенными триггерами внутри и задача: события технического плана отправлять инженерам техподдержки(и так отправляются), а события ИТ-сервисного плана отправлять ИТ-руководству. Как можно такое реализовать?

    И еще хорошо бы получать сообщения/алармы о нарушении SLA или скором нарушении SLA, не говоря уже про отчет о качестве ИТ-сервиса

    #2
    Originally posted by romale View Post
    Соотв-но в ИТ сервисе "web-сервис" завел подсервисы с определенными триггерами внутри и задача: события технического плана отправлять инженерам техподдержки(и так отправляются), а события ИТ-сервисного плана отправлять ИТ-руководству. Как можно такое реализовать?
    Если я правильнопонял, то сейчас в системе заведен целый ряд триггеров, ряд имеют значение для технических специалистов, а ряд для ИТ-руководства. В таком случае надо просто создать несколько действий с различными условиями. В одно будут попадать события технического плана, в другое ИТ-сервисного.
    Как это сделать есть несколько вариантов. Можно просто в условия действия добавить проверка имен триггеров, или, по мне так предпочтительнее, создать несколько шаблонов и в условия действий добавлять проверку к какому шаблону относится сработавший триггер.

    По sla особо не заморачивался. Просто на уровне идеи - посмотреть как реализован подсчет sla. Если подсчетом занимается сервер и периодически значения скидываются в базу, то оттуда значения в принципе можно вытягивать скриптом и организовать анализ стандартными средствами.

    Comment


      #3
      Originally posted by bga83 View Post
      Если я правильнопонял, то сейчас в системе заведен целый ряд триггеров, ряд имеют значение для технических специалистов, а ряд для ИТ-руководства.
      нет, сейчас (если про мой частный случай а не про архитектурные возможности/ограничения заббикса) все по умолчанию, т.е. все алармы от группы web-сервера, уходят и к технарям, и к руководству, т.к. указывать по отдельности алармы от триггеров (которые входят в web-сервис) и которые надо отправлять руководству из actions - это трудоемко поддерживать в актуальном состоянии и большая вероятность человеческого фактора (забыть какой-нибудь тригер указать в actions).
      В общем пока не понятно как отделить мух от котлет гуманным способом.
      Как-то логичным видится: создать в заббиксе ИТ сервис (ИТ сервис - это само по себе руководство-ориентированная область/модель) и иметь возможность в actions как-то указать, что с сервисными алармами (триггерами входящие в ИТ-сервисы) можно делать какие-то операции. В общем как-то идентифицировать сервисные алармы.

      Comment


        #4
        Originally posted by romale View Post
        В общем пока не понятно как отделить мух от котлет гуманным способом.
        как я уже писал, мне кажется разуиным в таком случае разнести по разным шаблонам и действия настраивать на основе шаблонов. В таком случае вероятность ошибки меньше, так как шаблонов ощутимо меньше чем серверов и найти время чтобы внимательно его настроить все же проще.

        Comment


          #5
          Originally posted by bga83 View Post
          как я уже писал, мне кажется разуиным в таком случае разнести по разным шаблонам и действия настраивать на основе шаблонов. В таком случае вероятность ошибки меньше, так как шаблонов ощутимо меньше чем серверов и найти время чтобы внимательно его настроить все же проще.
          если правильно понял, то это похоже не подойдет.
          т.к. при создании шаблона и применении его к хосту, стараюсь придерживаться наследования, то есть имеется базовый шаблон "template0", с items и порогами наиболее подходящими и полезными для большинства случаев (например для мониторинга линухов). Создается проект или появляется заказчик, которого надо мониторить, то под этот проект/заказчик создаю template1 и присоединяю к нему template0. Тем самым основной набор параметров мониторинга (items,triggers) уже готов (требуется меньше времени на изменения и мартышкин труд), далее подкручиваю некоторые параметры мониторинга template1 под инфраструктуру заказчика/проекта и все. Если в процессе работы накапливается какой-то опыт (тюнинг формул триггеров или новый параметр/способ мониторинга чего-либо), то это добавляю в template0 и это доступно в других дочерних шаблонах, т.о. не приходится ходить по всем шаблонам и добавлять/изменять (интерфейс заббикса и так требует слишком много клико-окошков). Напоминает классы в с++.

          при таком подходе наследования шаблонов, было бы полезным иметь возможность:
          1. менять параметры триггерам дочерних шаблонов (в данном случае без клонирования триггера и последующего его изменения)
          2. тригерам дочерних шаблонов "сказать" reset to parent/default

          На мой взгляд мухи это items+тригеры и возможность удобно ими манипулировать, а котлеты это ИТ сервисы и их алармы. Ну или наоброт, не важно.
          Ведь ит-сервисы определены, имеют в себе триггеры (уже условие child,parent), наверно не так сложно в коде реализовать принадлежность тригера сервису (которому добавить бы еще поле service_owner, service_customer и т.п.).

          Comment


            #6
            Требуется написать патч по теме за вознаграждение.
            Надеюсь не нарушаю правила форума.
            Условия (ожидаемая оплата и примерные сроки) через личку, тех детали реализации наверно можно пока тут обсудить.

            Нужно реализовать (как мне видится) следующее:
            1. в "Actions", в "New conditions" выбрать IT Service, выбрать нужный ит_сервис/ы (родительский и/или дочерний) и чтобы в Operations указав получателей, этим получателям отправлялись сообщения по триггерам из выбранных ИТ сервисов. Имя сервиса должно автоматически браться (создать макрос {SERVICE.NAME}?) из заббикса, ID сервиса тоже автоматически должен браться из заббикса ({SERVICE.ID}?). Так же на мой взгляд нужно получать через доп макросы имя и/или ID root (ID parent) сервиса ({SERVICE.ROOT.ID},{SERVICE.ROOT.NAME}, {SERVICE.PARENT.ID}, {SERVICE.PARENT.NAME}?), в котором находится например проблемный подсервис.
            Это базисное описание того что надо сделать, чтобы можно было прикинуть примерные трудозатраты.

            Тех реализация - обсуждаема, идеи приветствуются

            Comment


              #7
              Некоторая реализация

              Конфиг ИТ услуг(для проверки функционала патча):



              Действия (источник событий - ИТ Услуга):



              Настройка действия:





              продолжение в след ответе...

              Comment


                #8
                В продолжение этого поста





                Выключаем snmpd сервисы



                Получаем письмо




                Если интересен функционал в этом направлении, просьба голосовать:
                https://support.zabbix.com/browse/ZBXNEXT-2253

                Тут готовые пакеты для Altlinux
                ftp://89.112.11.193/repo/zabbix/

                Comment


                  #9
                  Немного подправили код, сейчас выглядит так:



                  Comment


                    #10
                    Доступны пакеты для OpenSUSE 12.3, 13.1
                    В продуктиве пока лучше не пользовать, т.к. еще полностью не протестировали.

                    https://build.opensuse.org/package/s...rom-ale/Zabbix

                    upd. 20140514
                    Ошибка в сборке пакетов, патч не применился. Исправляем

                    upd. 20140517
                    Ошибка исправлена, пакет можно пробовать
                    Last edited by romale; 17-05-2014, 20:38.

                    Comment

                    Announcement

                    Collapse
                    No announcement yet.
                    Working...
                    X