Серверный мониторинг

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

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

Как мы работаем

1. Определяем, что критично. Разбираемся, отказ чего именно означает потерю денег: оплата, форма заявки, личный кабинет, обмен с внешней системой. Мониторим бизнес-функции, а не только сервер.
2. Проверки по сценариям. Настраиваем не только пинг доступности, но и прохождение ключевых путей: тестовый заказ, отправка формы, вход в кабинет.
3. Метрики инфраструктуры. Процессор, память, диск, время ответа, коды ошибок, состояние очередей и фоновых задач. Сюда же — свободное место, которое роняет системы чаще, чем принято думать.
4. Каналы оповещения. Настраиваем маршруты: что уходит в Telegram, что дублируется на почту, что должно звонить ночью. Разные уровни аварий будят разных людей.
5. Настройка порогов. Самая долгая часть. Пороги подбираются по реальным данным за несколько недель, чтобы алерты срабатывали на проблемы, а не на обычные колебания нагрузки.
6. Логи и разбор. Собираем логи в одно место, чтобы после инцидента было где искать причину. Заводим шаблон постмортема — короткий разбор каждой аварии.

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

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

Настройка мониторинга — разовая работа: мы поднимаем систему и передаём её вам. Если нужен не только мониторинг, но и человек, который реагирует на его сигналы, это техническая поддержка с дежурным инженером и SLA. Для приложений с фоновыми задачами и очередями смотрите поддержку веб-приложений.

Сроки

Базовая настройка занимает от нескольких дней до недели: проверки доступности, метрики, каналы оповещения. Потом идёт период калибровки — две-три недели наблюдения, за которые пороги доводятся до состояния, когда алерты не врут. Этот этап пропускать нельзя: непрокалиброванный мониторинг быстро превращается в шум, который отключают.

Пример из практики

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