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, соединения, очереди).

Бизнес-метрики: конверсия регистрации→депозит, доля успешных выводов, количество активных столов лайв-казино, средняя задержка котировок.

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

Структурированные 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, связные логи и трассировки через весь путь игрока и денег. Добавьте дисциплину алертинга по ошибочному бюджету, контролируйте стоимость телеметрии, соблюдайте приватность — и команда будет не угадывать, а видеть причины проблем и чинить их до того, как это заметят игроки.