Мониторинг сервисов

[shkiv]

Добрый день.
Помогите советом. Есть несколько вопросов.

1. Необходимо мониторить сервис в глобальном плане. Например, сервис ПриложениеХ. Оно состоит из базы данных, аппликейшн сервера, сервера обработки данных и т.п. Необходимо знать о падение всего сервиса, а не конкретных серверов.
Как я понял, в данном случае удобно создать группу узлов под названием Приложение Х, запихнуть туда все хосты необходимые для работы и повесить на них шаблоны, либо через другие группы, либо а каждый хост свой.
Прав ли я или есть какие-то более удобные способы?

2. Допустим есть core свитч, если он падает, то все что за ним становится недоступным. Можно ли сделать, чтобы в данном случае заббикс прислал только оповещение о падение свитча, и проигнорировал отсутствие пинга к 30и серверам за ним т.к. они завязаны на свитч? Можно ли где-то указывать зависимости одного объекта мониторинга от другого? Зависимости триггеров есть, но неужели, допустим, 30и триггерам надо указывать зависимость от 1го icmp ping?

Заранее спасибо за совет.

[Navoyenok]

Доброго времени суток, Shkiv.

Если я все верно понял, то есть некая сущность работа которой "размазана" по нескольким серверам (что обычное дело). Предлагаю воспользоваться для этой цели Monitoring\IT Services. Нарисуйте дерево IT сервисов (строиться это все в Configuration\IT Services, где-то лежит даже на сервере разработчки мануал, описывающий пример использования, но дума, что Вы и сами разберетесь методом проб и ошибок ) и в каждый из них можно "натаскать" триггеры из разных серверов.

С уважением, Navoyenok Sergey

[shkiv]

Спасибо за ответ.
Пробовал такой вариант.
НО... можно только оин триггер привязывать к сервису. И состояние только Ок или неОК... а хочется иметь уровни критичности.

[Navoyenok]

Уважаемый, shkiv.

1. Я бы создал в IT Services сервис "Приложение X" и туда собрал бы все триггеры, которые обеспечивают мониторинг работоспособности работы этого сервиса (но сделал бы это тоже с иерархией, например, создал бы подузел "БД" и т.д. ) и тогда в представлении "IT Services" можно будет мониторить весь сервис и если что то детально (там же) смотреть что случилось (какой триггер сработал). Еще раз хочу уточнить, что в IT Service как раз, наверное, и был сделан для этого, чтобы можно было создать логическое представление предоставляемых сервисов.

2. Реализовать это можно установив зависимость триггеров (почитайте это интересно), но важно чтобы триггеры, от которых зависит работа других триггеров срабатывал раньше). Скажу, что правильной работы зависимостей так добиться и не удалось. Всему виной различные механизмы против ложных срабатываний. Если их (эти механизмы) убрать, то беспокойств от заббикса будет больше, чем если случиться действительно какая-то авария.

Может у сообщества будут какие-нибудь рецепты для того как правильно организовать зависимости триггеров.

С уважением, Navoyenok

[oalex]

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

[shkiv]

Решили все-таки заморочиться с IT Services.
Спасибо за советы.