Мониторинг инфраструктуры

Мониторинг инфраструктуры

1) Цели и рамка

• Предупреждать о сбоях раньше пользователя (ранняя детекция).
• Давать диагностику первопричины (from symptom to cause).
• Поддерживать SLO-гейтинг релизов и авто-откаты.
• Кормить пост-инцидентный анализ (evidence as data).

Опорные принципы: Observable by design, меньше шума — больше сигналов, автоматизация реакций, единая панель правды.

2) Триада наблюдаемости

Метрики (timeseries): скорость/спрос/ошибки/насыщение (USE/RED).
Логи: событийная детализация с контекстом; не содержат секретов/PII.
Трейсы: распределенные обращения с причинно-следственными связями.

• Профилирование (CPU/heap/lock/io), eBPF для системного уровня.
• События/аудит (K8s Events, изменения конфигов/секретов).

3) SLI/SLO/SLA — язык качества

SLI (показатель): `availability`, `error_rate`, `p95_latency`, `queue_lag`.
SLO (цель): «успешные запросы ≥ 99.9% за 30 дней».
Error Budget: допустимое отклонение; используется для авто-стопа релизов.

yaml service: "api-gateway"
slis:
- name: success_rate query_good: sum(rate(http_requests_total{status!~"5.."}[5m]))
query_total: sum(rate(http_requests_total[5m]))
slo: 99. 9 window: 30d

4) Карта слоев мониторинга

1. Хосты/VM/узлы: CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem.
2. Сеть/LB/DNS: RTT, пакеты/дропы, backlog, SYN/Timeout, health-probes.
3. Kubernetes/Orchestrator: API-сервер, etcd, контроллеры, scheduler; поды/узлы, pending/evicted, throttling, kube-events.
4. Сервисы/контейнеры: RED (Rate/Errors/Duration), readiness/liveness.
5. Базы данных/кэши: QPS, lock wait, replication lag, buffer hit, slow queries.
6. Очереди/шины: consumer lag, requeue/dead-letter, throughput.
7. Хранилища/облако: S3/Blob ошибки и latency, 429/503 от провайдеров.
8. Границы периметра: WAF/Rate Limits, 4xx/5xx по маршрутам, CDN.
9. Синтетика: HTTP-проверки сценариев (депозит/вывод), TLS/сертификаты.
10. Экономика/емкость: cost per service, utilization, headroom.

5) Whitebox и Blackbox

Whitebox: экспортеры/SDK внутри сервисов (Prometheus, OpenTelemetry).
Blackbox: внешние пробы из разных регионов (availability, latency, TLS expiry).
Комбинируйте: «признак снаружи» + «диагностика внутри».

yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"

6) Kubernetes: ключевые сигналы

Кластер: `apiserver_request_total`, `etcd_server_has_leader`, etcd fsync.
Узлы: `container_cpu_cfs_throttled_seconds_total`, `node_pressure`.
Поды: Pending/CrashLoopBackOff, OOMKilled, рестарты.
Планы/лимиты: Requests vs Limits, PodDisruptionBudget, HPA/VPA.
Сеть: NetworkPolicy дропы, conntrack exhaustion.

Дашборды: «Cluster health», «Workload saturation», «Top erroring services».

7) БД и очереди

PostgreSQL/MySQL: replication lag, deadlocks, slow query %, checkpoint I/O.
Redis/Memcached: hit ratio, evictions, rejected connections.
Kafka/RabbitMQ: consumer lag, unacked, requeue, broker ISR, disk usage.

8) Метрики RED/USE и бизнес-корреляции

RED: `rate` (RPS), `errors` (4xx/5xx), `duration` (p95/p99).
USE (для ресурсов): Utilization, Saturation, Errors.
Связывайте с продуктом: депозиты/выплаты успех, фрод-флаги, конверсия — это «охранители» при канареечном релизе.

9) Структура алертинга

Tier-1 (пейдж): инциденты, влияющие на SLO (доступность, 5xx, латентность, отказ кластерных критичных компонентов).
Tier-2 (тикет): деградации емкости, рост ошибок без влияния на SLO.
Tier-3 (информ): тренды, предиктивная емкость, истекающие сертификаты.

Правила эскалаций: время тишины/сжатие дубликатов, ротации on-call, «follow-the-sun».

yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"

10) Примеры правил Prometheus

10.1 Ошибки 5xx c SLO-порогом

yaml groups:
- name: api rules:
- alert: HighErrorRate expr:
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0. 005 for: 10m labels: { severity: "critical", service: "api-gateway" }
annotations:
summary: "5xx > 0. 5% 10m"
runbook: "https://runbooks/api-gateway/5xx"

10.2 Сжигание error-budget (multi-window burn)

yaml
- alert: ErrorBudgetBurn expr:
(1 - (
sum(rate(http_requests_total{status!~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
)) > (1 - 0. 999) 14 for: 5m labels: { severity: "critical", slo: "99. 9" }
annotations: { summary: "Fast burn >14x for 5m" }

10.3 Системная насыщенность (CPU Throttling)

yaml
- alert: CPUThrottlingHigh expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1 for: 10m labels: { severity: "warning" }
annotations: { summary: "CPU throttling >10%" }

11) Логи: сбор, нормализация, ретеншн

Стандартизация: JSON-логи: `ts`, `level`, `service`, `trace_id`, `user/tenant`.
Пайплайн: агент (Fluent Bit/Vector) → буфер → индекс/хранилище.
Редакция: маскирование PII/секретов на краю.
Ретеншн: быстрый класс хранения (7–14 дней), «холодный» архив (30–180 дней).
Семантика: error budgets/депрекейты — отдельные каналы.

12) Трейсы и OpenTelemetry

Инструментируйте входные точки (gateway), клиент→сервис вызовы, БД/кэши/очереди.
Привязывайте метрики к трейс-атрибутам (Exemplars) для быстрой навигации.
OTel Collector как центральный шлюз: фильтрация, семплинг, экспорт в выбранные бекенды.

yaml receivers: { otlp: { protocols: { http: {}, grpc: {} } } }
processors: { batch: {}, tail_sampling: { policies: [ { name: errors, type: status_code, status_codes: [ERROR] } ] } }
exporters: { prometheus: {}, otlp: { endpoint: "traces. sink:4317" } }
service:
pipelines:
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
traces: { receivers: [otlp], processors: [tail_sampling,batch], exporters: [otlp] }

13) Синтетика и внешние проверки

HTTP-пробеги бизнес-сценариев (логин, депозит, вывод, покупка).
TLS/Domain: срок сертификатов/CAA/DNS health.
Региональность: пробы из ключевых стран/провайдеров (маршрутизация/блок-листы).
Синтетика должна алертить, если недоступно пользователю, даже при зеленой внутренней телеметрии.

14) Профилирование и eBPF

Continuous profiling: выявление горячих функций, блокировок.
eBPF: системные события (syscalls, TCP retransmits), на проде с минимальным overhead.
Профильные алерты без страницинга (тикеты), а для регрессий после релиза — как сигнал отката.

15) Дашборды и «панель правды»

1. Platform Overview: SLI/SLO по ключевым сервисам, error-budget, алерты.

2. API RED: RPS/ERRORS/DURATION по маршрутам.

3. K8s Cluster: control-plane, узлы, capacity headroom.

4. DB/Cache: lag/locks/slow query %, hit ratio.

5. Queues: backlog/lag, отказные/повторные.

6. Per-release: сравнение метрик до/после (канареечные окна).

7. FinOps: cost per namespace/service, idle/oversized ресурсы.

16) Инциденты, алерт-шума и эскалации

Дедупликация: группировка по сервису/причине, подавление каскадов.
Тишина/maintenance: релизы/миграции не должны «красить» все красным.
Runbooks: каждая критическая алерта с шагами диагностики и «кнопкой» отката.
Postmortem: таймлайн, чему научились, какие сигналы добавили/почистили.

17) Безопасность в мониторинге

RBAC на чтение/правки правил/датасорсов.
Секреты: токены экспортеров/агентов — через Secret Manager.
Изоляция: метрики клиентов/тенантов — в отдельные пространства/лейбы.
Целостность: подпись агентов/билдов, конфиги через GitOps (мердж-ревью).

18) Финансы и емкость (FinOps)

Квоты и бюджеты; алерты на аномальный рост.
Right-sizing: анализ запросов/лимитов, утилизации CPU/RAM, спот-инстансы для не критичных задач.
«Cost per request/tenant» как KPI эффективности.

19) Анти-паттерны

Только инфраструктурные метрики без пользовательских SLI.
100+ алертов «о всем» → слепота on-call.
Логи как единственный источник (без метрик и трейсинга).
Мутабельные дашборды без версионирования/ревью.
Отсутствие синтетики: «все зеленое», но фронт недоступен.
Нет связки с релизами: нельзя ответить «что поменялось в момент Х».

20) Чек-лист внедрения (0–60 дней)

0–15 дней

Определить SLI/SLO для 3–5 ключевых сервисов.
Включить базовые экспортеры/агенты, стандартизировать JSON-логи.
Настроить Tier-1 алерты (availability, 5xx, p95).

16–30 дней

Добавить синтетику по критическим сценариям.
Включить трейсы (OTel) на входных/критичных сервисах.
Дашборды «Per-release» и error-budget burn-правила.

31–60 дней

Покрыть БД/очереди/кэш продвинутыми сигналами.
Внедрить eBPF/профилирование для high-CPU сервисов.
GitOps для правил/дашбордов/алертов, регулярная чистка шума.

21) Метрики зрелости

Покрытие SLO ключевых сервисов ≥ 95%.
MTTA/MTTR (цель: мин/десятки минут).
Доля алертов Tier-1, закрытых авто-действием или быстрым откатом.
Отношение «полезных»/«шумных» алертов > 3:1.
Покрытие синтетикой всех «денежных» путей = 100%.

22) Приложения: мини-шаблоны

Prometheus — доступность по статус-классам

yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Grafana — подсказка для канареек

expr: histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m])) by (le,version))

Alertmanager — дежурства и тишина

yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]

23) Заключение

Мониторинг — это не набор графиков, а операционная система SRE: SLI/SLO как контракт качества, метрики/трейсы/логи как источники правды, алерты как управляемый сигнал, синтетика как «голос пользователя», GitOps как дисциплина изменений. Постройте единый контур от хоста до API, завяжите его на релизы и откаты — и платформа будет предсказуемой, быстрой и экономной.