Стек спостережуваності

1) Навіщо потрібен стек спостережуваності

Швидкі RCA і зниження MTTR: від симптому до причини за хвилини.
SLO-управління: вимірювання помилок/латентності, алертинг за помилковим бюджетом.
Контроль релізів: канарні викладки, авто-rollback за метриками.
Безпека та аудит: траси доступу, аномалії, Legal Hold.
ФінОпс-прозорість: вартість зберігання/запитів, cost-per-SLO.

Методології: Golden Signals (latency/traffic/errors/saturation), RED, USE.

2) Базова архітектура стека

Компоненти по шарах

Збір/агенти: Exporters, Promtail/Fluent Bit, OTel SDK/Auto-Instr, Blackbox-probes.
Шина/ingest: Prometheus remote_write → Mimir/Thanos, Loki distributors/ingesters, Tempo/Jaeger ingesters.
Сховища: об'єктне S3/GCS/MinIO (тривалий холод), SSD (гарячі ряди).
Запити/візуалізація: Grafana (панелі, SLO-віджети), Kibana (якщо ELK).
Управління: Alertmanager/Графана-альберти, сервіс-каталог, RBAC, секрет-менеджер.

Патерни розгортання

Managed (Grafana Cloud/хмарні сервіси) - швидко і дорожче на обсягах.
Self-hosted в K8s - повний контроль, потребує експлуатації і FinOps.

3) Стандарти даних: єдина «схема спостережуваності»

3. 1 Метрики (Prometheus/OpenMetrics)

Обов'язкові лейбли: «env», «region», «cluster», «namespace», «service», «version», «tenant» (якщо мульти-тенант), «endpoint».
Іменування: 'snake _ case', суфікси'_ total','_ seconds','_ bytes'.
Гістограми: фіксовані «buckets» (SLO-орієнтовані).
Кардинальність: не включати'user _ id','request _ id'в лейбли.

3. 2 Логи

Формат: JSON; обов'язкові поля'ts','level','service','env','trace _ id','span _ id','msg'.
PII: маскування на агенті (PAN, токени, e-mail тощо).
Loki-лейбли: тільки низька кардинальність («app», «namespace», «level», «tenant»).

3. 3 Траси

OTel семантика: `service. name`, `deployment. environment`, `db. system`, `http.`.
Семплінг: цільові шляхи p99 -'always _ on '/tail-sampling, решта -'parent/ratio'.
Вбудовування ID: прокидайте'trace _ id/span _ id'в логи і метрики (labels/fields).

4) Кореляція M-L-T (Metrics/Logs/Traces)

З графіка алерта (метрика) → фільтровані логи по'trace _ id'→ конкретна траса.
З траси (повільний спан) → запит метрик конкретного бекенду на інтервалі спану.
Кнопки Drilldown в панелях: «до логів» і «до трас» з підстановкою змінних («$env», «$service», «$trace_id»).

5) OpenTelemetry Collector: еталонний пайплайн

yaml receivers:
otlp:
protocols: { http: {}, grpc: {} }
prometheus:
config:
scrape_configs:
- job_name: kube-nodes static_configs: [{ targets: ['kubelet:9100'] }]

processors:
batch: {}
memory_limiter: { check_interval: 1s, limit_mib: 512 }
attributes:
actions:
- key: deployment. environment value: ${ENV}
action: insert tail_sampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code: { status_codes: [ERROR] }
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/payments","/login"] }
- name: probabilistic type: probabilistic probabilistic: { sampling_percentage: 10 }

exporters:
otlphttp/mimir: { endpoint: "https://mimir/api/v1/push" }
otlphttp/tempo: { endpoint: "https://tempo/api/traces" }
loki:
endpoint: https://loki/loki/api/v1/push labels:
attributes:
env: "deployment. environment"
service: "service. name"

service:
pipelines:
metrics: { receivers: [prometheus, otlp], processors: [memory_limiter, batch], exporters: [otlphttp/mimir] }
logs:   { receivers: [otlp], processors: [batch], exporters: [loki] }
traces:  { receivers: [otlp], processors: [memory_limiter, attributes, tail_sampling, batch], exporters: [otlphttp/tempo] }

6) Алертінг: SLO и multi-burn

Ідея: алертим не на рівні «CPU> 80%», а на споживанні Error Budget.

promql
5-minute error rate err_ratio_5m =
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m]))

Quick burn (1m window)
(err_ratio_1m / (1 - SLO)) > 14. 4

Slow burn (30m)
(err_ratio_30m / (1 - SLO)) > 2

promql latency_p95 =
histogram_quantile(0. 95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

7) Дашборди: структура папок

00_Overview - платформа: SLO, p95, 5xx%, capacity, активні інциденти.
10_Services - за сервісами: RPS, p95/p99, помилки, релізи (анотації).
20_Infra - K8s/ноди/сторідж/мережа, etcd, контролери.
30_DB/Queues — PostgreSQL/Redis/Kafka/RabbitMQ.
40_Edge/DNS/CDN/WAF - ingress, LB, правила WAF.
50_Synthetic - аптайм і headless-сценарії.
60_Cost/FinOps - зберігання, запити, гаряче/холодне, прогноз.

Кожна панель: опис, одиниці, власник, runbook-посилання, drilldown.

8) Логи: LogQL практикум

logql
API errors
{app="api", level="error"}     = "Exception"

Nginx 5xx in 5 minutes
{app="nginx"}      json      status=~"5.."      count_over_time([5m])

Extract Fields
{app="payments"}      json      code!=""      unwrap duration      avg()

9) Траси: TraceQL і фокуси

{ service. name = "api" }      duration > 500ms

{ name = "HTTP GET /order" }      child. span. name = "SELECT" & child. duration > 50ms

10) Синтетика та аптайм

Blackbox-exporter: HTTP/TCP/TLS/DNS-проби з ≥3 регіонів/ASN.
Headless: login/deposit сценарії за розкладом.
Quorum-алерти: спрацьовування, якщо ≥2 регіонів бачать відмову.
Статус-сторінка: автоматичні апдейти + ручні коментарі.

11) Зберігання та ретеншн

Метрики: гаряче 7-30 днів (швидкі ряди), downsampling/recording rules, холодне - об'єктне сховище (місяці).
Логи: гарячіше 3-7 днів, потім - S3/GCS з індексом (Loki chunk store/ELK ILM).
Траси: 3-7 днів'always _ on'+ тривале зберігання для вибірок (tail-sampled/відбраковка).

• Ролловер за розміром і часом; бюджет на запити (квоти/ліміти).
• Окремі політики для prod/stage і даних безпеки.

12) Мульти-тенантність і доступи

Розділяйте по'tenant '/' namespace '/Spaces, індекс-патерни і дозволу.
Тегуйте ресурси для білінгу: `tenant`, `service`, `team`.
Імпортні дашборди/алерти - в просторах конкретних команд.

13) Безпека та комплаєнс

TLS/mTLS від агентів до бекендів, HMAC для приватних health.
RBAC на читання/запис, аудит всіх запитів і алертів.
PII-редакція на краю; заборона секретів в логах; DSAR/Legal Hold.
Ізоляція: окремі кластери/неймспейси для чутливих доменів.

14) ФінОпс: вартість спостереження

Знижуємо кардинальність лейблів і логіку в ingest (а не в запитах).
Семплінг трас + цільове always-on для критичних шляхів.
Downsampling/recording rules для важких агрегацій.
Архівація рідкісного доступу в холодне об'єктне.
Метрики: `storage_cost_gb_day`, `query_cost_hour`, `cost_per_rps`, `cost_per_9`.

15) CI/CD і тести спостережуваності

Лінтинг метрик/логів в CI: заборона «вибуху» кардинальності, перевірка гістограм/одиниць.
Contract-тести спостережуваності: обов'язкові метрики/поля логів,'trace _ id'в middleware.
Canary: анотації релізів на графах, SLO-авто-rollback.

16) Приклади: швидкі запити

promql topk(10, sum by (route) (rate(http_requests_total{status=~"5.."}[5m])))

promql sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m])) > 0

promql max by (topic, group) (kafka_consumergroup_lag)

Від логів до трас (Loki → Tempo): передавайте'trace _ id'як лінку на Tempo UI/дешборд.

17) Якість стека: чек-лист

• Узгоджені схеми метрик/логів/трас і одиниці вимірювання.
• 'trace _ id'в логах і метриках, drilldown з панелей.
• Multi-burn SLO-алерти без флапінгу (quorum/multi-window).
• Downsampling, квоти запитів, ліміти на крок/діапазон.
• Ретеншн і класи зберігання задокументовані і застосовуються.
• RBAC/аудит/PII-редакція включені.
• Дашборди: власник, runbooks, ≤2 -3 екрану, швидка відповідь.
• ФінОпс-дашборд (обсяги, вартість, топ-говоруни).

18) План впровадження (3 ітерації)

1. MVP (2 тижні): Prometheus→Mimir, Loki, Tempo; OTel Collector; базові дашборди і SLO-алерти; blackbox-проби.
2. Scale (3-4 тижні): tail-sampling, downsampling, мульти-регіон ingest, RBAC/Spaces, FinOps-дашборди.
3. Pro (4 + тижні): auto-rollback по SLO, headless-синтетика ключових шляхів, Legal Hold, портфель SLO і звітність.

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

«Красиві графіки без SLO» - немає дії → немає користі.
Лейбли з високою кардинальністю ('user _ id','request _ id') - вибух пам'яті і вартості.
Логи без JSON і без'trace _ id'- немає кореляції.
Алерти за ресурсами замість симптомів - шум і вигорання on-call.
Відсутність ретеншн-політик - безконтрольне зростання витрат.

20) Міні-FAQ

Що вибрати: Loki або ELK?
ELK для складного пошуку/фасетів; Loki - дешевше і швидше для grep-подібних сценаріїв. Часто використовують гібрид.

Чи потрібні траси всім?
Так, хоча б на ключових шляхах (login, checkout, payments) з tail-sampling - це різко прискорює RCA.

Як почати з нуля?
OTel Collector → Mimir/Loki/Tempo → базові SLO і blackbox-проби → потім дашборди і burn-алерти.

Підсумок

Стек спостережуваності - це не набір розрізнених інструментів, а узгоджена система: єдині стандарти даних → кореляція M-L-T → SLO-алертинг і синтетика → безпека і FinOps. Зафіксуйте схеми, дисципліну лейблів і ретеншн, підключіть OTel, додайте drilldown і auto-rollback - і ви отримаєте керовану надійність зі зрозумілою вартістю.