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

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

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

На чём строим

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С чего начать

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