Мониторинг және логирлеу

1) Неге iGaming маңызды

Нақты уақыттағы ақша: депозиттерді қабылдау, жылдам төлемдер, мөлшерлемелер мен ұтыстарды есептеу, турнирлер - барлығы кідірістер мен іркілістерге сезімтал.
Реттеуіш және аудит: іс-қимылдардың толық трассалануы талап етіледі (KYC/AML, төлемдер, жауапты ойын лимиттері).
Күрделі таратылған архитектура: API-шлюздер, төлемдерді оркестрлеу, EDA/Kafka, провайдерлер қызметтері, мобильді клиенттер, фронттар, BI-шина.
Мақсаты: MTTD/MTTR қысқарту, алтын сигналдар бойынша SLO ұстау және инциденттердің форензиясын қамтамасыз ету.

2) Бақылаудың базалық ұғымдары

Логи: тексеру және аудит үшін жарамды егжей-тегжейлі оқиғалар (JSON құрылымдалған).
Өлшемдер: уақыт агрегаттары (TSDB), SLO/алерттер үшін жарамды.
Трестер: сервистер/брокерлер/ДҚ арқылы сұрау салулардың себеп-салдарлық тізбектері (trace/span).
Ivents: домендік оқиғалар (BetPlaced, DepositApproved) - бизнес-метриктер мен техника арасындағы көпір.

3) «Алтын сигналдар» және iGaming үшін SLI/SLO

Latency: сыни ағымдар бойынша P95/P99 (авторизация, депозит, мөлшерлеме, сессияның басталуы, спин).
Traffic: API бойынша RPS, төлемдер бойынша 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. 30 күнде табысты авторизацияланған карталар 7% (error budget 0. 3%).

4) Жинау және өңдеу архитектурасы

1. Инжест: агенттер (OTel Collector/Fluent Bit), қосымшадағы SDK, RUM/синтетика.
2. Бағыттау: брокер/телеметрия шинасы (OTLP/HTTP/GRPC), сүзгілер және PII бүркемелеу.

• Өлшемдер: TSDB (агрегациялар, downsampling).
• Логи: hot (индекстелетін )/warm (аз индекстелетін )/cold (объектілік сақтау орны, WORM).
• Трестер: ретенциялары мен tail-sampling бар time-indexed storage.
• 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 аномалиялары, KYC қадамында drop-off, жауапты лимиттердің үлесі.

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: тіркеу → ҚҰС → депозит → ойын → шығару (конверсиялық құйғыш, қадамдар арасындағы уақыт).
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 for audit-log, 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) Аномалияларды және анти-фрод сигналдарын анықтау

decline-rate/chargeback-risk/жаңа карталардың көтерілуіндегі статистикалық триггерлер (seasonality-aware).
Корреляциялар: «сәтсіз депозиттердің өсуі + PSP-адаптердің жаңа шығарылымы».
near-real-time реакциялары үшін стримингтік ережелер (Kafka → Flink).

19) Енгізу жол картасы (кезеңдер бойынша)

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

20) Ревью үшін чек-парақ

• Тек JSON логтары, бірыңғай кілттер, PII-бүркемелеу.
• Әрбір оқиғада: 'trace _ id', 'span _ id', 'correlation _ id', 'tenant'.
• Метриктер алтын сигналдар мен бизнес ағындарын қамтиды.
• SLO сипатталған, error-budget және burn rate алгоритмдері бар.
• Tail-sampling төлем қателері мен жоғары жасырындылықтар үшін қосылған.
• ILM/Retents және WORM аудиторлар үшін теңшелген.
• 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/БД.