Lev Goncharov

Infrastructure simplifying engineer

View My GitHub Profile

About monitoring

intro

Date: 2017-10-04

English version

Мониторинг работы оборудования и ключевого ПО — это азы системного администрирования. Но все мы постигаем их по-разному. За 10 лет работы в IT моё отношение к мониторингу прошло через три стадии:

Отрицание

Denial Всё началось давным-давно, в далёкой галактике. Я учился в университете и работал в двух местах «ты ж программистом»:

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

Моё отношение к мониторингу в то время можно охарактеризовать так:

К счастью, этот период продлился недолго — я начал подозревать, что здесь что-то не так, и бывает лучше.

Гнев

Anger

Под влиянием получаемого опыта начало меняться и моё видение мониторинга. Это процесс совпал со сменой работ. Уйдя из университета и производственной компании, я начал работать в не больших outstaffing фирмах:

К тому времени уже считал, что:

В то же время активно развивался и преображался инструментарий. Изначально была пачка скриптов, контролирующих всевозможные метрики (свободное место, количество доступных обновлений, результат работы бэкапов и так далее), а также сторонние сервисы Red Alert, Lazy Farmer (in-house разработка — попытка заменить сервис проверки сайтов).

В такой конфигурации система мониторинга существовала около года, но за это время выявилось много недостатков:

Встал вопрос, как упростить себе жизнь. Рассматривал варианты с Dude/Nagios/Zabbix. Основным критерием при выборе стала скорость развертывания, и выбор пал на Zabbix. В нём на мониторинг ставили всё, до чего дотягивались руки:

Отдельно хочу упомянуть про особенности внедрения и работы с 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? Кто будет мониторить мониторинг? Я так и не нашёл для себя ответа.

Смирение

Acceptance

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

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

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

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

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

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