Мониторинг жана Логин

1) Эмне үчүн iGaming маанилүү

Реалдуу убакытта акча: депозиттерди кабыл алуу, дароо төлөмдөр, коюмдарды жана утуштарды эсептөө, турнирлер - баары кечигүүлөргө жана мүчүлүштүктөргө сезгич.
Жөнгө салуучу жана аудит: иш-аракеттердин толук байкоо талап кылынат (KYC/AML, төлөмдөр, жоопкерчиликтүү оюндун лимиттери).
Татаал бөлүштүрүлгөн архитектура: API-шлюздар, төлөмдөрдү топтоо, EDA/Kafka, провайдерлердин кызматтары, мобилдик кардарлар, фронттор, BI-шина.
Максаты: MTTD/MTTR кыскартуу, алтын сигналдар боюнча SLO кармап жана окуяларды форензия камсыз кылуу.

2) Байкоонун негизги түшүнүктөрү

Logs: деталдуу окуялар (JSON структураланган) тергөө жана аудит үчүн жарактуу.
Метрика: убакыт агрегаттары (TSDB), SLO/alerts үчүн ылайыктуу.
Traces: себептик суроо-чынжыр (trace/span) аркылуу кызмат/брокерлер/DD.
Events: Domain Events (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. 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).
• Tracks: Retenties жана tail-sampling менен убакыт-indexed storage.
• 4. Аналитика/Алерт: эрежелер (PromQL/LogQL/SQL), Trejsamia жана релиздер менен байланыш.
• 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 жашыруу (саясат гана уруксат талааларды сактоо), электрондук почта/тел - хэш/токен.
• IP/24 чейин кесип, GeoIP өзүнчө сактоо.
• Санитайзерсиз колдонуучу киргизүү үчүн 'extra' эркин текстке тыюу салынат.

6) Байланыш: trace_id, correlation_id, idempotency_key

Ар бир журналга жана метрикага 'trace _ id' (OTelден), 'span _ id', 'correlation _ id' (бизнес-процесс үчүн), 'idempotency _ key' (төлөм суроо-талаптары үчүн) кошулат.
тилкелерди куруу үчүн багаж (tenant/brand, market, A/B-параметр).

7) Metrics: техникалык жана бизнес

Техникалык: 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) Trace жана OpenTelemetry

Биз гейтвейлерди, төлөм оркестраторун, оюн өзөгүн, эскертмелерди, KYC/AML, провайдерлер менен интеграцияны инструменттейбиз.
Жалпы агым үчүн Head-sampling + tail-sampling (жогорулатылган) каталар/жашыруун спан жана төлөмдөр үчүн.
Контексттин пропагандасы: 'traceparent '/' tracestate', Kafka headers, gRPC metadata.
домендик окуялар менен уктап түшүндүрмө: 'BetPlaced', 'WithdrawalRequested'.

9) эч кандай ызы-чуу Alerting

Көп баскычтуу босоголор (warning/critical), флаппингди басуу, дедупликация, тайм-слоттор.
Корреляция: байлап "өсүү 5xx" + "Kafka lag" + "p95 latency PSP" → бир окуя.
SLO-based alerty: жумшап error-budget - эскалация.
Alerts-as-Code (GitOps), Review жана сыноо эрежелери.

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) Dashbord: эмне милдеттүү

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

12) сактоо, кабыл алуу жана наркы (FinOps)

контролдоо боюнча кардиналдуулук: жогорку өзгөрүлмө этикеткалар менен метриктер качуу (user_id).
Retens: метр hot 30-90 күн., 13 айга чейин downsampling.; hot 7-14 күн, warm 30-90 күн, cold 1-3 жыл (жөнгө салуу эске алуу менен).
WORM/Object Lock.
Кысуу/партиялаштыруу жана ILM саясаты; аудит/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 Recipes, деградация үчүн phicheflages) менен байланышкан.
Postmortem жазасыз, ээлери жана мөөнөтү менен action items.
Команданын көрсөткүчтөрү: MTTD/MTTR, ызы-чуу коркунучтардын пайызы, runbook каптоо.

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

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

17) Релиздер, эксперименттер жана phicheflags практикасы

Linkuem чыгаруу нускалары менен соода (commit/artefact).
A/B-теги багаж → dashboard "SLI боюнча эксперимент таасири".
Canary/Blue-Green: канарейка үчүн өзүнчө панелдер, error-budget burn rate.

18) Аномалияларды жана анти-frod сигналдарды аныктоо

Статистикалык триггерлер (seasonality-aware) decline-rate/chargeback-risk/жаңы карталардын өсүшү боюнча.
Корреляциялар: "Ийгиликсиз депозиттердин өсүшү + PSP адаптеринин жаңы релизи".
Striming эрежелери (Kafka → Flink) үчүн near-real-time жооп.

19) Ишке ашыруунун жол картасы (этаптар боюнча)

Этап 0 - Базис: JSON-логи, бирдиктүү кореляциялык талаалар, кызматтардын базалык метриктери, жалпы дашборддор, биринчи алерталар.
Этап 1 - Trace: OTel-instrumentation, head + tail sampling, логиндер менен байланыш.
Этап 2 - Бизнес-SLI/SLO: төлөмдөр/корутундулар/оюн метриктери, SLO-алерттер, error-budget процесстери.
Этап 3 - Жетилүү: Alerts-as-Code, ILM, өзүнчө ретенциялар, аномалия-детект, per-service runbook, CI/CD SRE практикалары.

20) Ревю үчүн чек баракчасы

• JSON гана Логи, бирдиктүү ачкычтар, PII-маскировка.
• Ар бир окуяда: 'trace _ id', 'span _ id', 'correlation _ id', 'tenant'.
• Metrics алтын сигналдарды жана бизнес агымдарын камтыйт.
• SLO сүрөттөлгөн, burn rate боюнча error-budget жана alerts бар.
• Tail-sampling төлөм каталар жана жогорку жашыруун үчүн киргизилген.
• ILM/Retents жана WORM аудиттер үчүн ылайыкташтырылган.
• Телеметрия боюнча RBAC, кирүү аудит.
• Payments/Game Core/Player Journey/Infra боюнча Dashboard.
• Рунбуктар ар бир критикалык алерт менен байланышкан.
• Postmortems жана 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: тез изилдөө Recipes

"Өсүүдө 'payment _ error _ rate'" → PSP/аймак/ыкма боюнча салыштырып, tail-соодалоого текшерүү, адаптердин бошотуу көрүү.
"p99 spins ↑" → трасса фронт → Gateway → провайдер, провайдер/каналдарды, thread-пулдун чектерин, тармактык ретраларды текшерүү.
"Kafka lag ↑" → ден соолук консумерлери, продюсерлердин ретрайлери, backpressure, жай sinks/DD.