Infrastructure monitoring

Что наблюдаем

Infrastructure monitoring собирает числовые показатели состояния ресурсов и запущенных сервисов: вычислительных узлов, контейнеров, баз данных, очередей, сети и зависимостей платформы.

Типовые группы:

• утилизация — CPU, память, диск, пулы соединений;
• насыщение — очереди, диск I/O, сеть, worker capacity;
• ошибки — сбои диска, соединений, health checks и зависимостей;
• задержка — ответ БД, внешнего API, очереди или HTTP-сервиса;
• состояние — доступность реплик, restart count, certificate expiry, лимиты.

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

Сбор телеметрии

В экосистеме Prometheus показатели публикуются в формате метрик и собираются с targets напрямую или через exporters. Запросы и правила записываются на PromQL.

OpenTelemetry Collector получает, обрабатывает и экспортирует телеметрию через receivers, processors и exporters. Он помогает строить переносимый конвейер между источниками и backends.

Выбор источника зависит от слоя: node/host metrics, runtime, контейнеры, приложение, управляемая БД или внешний API. Важно документировать, откуда пришла метрика и что именно она измеряет.

Time series и cardinality

Time series обычно определяется именем метрики и набором labels:

http_requests_total{service="checkout",env="prod",status="500"}

Labels позволяют срезать данные по сервису, окружению и региону. Но каждая уникальная комбинация создаёт отдельный ряд. Cardinality explosion возникает, когда в label попадают user ID, request ID, URL с параметрами или другие значения с высокой вариативностью.

Поэтому в labels помещают ограниченные аналитические измерения, а уникальный контекст запроса — в логи и трассы.

Дашборды и оповещения

Дашборд строится от вопроса:

• «не заканчиваются ли ресурсы» — capacity и saturation;
• «какой сервис деградировал» — request rate, errors, duration;
• «что изменилось» — сравнение периода и релизов;
• «где узкое место» — разбивка по сервису, узлу, зависимости.

Alerting может использовать фиксированные пороги, отсутствие данных, изменение тренда или anomaly detection. Аномалия — не автоматически инцидент: важны влияние на пользователя, устойчивость и контекст.

Минимальная схема внедрения

1. Определить сервисы и критичные зависимости.
2. Собрать базовые host/container и application metrics.
3. Добавить RED-показатели для request-driven сервисов.
4. Ограничить labels и проверить стоимость хранения.
5. Создать дашборды по сценариям диагностики, а не по всем доступным графикам.
6. Настроить actionable alerts и runbooks.

Типовые ошибки

• Сбор всех доступных метрик без владельца и вопроса.
• User ID или полный URL в labels.
• Панель CPU используется как единственный показатель здоровья.
• Нет отдельного сигнала об отсутствии самой метрики.
• Дашборд показывает инфраструктуру без связи с релизом и пользовательским сценарием.

Связанные инструменты

• Prometheus — сбор time series, PromQL и alerting rules.
• Grafana — визуализация и исследование метрик.
• OpenTelemetry — переносимый сбор и экспорт.
• Better Stack — метрики, дашборды и оповещения.

Связанные материалы

• Uptime monitoring — внешний срез доступности.
• Tracing — детализация запросов между сервисами.
• SLI, SLO и SLA — пользовательские показатели надёжности.

Материалы и источники

• Prometheus: Overview — модель time series, targets и PromQL.
• OpenTelemetry: Metrics — метрики и их роль в телеметрии.
• Better Stack: Infrastructure monitoring — пример OpenTelemetry/Prometheus-native контура.