Спостережуваність і телеметрія

(Розділ: Технології та Інфраструктура)

Коротке резюме

Спостережуваність - це здатність відповідати на «чому воно так працює?» без релізу нових білдів. В iGaming це критично: пікові турніри, платіжні піки, багаторегіональність та вимоги щодо відповідального гемблінгу/PII. Базис - метрики, логи, трасування, об'єднані загальними ідентифікаторами і стандартами (OpenTelemetry), з SLO-контрактами, шумостійким алертингом і контролем вартості.

1) Каркас спостережуваності: з чого він складається

Метрики (числа за часом): RED/USE, бізнес-KPI, SLI. Зберігаються в TSDB.
Логи (події в текст/JSON): аудит, помилки, бізнес-факти, безпека.
Трасування (спени): шлях запиту через сервіси, латентності, причини затримок.
Профайлінг: CPU/пам'ять/eBPF-потоки, heap/lock-контеншн.
RUM і синтетика: реальні користувачі (web/app) + робот-перевірки.
Каталог телеметрії: схеми, політики PII, терміни зберігання, теги вартості.

2) Таксономія сигналів і принципи

RED для API: Rate, Errors, Duration.
USE для інфраструктури: Utilization, Saturation, Errors (CPU, диски, мережа, черги).
SLI/SLO: вимірювані індикатори (наприклад, успішні запити/всі, p95 latency), цілі доступності (наприклад, "99. 9% за 30 днів"), бюджет помилок → тригери процесів.
High-cardinality з розумом: лейбли повинні бути корисні в розрізах (регіон/тенант/провайдер), але не підривати TSDB.

3) Стандарти і наскрізна кореляція

OpenTelemetry (OTel): єдиний SDK/протокол для метрик, логів і трасувань.
Ідентифікатори: 'trace _ id','span _ id','correlation _ id','player _ id'( псевдонімізований),'payment _ route'.
Протікання ID: вхідний шлюз → всі мікросервіси → платежі/PSP → черги/джоби → логи/метрики/спени.

Приклад: заголовки кореляції

traceparent: 00-<trace_id>-<span_id>-01 x-request-id: <correlation_id>

4) Метрики: що і як вимірюємо

Іменування/лейбли

`service="payments-api"`, `env="prod"`, `region="eu-west"`, `tenant`, `provider="pspX"`.

Приклади Prometheus

prometheus
RED http_requests_total{service="api",route="/deposit",method="POST",status="200"}
http_request_duration_seconds_bucket{service="api",le="0. 25",route="/deposit"} 1234 http_request_errors_total{service="api",route="/deposit"}

USE cpu_utilization_ratio{node="n1"} 0. 71 queue_depth{queue="withdrawals"} 128

Бизнес payments_success_total{psp="X",currency="EUR"} 4521 payment_conversion_ratio{route="pspX"} 0. 948

Гістограми та exemplars

Зберігайте гістограми латентності (native-histograms/ β uckets) і прив'язуйте exemplar з'trace _ id'для стрибка від «повільного бакета» до конкретної трасі.

5) Логи: структуровано та безпечно

Тільки JSON (ніякого «free-form» в проді).
Поля: `timestamp`, `severity`, `service`, `trace_id`, `correlation_id`, `player_id_hash`, `event`, `amount`, `currency`, `ip_hash`.
Маскування/хешування PII, окремі індекси/retention для чутливого.
Пайплайни логів: парсинг → нормалізація → збагачення (geo/ASN) → редагування PII → індексація.

Приклад JSON-події

json
{
"ts":"2025-11-05T10:42:31Z",
"sev":"ERROR",
"service":"payments-api",
"event":"psp_timeout",
"trace_id":"9c5e...e2",
"route":"pspX",
"duration_ms": 3100,
"attempt":2,
"player_id_hash":"p:1b7f...",
"pii_redacted":true
}

6) Трасування: Де втрачається час

Спени: вхідний запит, виклики провайдерів (PSP/ігрові провайдери), БД/кеш, міжсервісні RPC.
Атрибути: `db. system`, `net. peer. name`, `messaging. system`, `psp. route`, `game. provider`.

• head-based (ймовірнісний) для обсягу,
• tail-based (за умовами: помилки, p95 +, VIP-сегмент),
• guaranteed-keep для платіжних/PII-критичних.

7) Спостережуваність фронту і мобайлу

RUM: TTFB, FCP/LCP/CLS/INP, помилки JS, мережі та SPA-роутинг.
Краш-репорти: символикація, деобфускація, версія білда, пристрій/OS.
Синтетика: сценарії входу/депозиту/ставки; георозподілені перевірки.

8) SLO, SLI і бюджет помилок

Приклад SLO (псевдо-YAML)

yaml service: payments-api sli:
- name: availability expr: sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
- name: latency_p95 expr: histogram_quantile(0. 95, rate(http_request_duration_seconds_bucket[5m]))
targets:
availability: "99. 9%/30d"
latency_p95: "<=250ms/30d"
error_budget_policy:
fast_burn: 5% for 1h -> page, freeze deploy slow_burn: 20% for 24h -> incident, improvement plan

Алертинг по бюджету помилок, а не по «кожній метриці».
Freeze-процедури при згорянні бюджету: обмежити релізи/канарю.

9) Алертінг без шуму

Multi-window, multi-burn правила: коротке/довге вікно.
Дедуплікація/рутинг: по сервісах/регіонах/критичності в on-call.
Runbook URL і автозбір контексту (останні деплої, зміни конфігів, граф залежності).
Тихі години і придушення під час планових робіт.

Приклад правила (ідея PromQL)

promql alert: PaymentsSLOFastBurn expr: slo_error_rate_5m > 2 slo_budget_rate for: 15m labels: { severity="page", service="payments-api" }
annotations:
summary: "SLO fast burn"
runbook: "https://runbooks/payments/slo"

10) Профайлінг та eBPF

eBPF/профайлери: flame-графи CPU/alloc, I/O-латентність, мережеві дропи, Syscall-аномалії.
Корисно при вузьких місцях p99, «джиттері» і рідкісних зависаннях.

11) Бізнес-спостережуваність (product & risk)

Фінанси/монетизація: конверсія депозитів, TTW (time-to-wallet), авториз ./сеттл, скасування/чарджбеки.
Ігрова активність: ретеншн/стрик, частка live-ставок, «липкість» провайдерів.
Антифрод/аб'юз: швидкість дій, збіги пристроїв/IP, кореляції.
RG-індикатори: тривалі сесії, «догон», зростання стейків.
Бізнес-метрики корелюються з техметриками і релізами (annotation events).

12) Безпека, PII і відповідність

Data-zones: теги датасетів/логів ('pii = true','region = EU').
Маскування до індексації, псевдонімізація ідентифікаторів.
WORM-сховища для аудиту; рольовий доступ до логу.
Терміни зберігання: різні для техлогів/аудиту/бізнесу.
Заборона сирих секретів в логах; скан-перевірки в CI.

13) Управління вартістю (FinOps)

Ліміт кардинальності: обережно з'user _ id','session _ id'.
Партіонування/ретеншн: гаряче (7-14 днів), тепле (30-90), холодне (архів).
Семплінг трас (tail-based) і downsampling метрик.
Білінг за тегами'team','service','tenant': звіти «хто спалює спостережуваність».

14) Інструментарій (референс-стек)

Метрики: Prometheus/лейк для метрик, дашборди Grafana.
Логи: Loki/ELK; ingestion правила, reduction/парсинг.
Трейси: Tempo/Jaeger/OTel-колектори; exemplars-лінки з метрик.
Синтетика: Blackbox-експортер, браузерні роботи.
Alerting: Alertmanager/чат-інтеграції, on-call ротації.
Профайлінг: eBPF/continuous profiling.

15) Приклади: швидко впровадити основу

python from prometheus_client import Counter, Histogram, start_http_server reqs = Counter('http_requests_total','', ['route','method','status'])
lat = Histogram('http_request_duration_seconds','', ['route'])
def handle(req):
with lat. labels(route=req. route). time():
status = app(req)
reqs. labels(route=req. route,method=req. method,status=str(status)). inc()

go tid:= ctx. Value("trace_id")
logger = logger. With("trace_id", tid)
logger. Info("deposit-accepted", "amount", amt, "route", route)

prometheus http_request_duration_seconds_bucket{..., le="0. 25"} 1023 # exemplar: trace_id=9c5e...

16) Процеси та операційка

Єдиний словник метрик/лейблів (naming-guide) і шаблон дашбордів.
Release-annotations автоматом в графах.
Інциденти: картка, таймлайн, RCA без звинувачень, action items.
Навчальні тривоги («game-day»): імітації падінь, затримок PSP, перегріву кешу.
Runbooks: покрокові інструкції та автосилання з алертів.

17) Чек-лист зрілості

1. OTel SDK/колектор → єдиний експорт метрик/логів/трейсів.
2. RED/USE покривають всі сервіси + SLI/SLO за ключовими API.
3. Кореляція'trace _ id'⇄ логи ⇄ метрики (exemplars, jump-links).
4. Алерти по бюджету помилок з multi-burn і рунабук-посиланнями.
5. RUM + синтетика на «депозит/ставка/виведення».
6. Профайлінг (eBPF) на проді по білому списку.
7. PII-політики: маскування, зони, доступ, терміни зберігання.
8. Фінансовий звіт по вартості телеметрії (теги'team/service').
9. «Готовність до пікового навантаження»: тест-план, прогрів кешів, alert-шаблони.
10. Регулярні RCA і перегляд SLO/порогів.

18) Антипатерни

Логи «простирадлами» без структури і'trace _ id'.
Алерти по кожній метриці → алерт-фетІг.
Гістограми без коректних бакетів → «плоскі» p95.
Необмежена кардинальність лейблів → вибух вартості.
Відсутність RUM/синтетики - «все ок», а користувачеві немає.
Змішування PII з техлогами, безстрокова ретенція.
Ізоляція телеметрії від бізнес-KPI - «латентність падає, виручка теж».

Підсумки

Сильна спостережуваність - це спільна мова між продуктом, SRE, безпекою і платежами. З'єднавши метрики, логи, траси під OTel, ввівши SLO з бюджетом помилок, зробивши алертинг розумним і вартість керованої, ви отримуєте систему, яка раніше помічає проблеми, швидше відновлюється і передбачувано проходить піки трафіку і турнірні навантаження.