Observability: метрики, логи, трасування в iGaming

1) Навіщо observability саме в iGaming

Гравці чутливі до затримок і збоїв в реальному часі (live-ігри, ставки, турніри). Будь-яка деградація логіну/депозиту/виведення б'є по виручці і довірі. Спостережуваність повинна:

давати моментальну картину L3-L7, додатку та бізнесу;
швидко локалізувати «вузькі місця» між фронтом, API, провайдерами ігор, платіжками;
чітко відокремлювати продуктові фейли (неможливо зробити ставку) від «красивих» технічних метрик.

Ключ: починати з SLO (service level objectives) продуктових флоу, а вже потім вибирати метрики/логи/трасування.

2) Продуктові SLO і помилка бюджету (error budget)

Приклади SLO (за 30 днів):

Логін: успішність ≥ 99. 90%, p95 latency ≤ 250 мс.
Депозит ('/payments/deposit') і висновок: успішність ≥ 99. 85%, p95 ≤ 400 мс.
Ставка в реальному часі: успішність ≥ 99. 9%, p95 WS-повідомлення ≤ 120 мс.
Запуск слота/сесії лайв-гри: успішність ≥ 99. 8%, p95 ≤ 800 мс.

Error budget переводимо в політику релізів: якщо витрачено> 50% - стоп-фіча/канарний деплою тільки;> 80% - тільки багфікси.

3) «Три кити» телеметрії

Метрики (квантифікація стану)

RED для користувацьких API: Rate, Errors, Duration по кожному endpoint/методу.

USE для інфраструктури: Utilization, Saturation, Errors (CPU, пам'ять, IO, з'єднання, черги).

Бізнес-метрики: конверсія registratsii→depozit, частка успішних висновків, кількість активних столів лайв-казино, середня затримка котирувань.

Логи (факти і контекст)

Структуровані JSON-події з обов'язковими полями: `ts`, `level`, `service`, `env`, `trace_id`, `span_id`, `user_id` (псевдонимизированный), `session_id`, `route`, `status`, `latency_ms`, `amount`, `currency`, `provider`.

Категорії: аудит (зміни прав/балансу), бізнес-події (ставка, депозит), помилки (stack/код), техпідтримка (warn/info).

Трасування (причинно-наслідкові зв'язки)

End-to-end через фронт → API → ризиковий рушій → провайдери ігор/платежі → черги/БД.

Широке семплювання помилок (100%), адаптивне семплювання «повільних» запитів (напр. p95 +), за замовчуванням 1-5% success-трафіку.

4) Дизайн метрик: що знімати і як називати

Приклади Prometheus-метрик (псевдо):


RED по платежам counter ig_payments_requests_total{route="/payments/deposit",method="POST",provider="card"}
counter ig_payments_errors_total{route="/payments/deposit",code="5xx",provider="card"}
hist   ig_payments_latency_seconds_bucket{route="/payments/deposit",le="0. 25"}
gauge  ig_wallet_balance_anomalies{reason="negative_after_loss"}

Бизнес counter ig_bet_placed_total{game="slot",provider="PragmaticPlay",currency="EUR"}
hist   ig_bet_rtt_ms_bucket{game="live_blackjack",le="100"}
gauge  ig_active_tables{provider="Evolution",market="EU"}

Правила:

Єдина онтологія лейблів: `env`, `region`, `market`, `provider`, `route`, `game`, `payment_method`.
Не підривати кардинальність: обмежити'user _ id'в метриках (тільки в логах/трейсах).

5) Логи: структура, приватність, ретеншен

Мінімальний JSON для критичних дій:

json
{
"ts":"2025-10-23T17:41:26. 123Z",  "level":"INFO",  "service":"payments-api",  "env":"prod",  "trace_id":"b3f7…",  "span_id":"ab12…",  "user_pid":"u_9fd"... ,//псевдонім, не email/телефон
"session_id":"s_78a…",  "route":"/payments/deposit",  "status":200,  "latency_ms":182,  "amount":100. 0,  "currency":"EUR",  "provider":"card",  "bin_country":"DE"
}

Практики:

Маскувати/виключати PAN/CVV, токени, паролі, JWT - навіть в debug.
Прив'язати логи до трас ('trace _ id') і до замовника (псевдонім'user _ pid').
TTL: «галасливі» техлоги 14-30 дн, аудит-трейл 1-3 роки (за політикою і законом), бізнес-логи 6-24 міс (псевдонімізовано).
WORM/immutability для аудиту (незмінні бакети), ACL за ролями.

6) Трасування: від фронту до провайдера

Протяжні флоу

Логін/реєстрація → антибот/WAF → Auth-API → профіль/гаманець.

Депозит → Payment-API → провайдер → webhooks → Wallet-service.

Ставка → Game-gateway (WebSocket) → провайдер гри → розрахунок виграшу → Wallet.

Тактика

OpenTelemetry скрізь: SDK на фронті (XHR/Fetch), на мобілі, в API, в воркерах.

Протоколи контексту: W3C traceparent/tracestate; прокидати через gRPC/HTTP/WebSocket (у WS - у перших метаданих/повідомленнях).

Adaptive sampling: 100% для помилок, ≥50% для платіжних виводів, ≥10% для «нових» релізів/канарок, 1-5% фоново.

Візуальні мітки в трейс-в'ю: `risk_decision`, `provider_name`, `bonus_id`, `jackpot_round`.

7) Real-time канали: WebSocket/WebRTC

Метрики: `ws_connected_sessions`, `ws_messages_in_flight`, `ws_send_latency_ms`, `ws_disconnect_reason`.

Трейс-події: `ws_subscribe_table`, `ws_bet_place`, `ws_settlement`.

Логи: нормувати розмір повідомлень/частоту; відстежувати «порожні пінги» і flood-патерни.

Для WebRTC (лайв-казино): `jitter_ms`, `packet_loss`, `round_trip_time_ms`, `keyframe_interval_s`.

8) Алертінг: від симптомів до причин

Симптомні алерти (SLO/SLA):

SLI-помилка логіна> 0. 3% за 5 хв.
p95 '/payments/deposit'> 400 мс 10 хв поспіль.
Успішність ставок <99. 7% за 15 хв.

Причинні/ресурсні:

`db_connections_saturation > 0. 85` 5 мин; `queue_lag_seconds > 30`.
Сплеск'429 '/' 5xx'з одного ASN → сигнал в WAF/бот-менеджер.

Шумозаглушення:

Алерти тільки при стійких порушеннях; авто-глушіння дублікатів; routes to runbooks.

9) Дашборди, які реально допомагають

«Флоу депозиту»

Воронка: запит → редирект на провайдера → колбек → апдейт гаманця.

Успішність/помилки по провайдерам, карта BIN-країн, p95/99 латентності, розподіл кодів помилок.

«Live-ігри/ставки»

Активні столи, онлайн-гравці, p95 WS-затримки, share timeouts/aborts, топ-ігри помилково.

«Здоров'я API»

RED за ключовими маршрутами, 4xx/5xx, saturations пулу з'єднань/CPU/GC, top N повільних endpoints (з лінками в трейс).

10) Вартість та зберігання: Як не розоритися

Cardinality budget: ліміти на лейбли/атрибути; рев'ю PR, які додають метрики.

Tiered storage: гарячі 3-7 днів (швидкий пошук), теплі 30-90 днів (S3/об'єктне), холодний архів (рідше).

Downsampling метрик (1s → 10s → 1m) і rolling-агрегації.

Дедуплікація логів з ретраїв та ідемпотентних викликів.

11) Приватність і комплаєнс (коротко)

Псевдонімізуйте'user _ id', не зберігайте в логах e-mail, телефон, паспорт.

Шифруйте транспорт (mTLS) і «спокій», розмежовуйте доступи (RBAC/MFA), ведіть метажурнали доступу до даних.

TTL/ретеншен як в матриці даних; «право на видалення» реалізуйте через прапори-деактивації та псевдонімізацію в історичних наборах.

12) Інциденти і налагодження за трейсами: Швидкий рецепт

1. Спрацював симптомний алерт (успішність депозитів).

2. Дашборд показав сплеск по одному провайдеру.

3. Клікаємо в трейс-в'ю: довгий крок на'provider _ callback'( p99 2. 3 с), багато ретраїв.

4. Логи: 'timeout'+ ASN = хостинг з бот-патерном.

5. Дії: підняли таймаути на колбек, включили JS-челендж в WAF для ASN, лімітували ретраї.

6. Ретро: додали SLI на'callback _ success _ ratio', алерт на'queue _ lag _ seconds'.

13) Впровадження за етапами

1. SLO-дизайн для 4-6 критичних флоу (логін, депозит, виведення, запуск гри, ставка).

2. Метрики RED/USE + бізнес-SLI; єдина схема лейблів.

3. Структурні логи з'trace _ id'; маскування чутливих полів.

4. OpenTelemetry всюди; адаптивне семплювання.

5. Дашборди + алерти (симптомні і причинні), runbooks.

6. Кост-менеджмент: кардинальність, downsampling, рівні зберігання.

7. Навчання: GameDay-сценарії (падіння платіжки, лаг провайдера, сплеск WS).

8. Безперервне поліпшення: додавайте SLI при появі нових фіч, закривайте «сліпі зони».

14) Чек-лист (prod-ready)

SLO/SLI затверджені, error budget в політиці релізів.
RED/USE метрики + бізнес-метрики з єдиною онтологією лейблів.
Логи JSON, маскування секретів,'trace _ id'в кожному повідомленні.
End-to-end трасування (HTTP/gRPC/WebSocket/WebRTC), W3C контекст.
Алерти симптомні і причинні, без шуму, лінки в runbooks.
Дашборди для депозитів, ставок, здоров'я API; швидкі фільтри по'provider/market'.
Семплювання/кардинальність під контролем, tiered storage.
Приватність: псевдонімізація, шифрування, RBAC/MFA, метажурнали.
Навчання і ретро, регулярний перегляд SLO.

Резюме

Спостережуваність iGaming - це не «графіки CPU», а продуктова картина в реальному часі: SLO критичних флоу, метрики RED/USE, зв'язні логи і трасування через весь шлях гравця і грошей. Додайте дисципліну алертингу по помилковому бюджету, контролюйте вартість телеметрії, дотримуйтесь приватності - і команда буде не вгадувати, а бачити причини проблем і лагодити їх до того, як це помітять гравці.