Как организовать мониторинг ИТ-инфраструктуры: какие показатели нужно контролировать в первую очередь

Мониторинг ИТ-инфраструктуры начинается не с установки очередного агента, а с ответа на простой вопрос: как понять, что сервис действительно работает для пользователя? В первую очередь нужно контролировать доступность, время отклика, ошибки, загрузку ключевых ресурсов и состояние зависимостей. Одних графиков загрузки процессора недостаточно: сервер может выглядеть «здоровым», пока приложение уже теряет заказы, не принимает платежи или отвечает по 20 секунд.

Практичная система наблюдения строится в несколько слоёв. Сначала отслеживаются внешние симптомы - доступность сайта, API и критических операций. Затем проверяются приложения, базы данных, очереди, виртуальные машины, контейнеры, сети и физические узлы. Такой подход помогает быстро отделить причину сбоя от его последствий: например, увидеть, что медленный интерфейс вызван не самим веб-сервером, а заблокированными запросами к базе данных.

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

Если инфраструктура включает веб-приложения, мобильный бэкенд или API, полезно использовать российское решение для мониторинга приложений, которое позволяет смотреть не только на состояние серверов, но и на пользовательские операции, ошибки и задержки на отдельных этапах запроса.

Какие показатели контролировать в первую очередь

1. Доступность и успешность операций

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

Для каждой проверки фиксируются HTTP-код, время ответа, факт успешного завершения операции и текст ошибки. Внутренний health-check обычно должен быть проще пользовательского сценария: он подтверждает, что процесс запущен и основные зависимости доступны. Синтетический тест, напротив, показывает, работает ли сервис с точки зрения клиента.

Доступность следует считать не по числу успешных ping, а по доле успешно выполненных критичных операций. Если в течение часа из 10 000 запросов 200 завершились ошибкой, показатель успешности составит 98%, хотя сервер большую часть времени формально был доступен.

2. Время отклика и задержки

Среднее время ответа часто скрывает проблему. Десять быстрых запросов по 100 миллисекунд и один запрос длительностью 15 секунд дадут приемлемое среднее значение, но именно этот медленный запрос может быть критичным для пользователя. Поэтому в работе используют перцентили: p50 показывает медианное время, p95 - задержку, хуже которой оказываются 5% запросов, а p99 - наиболее тяжёлый хвост.

Порог зависит от типа сервиса. Для внутренней панели управления задержка в 1–2 секунды может быть терпимой, а для проверки платёжного статуса даже несколько сотен миллисекунд добавляют задержку в цепочку операций. Важнее не универсальное число, а собственная базовая линия: нормальные значения в обычной нагрузке и характер отклонений в часы пиков.

3. Ошибки приложения

Количество исключений, ответов 4xx и 5xx, неуспешных фоновых задач и отменённых транзакций нужно разделять. Рост 404 может быть следствием неправильной ссылки или устаревшего клиента, тогда как 500 обычно требует немедленной диагностики на серверной стороне. Ошибки авторизации, тайм-ауты внешних API и отказы базы данных также стоит считать отдельно: одна общая линия «ошибки» плохо помогает при поиске причины.

К каждой ошибке желательно привязывать версию приложения, endpoint, окружение, идентификатор корреляции и обезличенный контекст запроса. Логи без correlation ID превращают расследование в ручной поиск по временным меткам. При этом в систему мониторинга нельзя отправлять пароли, токены, полные номера карт и другие чувствительные данные.

Практическое правило: уведомление должно содержать не только факт сбоя, но и масштаб проблемы: сколько запросов затронуто, какой endpoint неисправен, когда началось отклонение и что уже проверено автоматически.

Ресурсы серверов: что действительно имеет значение

Метрики CPU, памяти и диска остаются необходимыми, но сами по себе редко объясняют поведение системы. Загрузка процессора 90% может быть нормальной для вычислительного сервиса, если задержки стабильны. А 40% CPU на сервере базы данных не исключают блокировок, нехватки оперативной памяти или медленного хранилища.

Для процессора стоит смотреть не только на общий процент, но и на load average, steal time в виртуальной среде, iowait и распределение нагрузки по ядрам. Для памяти важны доступный объём, swap activity, page faults и давление на память в контейнерной среде. Наличие свободных гигабайт не всегда означает отсутствие проблемы: операционная система может использовать память под кэш, а приложение уже сталкиваться с лимитом cgroup.

Для дисков критичны свободное место, latency операций чтения и записи, IOPS, throughput и процент времени занятости устройства. Заполнение файловой системы выше 85–90% часто становится не мгновенной причиной сбоя, а опасным фоном: прекращается запись логов, не создаются временные файлы, ломается ротация или резервное копирование.

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

Базы данных, очереди и внешние зависимости

Мониторинг базы данных должен отвечать на вопрос «почему запросы стали медленнее», а не только сообщать о доступности порта. Важны длительные запросы, p95 времени выполнения, количество активных соединений, ожидания блокировок, cache hit ratio, рост таблиц, задержка репликации и состояние резервного копирования.

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

Для брокеров сообщений контролируются длина очереди, возраст самого старого сообщения, скорость поступления и обработки, число повторных доставок, ошибки consumer и объём dead-letter queue. Если очередь растёт, но приложение формально отвечает, пользовательская проблема может проявиться спустя минуты - например, письмо не отправится вовремя, а платёжный статус обновится с задержкой.

Внешние поставщики - платёжные шлюзы, сервисы доставки, SMS-провайдеры и государственные API - должны рассматриваться как самостоятельные зависимости. Полезно измерять их доступность, тайм-ауты и долю ошибок по каждому интеграционному каналу. Это позволяет отличить собственный сбой от аварии у партнёра и не тратить время на перезапуск исправных компонентов.

Как настроить мониторинг без лишнего шума

Начинать лучше с карты сервисов. Для каждого бизнес-процесса фиксируются входная точка, основные компоненты, хранилища данных, внешние интеграции и ответственные команды. Затем выбираются 3–5 ключевых сигналов: доступность, ошибки, задержка, насыщение ресурсов и состояние зависимости.

1. Опишите критичные пользовательские сценарии. Например, вход в систему, поиск товара, создание заказа и получение статуса платежа.
2. Назначьте базовые значения. Соберите данные хотя бы за несколько обычных рабочих дней, чтобы видеть сезонные и суточные колебания.
3. Разделите уровни уведомлений. Warning предупреждает о тренде, Critical требует реакции сейчас, а информационные события не должны будить дежурного.
4. Свяжите алерты с действиями. Для каждого критического сигнала добавьте короткую инструкцию: что проверить, где посмотреть логи и при каких условиях эскалировать инцидент.
5. Проверьте мониторинг отказом. Без тестовой остановки, задержки или искусственной ошибки невозможно убедиться, что уведомление действительно приходит и содержит полезные данные.

Отдельно стоит контролировать качество самого мониторинга. Агенты могут остановиться, метрики - перестать поступать, а уведомления - попасть в неработающий канал. Отсутствие данных нельзя автоматически считать нормальным состоянием. Для этого вводят heartbeat, проверку свежести метрик и тестовые уведомления.

Критический совет: не ставьте алерт на единичный пик, если он не связан с пользовательским ущербом. Используйте длительность отклонения, процент ошибок, количество затронутых запросов и несколько взаимосвязанных сигналов.

Памятка перед запуском

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

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

Итоги

Хороший мониторинг показывает не просто состояние серверов, а путь от пользовательского запроса до результата. Приоритет стоит отдавать доступности реальных операций, перцентилям задержки, ошибкам, очередям, состоянию базы данных и внешних зависимостей. Ресурсные показатели помогают найти причину, но не заменяют контроль бизнес-сценариев.

Начните с нескольких критичных процессов, настройте измеримые пороги, свяжите каждый алерт с конкретным действием и только затем расширяйте покрытие. Такой подход даст меньше шума, быстрее расследование и более честное понимание того, что происходит в инфраструктуре. Если в вашей практике уже есть удачные правила мониторинга или, наоборот, неудачные настройки алертов, ими стоит поделиться - на таких примерах лучше всего видно, какие показатели действительно работают.