Мониторинг и логирование

1) Зачем это важно в iGaming

Деньги в реальном времени: прием депозитов, мгновенные выплаты, расчет ставок и выигрышей, турниры — все чувствительно к задержкам и сбоям.
Регуляторика и аудит: требуется полная трассируемость действий (KYC/AML, платежи, лимиты ответственной игры).
Сложная распределенная архитектура: API-шлюзы, оркестрация платежей, EDA/Kafka, сервисы провайдеров, мобильные клиенты, фронты, BI-шина.
Цель: сократить MTTD/MTTR, держать SLO по золотым сигналам и обеспечивать форензику инцидентов.

2) Базовые понятия наблюдаемости

Логи: детальные события (структурированные JSON), пригодные для расследований и аудита.
Метрики: агрегаты во времени (TSDB), подходят для SLO/алертов.
Трейсы: причинно-следственные цепочки запросов (trace/span) сквозь сервисы/брокеры/БД.
Ивенты: доменные события (BetPlaced, DepositApproved) — мост между бизнес-метриками и техникой.

3) «Золотые сигналы» и SLI/SLO для iGaming

Latency: P95/P99 по критическим потокам (авторизация, депозит, ставка, старт сессии, спин).
Traffic: RPS по API, TPS по платежам, EPS по событиям.
Errors: доля 5xx/4xx, decline-rate, failed-withdrawals, ошибки провайдеров.
Saturation: CPU, memory, IO, Kafka lag, DB connections, thread-pools.

• SLI: `1 - (failed_payments / total_payments)`
• SLO: 99.7% успешных авторизаций карт за 30 дней (error budget 0.3%).

4) Архитектура сбора и обработки

1. Инжест: агенты (OTel Collector/Fluent Bit), SDK в приложении, RUM/синтетика.
2. Маршрутизация: брокер/шина телеметрии (OTLP/HTTP/GRPC), фильтры и маскировка PII.

• Метрики: TSDB (агрегации, downsampling).
• Логи: hot (индексируемые) / warm (менее индексируемые) / cold (объектное хранилище, WORM).
• Трейсы: time-indexed storage с ретенциями и tail-sampling.
• 4. Аналитика/алерты: правила (PromQL/LogQL/SQL), корреляция с трейсамии и релизами.
• 5. Дашборды: технические + бизнес-виды (платежи, RNG/провайдеры, турнирный движок).

5) Стандарт логов (JSON) и таксономия событий

Рекомендуется строгое JSON-логирование, единые ключи и уровни.

Уровни: `DEBUG < INFO < NOTICE < WARN < ERROR < FATAL < AUDIT`

Таксономия: `auth.`, `payment.`, `gameplay.`, `risk.`, `psp.`, `kyc.`, `rg.` (responsible gaming), `ops.`.

json
{
"ts": "2025-11-04T19:45:31. 842Z",
"lvl": "AUDIT",
"event_type": "payment. deposit_approved",
"correlation_id": "c-7d2c1f0b",
"trace_id": "2d6a9c0e4c0b1f72",
"span_id": "9f3a81d2a1c3b764",
"request_id": "r-8f12de9e",
"tenant": "brand_eu",
"psp": "acq_xyz",
"user_id_hash": "u:sha256:1e63…",
"device_id": "d-3c8f…",
"ip_trunc": "203. 0. 113. 0/24",
"amount_minor": 5000,
"currency": "EUR",
"result": "approved",
"latency_ms": 312,
"tags": ["pci_safe", "kyc_passed", "low_risk"],
"extra": {
"bin": "411111",
"method": "card",
"region": "EU",
"ab_test": "checkout_v2"
}
}

• Маскируем PAN/BIN (храним только допустимые по политике поля), email/телефон — хэш/токен.
• IP усекать до /24, GeoIP хранить отдельно.
• Запрещаем свободный текст в `extra` для пользовательского ввода без санитайза.

6) Корреляция: trace_id, correlation_id, idempotency_key

В каждый лог и метрику добавлять `trace_id` (из OTel), `span_id`, `correlation_id` (сквозной для бизнес-процесса), `idempotency_key` (для платежных запросов).
Передавать baggage (tenant/brand, market, A/B-вариант), чтобы строить срезы.

7) Метрики: технические и бизнес

Технические: RPS, p95 latency, error rate, saturation, GC, pool usage, Kafka consumer lag.
Бизнес: CR регистрации→депозит, успешные авторизации, отмены выплат, NGR/GGR, ARPPU, RTP аномалии, drop-off на шаге KYC, доля ответственных лимитов.

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

8) Трейсинг и OpenTelemetry

Инструментируем гейтвей, платежный оркестратор, игровое ядро, уведомления, KYC/AML, интеграции с провайдерами.
Head-sampling для общего потока + tail-sampling (повышенный) для ошибок/латентных спанов и платежей.
Пропагация контекста: `traceparent`/`tracestate`, Kafka headers, gRPC metadata.
Аннотируем спаны доменными событиями: `BetPlaced`, `WithdrawalRequested`.

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

Многоступенчатые пороги (warning/critical), подавление флаппинга, дедупликация, тайм-слоты.
Корреляция: связываем «рост 5xx» + «Kafka lag» + «p95 latency PSP» → один инцидент.
SLO-based алерты: тратим error-budget — эскалируем.
Alerts-as-Code (GitOps), ревью и тесты правил.

yaml groups:
- name: payments rules:
- alert: PaymentErrorSpike expr: (sum(rate(payment_errors_total[5m])) / sum(rate(payment_attempts_total[5m]))) > 0. 02 for: 10m labels: { severity: "critical", team: "payments" }
annotations:
summary: "Payment errors> 2% per 10m"
runbook: "runbooks/payments/error-spike. md"

10) Поиск по логам (пример LogQL)

logql
{app="psp-orchestrator", level=~"ERROR    FATAL"}
= "decline"
json amount_minor > 10000 region="EU"

Цель — быстро отсеять шум и выделить «дорогие» отказы в целевом регионе.

11) Дашборды: что обязательно

Payments Health: успешность/отказы по PSP, latency по методу, карта регионов, SLA провайдеров.
Game Core: RPS по провайдерам, p95 спина, error ratio SDK, RTP аномалии по слотам.
Player Journey: регистрация→KYC→депозит→игра→вывод (конверсионная воронка, время между шагами).
Infra: Kafka lag, DB connections, cache hit ratio, кластера Kubernetes (сетка подов/узлов).

12) Хранение, ретенции и стоимость (FinOps)

Кардинальность под контролем: избегать метрик с высокоизменяемыми лейблами (user_id).
Ретенции: метрики hot 30–90 дн., downsampling до 13 мес.; логи hot 7–14 дн., warm 30–90 дн., cold 1–3 года (с учетом регуляторики).
WORM/immutability для audit-логов, Object Lock.
Сжатие/партиционирование и ILM-политики; отдельные индексы для audit/PII-safe.
Сэмплинг логов на INFO/DEBUG; ERROR/AUDIT — полные.

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

PII/PCI: токенизация, хэширование, маскировка; минимизация данных.
RBAC/ABAC: доступ к логам/трейсам — по ролям, разделение тентов.
Секреты и ключи: не логировать credentials/токены; детекторы секретов на CI.
Аудит-трейл: входы в админку, изменения лимитов/выплат, ручные корректировки баланса — только в AUDIT-индекс, неизменно.
Legal-hold: механизм заморозки ретенций при расследованиях.

14) Качество данных телеметрии

Schema Registry для логов/ивентов (версионирование, совместимость).
Единая наменклатура полей (snake_case, единицы измерения).
Валидация на инжесте (дроп грязных событий, метрики о браке).
Backpressure и защита от «штормов логов».

15) SRE-процессы, онколл и рунбуки

Онколл-матрица и эскалации; Quiet Hours и ротации.
Рунбуки привязаны к алертам (шаги диагностики, SQL/LogQL рецепты, фичефлаги для деградации).
Postmortem без наказаний, action items с владельцами и дедлайнами.
Индикаторы команды: MTTD/MTTR, процент шумных алертов, покрытие рунбуками.

16) RUM и синтетика

RUM: WebVitals (LCP, CLS, INP), ошибки фронта, отпечатки устройств, регионы/провайдеры.
Синтетика: сценарии «регистрация→депозит→спин→вывод» из разных регионов; приватные локации для внутренних путей (админка/бэк-офис).

17) Практики релизов, экспериментов и фичефлагов

Линкуем трейсы с версиями релизов (commit/artefact).
A/B-теги в baggage → дашборд «влияние эксперимента на SLI».
Canary/Blue-Green: отдельные панели для канареек, error-budget burn rate.

18) Обнаружение аномалий и анти-фрод сигналы

Статистические триггеры (seasonality-aware) на decline-rate/chargeback-risk/всплеск новых карт.
Корреляции: «рост неуспешных депозитов + новый релиз PSP-адаптера».
Стриминговые правила (Kafka → Flink) для near-real-time реакций.

19) Дорожная карта внедрения (по этапам)

Этап 0 — Базис: JSON-логи, единые кореляционные поля, базовые метрики сервисов, общие дашборды, первые алерты.
Этап 1 — Трейсинг: OTel-инструментирование, head+tail sampling, связывание с логами.
Этап 2 — Бизнес-SLI/SLO: платежи/выводы/игровые метрики, SLO-алерты, error-budget процессы.
Этап 3 — Зрелость: Alerts-as-Code, ILM, раздельные ретенции, аномалия-детект, пер-сервис рунбуки, SRE-практики в CI/CD.

20) Чек-лист для ревью

• Логи только JSON, единые ключи, PII-маскировка.
• В каждом событии: `trace_id`, `span_id`, `correlation_id`, `tenant`.
• Метрики покрывают золотые сигналы и бизнес-потоки.
• SLO описаны, есть error-budget и алерты на burn rate.
• Tail-sampling включен для платежных ошибок и высоких латентностей.
• ILM/ретенции и WORM настроены для audit-логов.
• RBAC на телеметрию, аудит доступа.
• Дашборды по Payments/Game Core/Player Journey/Infra.
• Рунбуки привязаны к каждому критическому алерту.
• Постмортемы и action items — в бэклоге с владельцами.

Приложение A: атрибуты OpenTelemetry (рекомендация)

`service.name`, `service.version`, `deployment.environment`

`cloud.region`, `k8s.pod.name`, `k8s.container.name`

`tenant`, `brand`, `market`, `ab_test`, `user_segment`

`payment.method`, `psp`, `game.provider`, `game.id`

Приложение B: примеры метрик для SLO

`payment_success_ratio`, `withdrawal_ttw_p95` (time-to-wallet), `psp_latency_p99`

`game_spin_latency_p95`, `provider_error_rate`, `kafka_consumer_lag`

`auth_success_ratio`, `kyc_step_dropout`, `cache_hit_ratio`

Приложение C: быстрые рецепты расследований

«Растет `payment_error_rate`» → сравнить по PSP/региону/методу, проверить tail-трейсы, посмотреть релиз адаптера.
«p99 спинов ↑» → трассировки фронт→гейтвей→провайдер, проверить провайдера/каналы, лимиты thread-пулов, сетевые ретраи.
«Kafka lag ↑» → health консумеров, ретраи продюсеров, backpressure, медленные sinks/БД.