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

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

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 з 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), kliyent→servis виклики, БД/кеші/черги.
Прив'язуйте метрики до трейс-атрибутів (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, зав'яжіть його на релізи і відкати - і платформа буде передбачуваною, швидкою і економною.