Моніторинг та логування

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 registratsii→depozit, успішні авторизації, скасування виплат, 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: registratsiya→KUS→depozit→igra→vyvod (конверсійна воронка, час між кроками).
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), помилки фронту, відбитки пристроїв, регіони/провайдери.
Синтетика: сценарії «registratsiya→depozit→spin→vyvod» з різних регіонів; приватні локації для внутрішніх шляхів (адмінка/бек-офіс).

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 спінів ↑» → трасування front→geytvey→provayder, перевірити провайдера/канали, ліміти thread-пулів, мережеві ретраї.
«Kafka lag ↑» → health консумерів, ретраї продюсерів, backpressure, повільні sinks/БД.

При дотриманні цих практик платформа отримує стійку, перевіряється і економну систему спостережуваності, яка одночасно служить інженерним інструментом, бізнес-радаром і гарантом комплаєнсу.