Мониторинг услуг на базе серверов

Горбушка

Горбушка

Ищу её...
Регистрация
2 Май 2008
Сообщения
3.444
Реакции
2.524
Столкнулся со следующей задачей, которую пока решить не получается...

Хостинг-компания имеет множество серверов, часть из которых в кластерах (отдельно обработчики, хранилища и база), часть отдельные (всё на 1 машине), а часть облачные (полноценное облако с авто-переездом с машины на машину и т.д.)...

Так вот, требуется всё это добро поставить на мониторинг, но не просто серверов, а именно услуг. Объясню:

У нас есть услуга "Хостинг сайтов", эта услуга размещена на кластере, в составе которого 2 обработчика, 2 хранилища и 2 базы. Кластер работает в режиме мастер-мастер.
Так вот, мне нужно мониторить не сами сервера, а услугу. То есть, если упал сервер базы данных - да, окрасить его в красный, а услугу в жёлтый. И инженеры понимают, что умер один из дублируемых узлов, критичность средняя, делают рассылку оповещения об ограничении и продолжают, к примеру, плановые работы, а к этому вернуться потом. А вот если упали оба сервера базы - то мы красим услугу уже в красный цвет и инженеры бросают все дела и бегут поднимать сервера баз данных, ибо услуга не оказывается. В идеале красить даже не услугу "Хостинг", а "MySQL", т.к. сайты на голом html продолжат работу...

К сожалению, из таких мониторингов знаю только HP BSM, но это дорогое и бесполезное ПО, сложное в обучении сотрудников и т.д. Кроме того, развернуть его в пределах хостинг-компании почти не реально ввиду количество серверов под мониторинг.

Увы, ни в nagios, ни в zabbix такого функционала не знаю... Сейчас мониторинг идёт на базе The dude, который свою задачу выполняет на ура, но красит сразу весь кластер, если падает хотя бы 1 сервер. А падение сервиса определяется по его падении на 1 из серверов... Что мягко говоря не устраивает...

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

Согласитесь, если отвалился один из серверов баз данных, а есть дублирующий, бросать на половину сваренную оптику не есть хорошо или отбирать инженера у клиента, которого он консультировал или помогал поднять сервер... А вот если сдохло всё хранилище в ДЦ - то VDS прыщавого подростка с сервером Minecraft спокойно может подождать - коровки на ферме у них за полчаса не передохнут...
 
Насколько понял из задачи, неоходимо мониторить сервисы с привязкой зависимостей? Посмотрите в сторону Для просмотра ссылки Войди или Зарегистрируйся.

Сам использую в проде, если есть вопросы, отвечу на какие смогу :)
 
Последнее редактирование:
Да, верно, нужны зависимости. И мониторинг больше нужен не самих серверов, а этих самых зависимостей.
Т.е. сдох сервер - это нормально, сдох диск - это тоже нормально. А вот сдох полностью сторадж - это труба-пичаль.

Увы, к сожалению, поздно предложили... Сделали кастомное решение на базе пары bash-скриптов и веб-обработчика с кроном...
 
Крайне не согласен с тем, что zabbix не умеет делать такие вещи, наоборот, в нём можно указать огромное количество метрик и событий, которые мы хотим мониторить и условия срабатываний тригерров.

Нужно мониторить сервис, - пожалуйста, выставляем проверку доступности БД ( ответ на порт, выбор тестовых данных). Если БД не отвечает, то это событие имеет disaster приоритет.
Отдельно сервера с БД? Составляем ещё одно событие на проверку, и в случае её срабатывание выставляем warning. Чтобы не было лишний событий можно привязаться условиями в trigger'ах на отказ основного сервиса.

Zabbix более чем подойдёт, правда разобраться в его логике и фишках несколько тяжеловато бывает.
 
Прочитайте задачу чуть внимательнее... Задача привязываться не к сервису, а услуге...
К примеру, есть у нас услу "MySQL" и стоит у неё 4 сервера - 2 кластера мастер-мастер...
Так вот, на падение 1 мастера мне всё равно. Мониторинг должен краснеть только при падении обоих серверов в рамках кластера.

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

если обращаемся по разным IP адресам к MySQL, то ставим условие в триггере, чтобы краснеем только при "когда лежат оба MySQL", когда не отвечает на порты по обоим серверам. ( пример -
{db1.zabbix.com:net.tcp.service[mysql].last(0)}=0&{db2.zabbix.com:net.tcp.service[mysql].last(0)}=0)
если обращаемся к MySQL через балансировщик вроде HAProxy и т.п., то мониторим "внешний" IP адрес.

это под описанный кэйс подпадает.

т.е. создаются события, по которым мониторим и в случае наступления ожидаемого уровня, идёт оповещение по выбранным каналам. Эти события можно вывести на дашборд заббикса.
 
Во! Вот это уже круто!
А можешь дать ссылочку на мануалы, написанные нормальным языком? Для обучения с нуля до написания таких кейсов =)
 
Zabbix и Cacti
куча плагинов, модулей и скриптом доя мониторинга чего угодно
снимаю показания со свичей, пк и серевров.

стоят обе системы, одна в одной конторе другая досталась в другой и была допилена до zabbix плющек )
 
Войдите или зарегистрируйтесь для ответа.
Назад
Сверху