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

[romale]

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

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

[bga83]

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

Если я правильнопонял, то сейчас в системе заведен целый ряд триггеров, ряд имеют значение для технических специалистов, а ряд для ИТ-руководства. В таком случае надо просто создать несколько действий с различными условиями. В одно будут попадать события технического плана, в другое ИТ-сервисного.
Как это сделать есть несколько вариантов. Можно просто в условия действия добавить проверка имен триггеров, или, по мне так предпочтительнее, создать несколько шаблонов и в условия действий добавлять проверку к какому шаблону относится сработавший триггер.

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

[romale]

Если я правильнопонял, то сейчас в системе заведен целый ряд триггеров, ряд имеют значение для технических специалистов, а ряд для ИТ-руководства.

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

[bga83]

В общем пока не понятно как отделить мух от котлет гуманным способом.

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

[romale]

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

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

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

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

[romale]

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

Нужно реализовать (как мне видится) следующее:
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}?), в котором находится например проблемный подсервис.
Это базисное описание того что надо сделать, чтобы можно было прикинуть примерные трудозатраты.

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

[romale]

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

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



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



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





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

[romale]

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





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



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




Если интересен функционал в этом направлении, просьба голосовать:

https://support.zabbix.com/browse/ZBXNEXT-2253

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

[romale]

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

[romale]

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

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

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

upd. 20140517
Ошибка исправлена, пакет можно пробовать