Observability: метриктер, логтар, iGaming-тегі трассировка

1) Неге дәл iGaming observability

Ойыншылар нақты уақыттағы кідірістер мен іркілістерге сезімтал (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) Телеметрияның «үш киті»

Метрика (күй квантификациясы)

Әрбір endpoint/әдісі бойынша теңшелетін API: Rate, Errors, Duration үшін RED.

Инфрақұрылымға арналған 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`.

Trace-оқиғалар: '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. 5 минут ішінде 3%
p95 '/payments/deposit '> 400 мс қатарынан 10 мин.
Ставкалардың табыстылығы <99. 15 минут ішінде 7%

Себеп/ресурс:

`db_connections_saturation > 0. 85` 5 мин; `queue_lag_seconds > 30`.
Бір ASN → дабылынан WAF/бот менеджеріне '429 '/' 5xx' секіру.

Шуды азайту:

Аллергтер тұрақты бұзылулар кезінде ғана; телнұсқаларды автоматты түрде өшіру; 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-челленджді ASN үшін WAF-қа қосты, ретраларды шектеді.

6. Ретро: SLI 'callback _ success _ ratio' -ге, алерт 'queue _ lag _ seconds' -ке қосылды.

13) Кезеңдер бойынша енгізу

1. SLO-дизайн үшін 4-6 сыни флоу (логин, депозит, шығару, ойынды іске қосу, ставка).

2. RED/USE + бизнес-SLI өлшемдері; лейблдердің бірыңғай схемасы.

3. c '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 метрикасы, ойыншы мен ақшаның бүкіл жолы арқылы байланысты логтер мен трассалар. Қате бюджет бойынша алертинг тәртібін қосыңыз, телеметрияның құнын бақылаңыз, құпиялылықты сақтаңыз - команда болжай алмайды, бірақ проблемалардың себептерін көріп, оны ойыншылар байқағанға дейін жөндейді.