Мониторинг IT-инфраструктуры 24/7: алерты о сбоях раньше жалоб клиентов

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

Обе истории про одно. Система заранее подавала сигналы: росла нагрузка, кончалось место, истекал сертификат. Только смотреть на них было некому. Мониторинг нужен ровно для этого: чтобы о проблеме первыми узнавали вы, а не ваши клиенты.

Почему мониторинг часто не работает

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

Поэтому после запуска мы две-три недели тюним пороги и правила. Убираем ложные срабатывания, склеиваем связанные события, разводим критичное и информационное. Это обычная часть работы, а не исправление чьего-то недосмотра. Подрядчик, который обещает «поставим Zabbix за день», просто отдаёт вам шум.

На чём строим

Берём инструменты с открытым кодом, они же стандарт отрасли. Вендорских лицензий тут нет, привязки к нам как к подрядчику тоже.

Zabbix хорошо закрывает классическую инфраструктуру: серверы, виртуальные машины, сетевое оборудование, инвентаризацию. Связка Prometheus и Grafana сильнее в современных окружениях: контейнеры, облака, приложения со своими метриками, а работают эти системы часто параллельно, и тогда Grafana становится общим экраном для обоих источников.

Что разворачивать у вас, зависит от состава инфраструктуры, а не от моды. Для пары серверов с сайтом и 1С кластерный стек мониторинга городить незачем. Мы и не будем.

Что настраиваем в Zabbix, Prometheus и Grafana

В Zabbix заводим хосты и шаблоны под ваши системы, ставим агентов, описываем триггеры с порогами и эскалацию. В Prometheus собираем метрики приложений и контейнеров, пишем правила алертов, подключаем Alertmanager с расписанием дежурств. В Grafana собираем экран для руководителя и отдельные доски для админа: сайт, базы, диски, интеграции.

Сам мониторинг ставим вне наблюдаемого контура. Иначе сервер падает вместе с тем, что должен был сторожить, и вы опять узнаёте о сбое от клиента.

Что попадает под наблюдение

• Доступность сайтов и сервисов снаружи: то, что видят клиенты. Заодно скорость ответа и то, что главные страницы открываются как надо.
• Ресурсы серверов: диски, память, процессор, нагрузка на базу. Пороги ставим так, чтобы они предупреждали заранее, а не сообщали об аварии.
• Сроки SSL-сертификатов и доменов. Просроченный сертификат стоит дня без заказов и звонков «у вас там красное окно про угрозу».
• Результаты резервного копирования. Бэкап не прошёл: придёт алерт, а не тишина. Три месяца молчаливых падений вскрываются ровно в день, когда копия нужна.
• Очереди интеграций: обмен сайта с 1С, выгрузки на маркетплейсы, отправка почты. Тут проблемы копятся молча, а платите вы остатками на витрине и штрафами площадки.
• Каналы алертов: Telegram, почта, при необходимости SMS. Разделяем заранее: что будит ночью, а что ждёт до утра.

Сколько это стоит и сколько занимает

• Старт на два-три сервера и сайт. От 60 тысяч рублей, одна-две недели до первых рабочих алертов. Разворачиваем систему, заводим хосты, настраиваем каналы и базовые пороги.
• Контур от десяти хостов с интеграциями. От 150 тысяч рублей, три-четыре недели. Добавляются метрики приложений, очереди обменов, дашборды по подразделениям.
• Сопровождение в рабочие часы. От 12 тысяч рублей в месяц: держим систему живой, правим пороги, разбираем сработки.
• Дежурство круглосуточно. От 35 тысяч рублей в месяц, с регламентом реагирования и правом что-то чинить ночью.

Отдельно считается место, где живёт мониторинг. Виртуальная машина у российского облачного провайдера обходится в пару тысяч рублей в месяц. Есть свободные мощности, поставим у вас и не возьмём за это ничего.

Как выглядит реагирование

Следим круглосуточно, это правда. А вот реакция на ночной алерт: отдельный вопрос, и его надо проговорить заранее. Кто просыпается, что он имеет право сделать, где лежат инструкции.

Вариант «алерт упал в общий чат, все спят» мы считаем самообманом. Поэтому предлагаем два честных формата.

• Рабочие часы. Будни с девяти до девятнадцати, реакция на критичный алерт до тридцати минут. Ночью алерт копится и ждёт утра. Многим компаниям этого хватает, и лучше это признать, чем изображать круглосуточный центр реагирования.
• Круглосуточное дежурство. Реакция до пятнадцати минут в любое время, дежурный по графику, заранее согласованный список действий: перезапустить сервис, почистить диск, поднять из бэкапа. Плюс телефон человека, которому звонят, если решение выходит за список.

Что именно мы вправе сделать сами, а что только с вашего звонка, записываем до старта. Это лист на одну страницу, а не договор на двадцать.

Что нужно от вас

• Доступы. Учётные записи на серверы, в панель хостинга или облака, к базам и к почтовому домену. Обычно это полдня работы вашего админа.
• Список критичного. Полчаса разговора о том, что для бизнеса «всё встало», а что потерпит до утра. Без этого разговора пороги придётся угадывать.
• Один ответственный с вашей стороны, который принимает алерты и решения. Общий чат в этой роли не работает.
• Контакты для ночных случаев, если берём дежурство. Кому звоним, когда сервис лежит, а согласованные действия не помогли.

Что вы получите

Дашборд, по которому состояние инфраструктуры читается за десять секунд. Алерты, которым можно верить. И историю метрик: если сайт «тормозил вчера вечером», вы увидите почему, а не будете гадать.

Растущему бизнесу это помогает ещё и планировать. Графики честно показывают, когда пора расширять сервер. Пока это не стало срочным.

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

Что происходит после запуска

Инфраструктура меняется, и мониторинг меняется вместе с ней. Появился новый сервер, переехал сайт, добавилась выгрузка на маркетплейс: всё это надо завести под наблюдение, иначе через год система следит за половиной хозяйства.

Дальше два пути. Есть свой админ, мы отдаём ему систему с документацией, показываем, как заводить хосты и править пороги, и остаёмся на связи для сложного. Своего человека нет, ведём сами: правим пороги, чистим ложные сработки, добавляем новое и раз в месяц отчитываемся.

Подводные камни из практики

Симптомы, а не причины. Мониторинг показывает, что болит. Чинить он не умеет. Диск заполняется каждую неделю: алерты будут исправно приходить каждую неделю, пока кто-то не разберётся, что его забивает. Мы разбираемся, но это уже сопровождение, и границу мы обозначаем заранее.

Мониторинг не заменяет бэкапы. Он честно скажет, что копия не создалась. Восстановит данные схема резервного копирования, а не график в Grafana. Эти две вещи работают в паре и настраиваются вместе.

С чего начать

Опишите задачу в форме ниже. Что нужно мониторить: серверы, сайты, интеграции. Где всё это размещено и как вы сейчас узнаёте о сбоях. Предложим состав мониторинга и формат реагирования под ваш режим работы.