Мониторинг — что это и зачем нужен

Мониторинг — это непрерывный сбор, агрегация и анализ показателей работы системы, сервисов и пользовательских транзакций с целью раннего обнаружения проблем, понимания состояния системы и принятия обоснованных решений по эксплуатации. Он обеспечивает наблюдаемость (observability) — способность понять, что происходит внутри системы по её внешним сигналам (метрики, логи, трассы).

Задачи мониторинга

• детектировать деградацию и инциденты быстрее, чем их заметят пользователи;

• определить причину проблемы и сократить MTTR;

• отслеживать тренды и capacity planning;

• контролировать выполнение SLO/error budget;

• поддерживать безопасность и соответствие требованиям.

Типы мониторинга

• Инфраструктурный — CPU, память, диск, сеть на хостах и контейнерах.

• Приложенческий (application) — метрики внутри приложения: latency, error rate, queue length.

• Синтетический (synthetic / probing) — регулярные health-checks и скрипты, эмулирующие пользовательские сценарии.

• Реальный пользовательский мониторинг (RUM) — измерение опыта реальных пользователей (загрузка страниц, ошибки JS).

• Трейсинг — распределённые трассы для понимания задержек между сервисами.

• Логирование — агрегированные логи для поиска корневых причин.

Основные метрики, которые нужно отслеживать

• Availability (доступность) — доля успешных ответов/времени работы. Важна для SLO/SLA.

• Latency (задержка) — распределение ответов: p50, p95, p99 и максимум; важно измерять по отдельным вызовам/эндпоинтам.

• Error rate (ошибки) — доля 5xx/ошибочных транзакций; считать по сущностям, а не только по агрегатам.

• Throughput (пропускная способность) — запросы/сек, транзакции/сек; показывает нагрузку.

• Saturation (насыщение ресурсов) — проценты использования: CPU, memory, disk I/O, file descriptors, connection pools; сигнализирует о приближении к пределам.

• Queue depth / backlog — длина очередей задач/сообщений; рост часто предвестник деградации.

• Business metrics — критичные для бизнеса показатели: покупки, конверсии, активные пользователи; помогают понять бизнес-импакт инцидента.

• Custom health indicators — целевые SLIs (корректность данных, успешное подтверждение платёжных транзакций и т.д.).

Как правильно считать и алертить

• используйте percentiles (p95/p99) вместо среднего для latency;

• различайте сигнал симптома (например, резкий рост ошибок) и причину (падение БД); alert делайте на симптомы; уведомления на причину — для онколла/инженеров;

• настроьте степенчатые алерты (warning → critical) и burn-rate алерты для error budget;

• избегайте алерт-флуда: включайте debounce, suppression и группировку инцидентов.

Практические рекомендации

• документируйте определения метрик (что считается «успехом»);

• сочетайте синтетические проверки и RUM;

• сохраняйте сырой телеметрический поток для ретроспективы;

• контролируйте cardinality метрик (labels/tag) — слишком высокая кардинальность увеличивает стоимость и снижает производительность хранилища;

• тестируйте мониторинг (chaos / fault-injection) — убедитесь, что алерты срабатывают и playbook работает;

• визуализируйте ключевые SLO и error budgets на дашбордах для быстрых решений.

Мониторинг — не только инструменты, но и процесс: правильно выбранные и доверенные метрики позволяют не терять время на поиск причин и управлять стабильностью сервиса количественно.