Мониторинг работы оборудования и ключевого ПО — это азы системного администрирования. Но все мы постигаем их по-разному. За 10 лет работы в IT моё отношение к мониторингу прошло через три стадии:
Отрицание. Ничего не мониторить, пользователи сами сообщат, когда у них возникнут проблемы.
Гнев. Мониторить всё, что можно и нельзя, оповещать всех, включая не очень заинтересованных лиц, что на веб-сервере в течение 30 секунд нагрузка на CPU была 95%.
Смирение. Бизнесу пофиг на процессор/память/диски. Его больше интересует, лучше или хуже стало после изменений в инфраструктуре. Надо работать на упреждение.
Под катом — подробности эволюции моего отношения.
Отрицание
Всё началось давным-давно, в далёкой галактике. Я учился в университете и работал в двух местах «ты ж программистом»:
- Торгово-производственная компания: три сервера, десять пользователей. На этих фотографиях вы видите серверную.
- Кафедра государственного университета: четыре сервера, сорок рабочих мест.
В то время я даже не подозревал о существовании такой штуки, как мониторинг. Я искренне считал, что если что-то сломается, то можно просто броситься грудью на амбразуру и героически решить проблемы.
Моё отношение к мониторингу в то время можно охарактеризовать так:
- Пользователи сами сообщат, когда что-то сломается.Мы сами постоянно работаем с сайтом, поэтому увидим, когда он сломался.На сервере перегружен процессор? Мне какое дело, программисты что-то там написали.
К счастью, этот период продлился недолго — я начал подозревать, что здесь что-то не так, и бывает лучше.
Гнев
Под влиянием получаемого опыта начало меняться и моё видение мониторинга. Это процесс совпал со сменой работ. Уйдя из университета и производственной компании, я начал работать в не больших outstaffing фирмах:
- В первой компании было три офиса, 100 пользователей, одна стойка в дата-центре и два системных администратора. Серверный парк состоял из 100 машин, расположенных в 5000 км от меня, а на хостинге было 1200 клиентов.
- Во второй компании было 400 серверов, до которых всего-то 12000 км, два корпоративных сайта и один системный администратор.
К тому времени уже считал, что:
- Мониторить нужно всё подряд. В том числе и то, что никому не нужно. Все события являются важными, и информацию о них нужно рассылать максимальному количеству человек. Включая начальство. По SMS. Ночью. Процессор на сервере в течение 35 секунд был загружен на 95%? Нет времени объяснять, необходимо срочно слать SMS!
В то же время активно развивался и преображался инструментарий. Изначально была пачка скриптов, контролирующих всевозможные метрики (свободное место, количество доступных обновлений, результат работы бэкапов и так далее), а также сторонние сервисы Red Alert, Lazy Farmer (in-house разработка — попытка заменить сервис проверки сайтов).
В такой конфигурации система мониторинга существовала около года, но за это время выявилось много недостатков:
- Многочисленные задержки в работе серверов из-за работы скриптов.
- Неизвестна утилизация ресурсов.
- Сложно найти источники проблем.
Встал вопрос, как упростить себе жизнь. Рассматривал варианты с Dude/Nagios/Zabbix. Основным критерием при выборе стала скорость развертывания, и выбор пал на Zabbix.
В нём на мониторинг ставили всё, до чего дотягивались руки:
- Количествво пользователей, подключенных к WiFi.
- Количество напечатанных на принтере страниц.
- Свободную память на маршрутизаторе.
- Количество VPN туннелей на маршрутизаторе.
- Температуру на серверах.
- Открытость крышки сервера.
- Загруженность сетевых интерфейсов коммутаторов.
- … и многое другое.
Отдельно хочу упомянуть про особенности внедрения и работы с Zabbix:
- Серверы далеко, а метрик много. Когда начали появляться пропуски, внедрили Zabbix proxy.
- При падении туннеля генерируется куча алертов о недоступности серверов, пришлось настраивать зависимости.
- Мы автоматизировали однотипные действия при алертах: сначала система пробует починить самостоятельно (к примеру, почистить диск), и только в случае неудачи шлёт алерт. Чтобы уменьшить время реакции на алерт, мы настроили рассылку SMS.
- Чтобы алерты не сыпались круглые сутки в виде SMS, не надо настраивать оповещения о том, что на сервере в течение 5 секунд CPU грузился на 100%.
- При мониторинге сложных метрик из-за ресурсоёмкости процесса терялась часть значений. Хотя данные отправлялись серверу мониторинга, он не успевал всё регистрировать.
- У Sphinx есть куча сервисов, состав которых может меняться. Новые серверы автоматически обнаруживаются и ставятся на мониторинг. Бывают ситуации, когда вебсервер запущен, но пользователь видит фигу вместо страницы. В подобных случаях мы прогоняли пользовательские сценарии на вебе, а в случае проблем система слала алерт.
- Обычно заказчики хотят, что бы все задачи/проблемы отображались в одном месте, поэтому мы создавали задачу при возникновении критичного для бизнес-процессов события.
- Сбор необработанных исключений долог и нуден, поэтому при возникновении события мы обрабатывали его в eventlog и создавали задачу.
- Заказчики не читают писем, поэтому мы писали им в Skype (zabbix2skype).
- Quis custodiet ipsos custodes? Кто будет мониторить мониторинг? Я так и не нашёл для себя ответа.
Смирение
Спустя несколько лет я пришёл к смирению. Опять же, этот период отчасти совпал со сменой места работы. Три ЦОДа, тысячи серверов, тысячи сотрудников, офисы по всей РФ, и не только.
Я понял для себя, что бизнес не интересует нагрузка на CPU и прочие технические подробности. Владельцы и управленцы мыслят другими категориями: время простоя/информационная система/потеря прибыли…
Zabbix мне нравился, но я увидел, что существуют другие системы (сторонние решения, сильно доработанные напильником, или самописные), которые плотно интегрируются с бизнесом заказчика.
Основные идеи, к которым я пришёл: Нужно объединять серверы в информационные систему, чтобы все видели одну и ту же картинку и понимали взаимосвязи.
- Нельзя всё удержать в голове, должно быть хранилище знаний об инфраструктуре (кто ответственен за сервер, где что находится, и так далее).Необходимо упрощать и унифициовать настройку мониторинга (SNMP вместо агентов).
- Важно, чтобы у системы мониторинга был дружелюбный интерфейс, позволяющий разобраться в ситуации даже не айтишникам.
- Если информационная система не работает, это ещё не повод поднимать всех по тревоге в 3 ночи. Необходимо оговаривать с заказчиком допустимую продолжительность простоя и реакции.
- Серебряной пули не существует — надо идти на компромиссы при выборе метрик для отслеживания, при создании правил уведомления, при автоматизации типовых действий и так далее.
Так, вкратце, эволюционировали представления о мониторинге как таковом, его задачах и способах реализации. Конечно, огромное влияние на этот процесс оказали условия, сложившиеся в компаниях, где я работал, и люди, трудившиеся вместе со мной.
UPD: English version
