Мониторинг головного мозга

Мониторинг работы оборудования и ключевого ПО — это азы системного администрирования. Но все мы постигаем их по-разному. За 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:

1. Серверы далеко, а метрик много. Когда начали появляться пропуски, внедрили Zabbix proxy.
2. При падении туннеля генерируется куча алертов о недоступности серверов, пришлось настраивать зависимости.
3. Мы автоматизировали однотипные действия при алертах: сначала система пробует починить самостоятельно (к примеру, почистить диск), и только в случае неудачи шлёт алерт. Чтобы уменьшить время реакции на алерт, мы настроили рассылку SMS.
4. Чтобы алерты не сыпались круглые сутки в виде SMS, не надо настраивать оповещения о том, что на сервере в течение 5 секунд CPU грузился на 100%.
5. При мониторинге сложных метрик из-за ресурсоёмкости процесса терялась часть значений. Хотя данные отправлялись серверу мониторинга, он не успевал всё регистрировать.
6. У Sphinx есть куча сервисов, состав которых может меняться. Новые серверы автоматически обнаруживаются и ставятся на мониторинг. Бывают ситуации, когда вебсервер запущен, но пользователь видит фигу вместо страницы. В подобных случаях мы прогоняли пользовательские сценарии на вебе, а в случае проблем система слала алерт.
7. Обычно заказчики хотят, что бы все задачи/проблемы отображались в одном месте, поэтому мы создавали задачу при возникновении критичного для бизнес-процессов события.
8. Сбор необработанных исключений долог и нуден, поэтому при возникновении события мы обрабатывали его в eventlog и создавали задачу.
9. Заказчики не читают писем, поэтому мы писали им в Skype (zabbix2skype).
   
10. Quis custodiet ipsos custodes? Кто будет мониторить мониторинг? Я так и не нашёл для себя ответа.

Смирение

Спустя несколько лет я пришёл к смирению. Опять же, этот период отчасти совпал со сменой места работы. Три ЦОДа, тысячи серверов, тысячи сотрудников, офисы по всей РФ, и не только.

Я понял для себя, что бизнес не интересует нагрузка на CPU и прочие технические подробности. Владельцы и управленцы мыслят другими категориями: время простоя/информационная система/потеря прибыли…

Zabbix мне нравился, но я увидел, что существуют другие системы (сторонние решения, сильно доработанные напильником, или самописные), которые плотно интегрируются с бизнесом заказчика.

Основные идеи, к которым я пришёл: Нужно объединять серверы в информационные систему, чтобы все видели одну и ту же картинку и понимали взаимосвязи.

1. Нельзя всё удержать в голове, должно быть хранилище знаний об инфраструктуре (кто ответственен за сервер, где что находится, и так далее).Необходимо упрощать и унифициовать настройку мониторинга (SNMP вместо агентов).
2. Важно, чтобы у системы мониторинга был дружелюбный интерфейс, позволяющий разобраться в ситуации даже не айтишникам.
3. Если информационная система не работает, это ещё не повод поднимать всех по тревоге в 3 ночи. Необходимо оговаривать с заказчиком допустимую продолжительность простоя и реакции.
4. Серебряной пули не существует — надо идти на компромиссы при выборе метрик для отслеживания, при создании правил уведомления, при автоматизации типовых действий и так далее.

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

UPD: English version