---
title: Infrastructure monitoring
description: "Мониторинг инфраструктуры: метрики ресурсов и сервисов, Prometheus, OpenTelemetry, cardinality, дашборды и оповещения."
---

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

**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:

```text
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](https://wpcraft.ru/kb/infrastructure/observability/alerting.md) может использовать фиксированные пороги, отсутствие данных, изменение тренда или 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](https://wpcraft.ru/kb/infrastructure/tools/prometheus.md) — сбор time series, PromQL и alerting rules.
- [Grafana](https://wpcraft.ru/kb/infrastructure/tools/grafana.md) — визуализация и исследование метрик.
- [OpenTelemetry](https://wpcraft.ru/kb/infrastructure/tools/open-telemetry.md) — переносимый сбор и экспорт.
- [Better Stack](https://wpcraft.ru/kb/infrastructure/tools/better-stack.md) — метрики, дашборды и оповещения.

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

- [Uptime monitoring](https://wpcraft.ru/kb/infrastructure/observability/uptime-monitoring.md) — внешний срез доступности.
- [Tracing](https://wpcraft.ru/kb/infrastructure/observability/tracing.md) — детализация запросов между сервисами.
- [SLI, SLO и SLA](https://wpcraft.ru/kb/infrastructure/sre/sli-slo-sla.md) — пользовательские показатели надёжности.

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

- [Prometheus: Overview](https://prometheus.io/docs/introduction/overview/) — модель time series, targets и PromQL.
- [OpenTelemetry: Metrics](https://opentelemetry.io/docs/concepts/signals/metrics/) — метрики и их роль в телеметрии.
- [Better Stack: Infrastructure monitoring](https://betterstack.com/infrastructure-monitoring) — пример OpenTelemetry/Prometheus-native контура.