Monitoring va logografiya

1) Nima uchun bu iGamingda muhim?

Real vaqtdagi pul: depozitlarni qabul qilish, bir zumda to’lovlar, stavkalar va yutuqlarni hisoblash, turnirlar - hamma kechikish va nosozliklarga sezgir.
Tartibga solish va audit: harakatlarning to’liq izlanishi talab etiladi (KYC/AML, to’lovlar, mas’uliyatli o’yin limitlari).
Murakkab taqsimlangan arxitektura: API-shlyuzlar, to’lovlar orkestri, EDA/Kafka, provayder xizmatlari, mobil mijozlar, frontlar, BI-shina.
Maqsad: MTTD/MTTRni qisqartirish, oltin signallar bo’yicha SLOni ushlab turish va hodisalarning forenzikasini ta’minlash.

2) Kuzatishning bazaviy tushunchalari

Logi: tekshirish va audit uchun yaroqli bo’lgan batafsil voqealar (JSON tuzilmasi).
Metriklar: vaqt bo’yicha agregatlar (TSDB), SLO/alertlar uchun mos keladi.
Treyslar: servislar/brokerlar/DB orqali so’rovlarning sababiy-oqibatli zanjirlari (trace/span).
Eventlar: domen voqealari (BetPlaced, DepositApproved) - biznes metriklar va texnika o’rtasidagi ko’prik.

3) «Oltin signallar» va iGaming uchun SLI/SLO

Latency: tanqidiy oqimlar bo’yicha P95/P99 (avtorizatsiya, depozit, stavka, sessiya boshlanishi, spin).
Traffic: API bo’yicha RPS, to’lovlar bo’yicha TPS, voqealar bo’yicha EPS.
Errors: 5xx/4xx, decline-rate, failed-withdrawals ulushi, provayderlarning xatolari.
Saturation: CPU, memory, IO, Kafka lag, DB connections, thread-pools.

• SLI: `1 - (failed_payments / total_payments)`
• SLO: 99. 7% muvaffaqiyatli avtorizatsiya kartalari 30 kun ichida (error budget 0. 3%).

4) Yig’ish va qayta ishlash arxitekturasi

1. Injest: agentlar (OTel Collector/Fluent Bit), ilovadagi SDK, RUM/sintetika.
2. Marshrutlash: broker/shina telemetriya (OTLP/HTTP/GRPC), filtrlar va kamuflyaj PII.

• Metriklar: TSDB (agregatsiyalar, downsampling).
• Loglar: hot (indekslanadigan )/warm (indekslanadigan )/cold (obyekt ombori, WORM).
• Treyslar: retensiyalar va tail-sampling bilan time-indexed storage.
• 4. Tahlillar/alertlar: qoidalar (PromQL/LogQL/SQL), treysomiya va relizlar bilan bog’lanish.
• 5. Dashbordlar: texnik + biznes turlari (to’lovlar, RNG/provayderlar, turnir dvigateli).

5) Loglar standarti (JSON) va hodisalar taksonomiyasi

Qattiq JSON, yagona kalitlar va darajalar tavsiya etiladi.

Уровни: `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 (faqat ruxsat etilgan maydonlarni saqlaymiz), email/telefon - xesh/token.
• IP/24 gacha kesiladi, GeoIP alohida saqlanadi.
• Foydalanuvchi tomonidan kiritiladigan’extra’dagi bepul matnni sanitayzasiz taqiqlaymiz.

6) Korrelyatsiya: trace_id, correlation_id, idempotency_key

Har bir log va metrikaga’trace _ id’(OTeldan),’span _ id’,’correlation _ id’(biznes-jarayon orqali),’idempotency _ key’(to’lov so’rovlari uchun) qo’shilsin.
Kesish uchun baggage (tenant/brand, market, A/B-variant) ni uzatish.

7) Metrika: texnik va biznes

Texnik: RPS, p95 latency, error rate, saturation, GC, pool usage, Kafka consumer lag.
Biznes: CR ro’yxatdan o’tish → depozit, muvaffaqiyatli avtorizatsiya, to’lovlarni bekor qilish, NGR/GGR, ARPPU, RTP anomaliyalari, KYC bosqichidagi drop-off, mas’ul limitlar ulushi.

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

8) Treysing va OpenTelemetry

Geytvey, to’lov orkestratori, o’yin yadrosi, bildirishnomalar, KYC/AML, provayderlar bilan integratsiya.
Umumiy oqim uchun Head-sampling + xatolar/yashirin spanlar va to’lovlar uchun tail-sampling (oshirilgan).
Kontekst targ’iboti:’traceparent ’/’ tracestate’, Kafka headers, gRPC metadata.
«BetPlaced», «WithdrawalRequested» kabi domen hodisalari bilan izohlang.

9) Shovqinsiz alerting

Ko’p bosqichli ostonalar (warning/critical), flappingni bostirish, deduplikatsiya, taym-slotlar.
Korrelyatsiya: «o’sish 5xx» + «Kafka lag» + «p95 latency PSP» → bitta hodisani bog’laymiz.
SLO-based alertlar: sarflaymiz error-budget - eskalatsiya.
Alerts-as-Code (GitOps), revyu va qoidalar testlari.

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) Loglar bo’yicha qidirish (LogQL misoli)

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

Maqsad shovqinni tezda olib tashlash va maqsadli hududda «qimmatbaho» nosozliklarni aniqlash.

11) Dashbordlar: nima majburiy

Payments Health: PSP bo’yicha muvaffaqiyat/muvaffaqiyatsizliklar, latency usuli, hududlar xaritasi, provayderlarning SLA.
Game Core: RPS provayderlar bo’yicha, p95 orqa, error ratio SDK, RTP slotlar bo’yicha anomaliyalar.
Player Journey: ro’yxatdan o’tish → KUS → depozit → o’yin → chiqish (konversion huni, qadamlar orasidagi vaqt).
Infra: Kafka lag, DB connections, cache hit ratio, Kubernetes klasteri.

12) Saqlash, retensiya va qiymat (FinOps)

Nazorat ostidagi kardinallik: yuqori o’zgaruvchan yorliqli metriklardan qochish (user_id).
Retensiya: metrika hot 30-90 dn., downsampling 13 oygacha; hot 7-14 kun, warm 30-90 kun, cold 1-3 yil (tartibga solishni hisobga olgan holda).
Audit-loglar uchun WORM/immutability, Object Lock.
Siqish/partiyalashtirish va ILM siyosati; audit/PII-safe uchun alohida indekslar.
INFO/DEBUG da log sampling; ERROR/AUDIT - to’liq.

13) Xavfsizlik va komplayens

PII/PCI: tokenlash, xeshlash, niqoblash; ma’lumotlarni minimallashtirish.
RBAC/ABAC: loglar/treyslarga kirish - rollar bo’yicha, tentlarni ajratish.
Sirlar va kalitlar: credentials/tokenlarni noto’g’ri ishlatish; CI uchun maxfiy detektorlar.
Audit-trail: ma’muriy idoraga kirish, limitlar/to’lovlarni o’zgartirish, balansni qo’lda tuzatish - faqat AUDIT-indeksga o’zgarishsiz.
Legal-hold: tekshiruvlarda retensiyalarni muzlatish mexanizmi.

14) Telemetriya ma’lumotlarining sifati

Loglar/iventlar uchun Schema Registry (version, moslik).
Maydonlarning yagona nomenklaturasi (snake_case, o’lchov birliklari).
Injestda validatsiya (iflos voqealar, nikoh metrikasi).
Backpressure va «boʻronlardan» himoya qilish.

15) SRE-jarayonlar, onkoll va runbuklar

Onkoll-matritsasi va eskalatsiyasi; Quiet Hours va rotatsiyalar.
Runbuklar alertlarga bog’langan (diagnostika qadamlari, SQL/LogQL retseptlari, degradatsiya uchun ficheflaglar).
Postmortem jazosiz, action items egalari va muddatlari bilan.
Buyruq indikatorlari: MTTD/MTTR, shovqinli alertlar foizi, runbuklar bilan qoplangan.

16) RUM va sintetika

RUM: WebVitals (LCP, CLS, INP), front xatolari, qurilmalar izlari, hududlar/provayderlar.
Sintetika: turli mintaqalardan «ro’yxatdan o’tish → depozit → spin → chiqish» stsenariylari; ichki yo’llar uchun shaxsiy joylar (ma’muriy/bek-ofis).

17) Relizlar, eksperimentlar va fizeflaglar amaliyoti

Relizlar (commit/artefact) versiyalari bilan treyslarni linklash.
Baggage → dashborddagi A/B-teglar «eksperimentning SLIga ta’siri».
Canary/Blue-Green: kanareykalar uchun alohida panellar, error-budget burn rate.

18) Anomaliyalar va anti-frod signallarini aniqlash

Statistik triggerlar (seasonality-aware) decline-rate/chargeback-risk/yangi xaritalarning ko’payishi.
Korrelyatsiyalar: «muvaffaqiyatsiz depozitlarning o’sishi + PSP-adapterning yangi chiqarilishi».
Near-real-time reaksiyalar uchun striming qoidalari (Kafka → Flink).

19) Joriy etish yo’l xaritasi (bosqichlar bo’yicha)

0-bosqich - Bazis: JSON-loglar, yagona korelatsiya maydonlari, xizmatlarning bazaviy metrikalari, umumiy dashbordlar, birinchi alertlar.
1-bosqich - Treysing: OTel-instrumentlash, head + tail sampling, loglar bilan bog’lanish.
2-bosqich - Biznes-SLI/SLO: to’lovlar/xulosalar/o’yin metrikalari, SLO-alertlar, error-budget jarayonlari.
3-bosqich - Etuklik: Alerts-as-Code, ILM, alohida retensiyalar, anomaliya-detekt, runbuka pers-xizmati, CI/CDda SRE-amaliyotlar.

20) Revyu uchun chek-varaq

• Faqat JSON, bitta kalitlar, PII-niqob.
• Har bir hodisada:’trace _ id’,’span _ id’,’correlation _ id’,’tenant’.
• Metriklar oltin signallar va biznes oqimlarini qamrab oladi.
• SLO tasvirlangan, error-budget va burn rate alertlari mavjud.
• Tail-sampling to’lov xatolari va yuqori maxfiylik uchun kiritilgan.
• ILM/retensiyalar va WORM audit-loglar uchun moslashtirilgan.
• Telemetriya uchun RBAC, kirish auditi.
• Payments/Game Core/Player Journey/Infra bo’yicha dashbordlar.
• Runbuklar har bir tanqidiy alertga bogʻlangan.
• Postmortemalar va action items - egalari bilan beklogda.

A ilovasi: OpenTelemetry atributlari (tavsiya)

`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`

Ilova B: SLO uchun metrika namunalari

`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`

Ilova C: tezkor tekshirish retsepti

"O’sib bormoqda’payment _ error _ rate’→ PSP/mintaqa/usul bo’yicha solishtirish, tail-treyslarni tekshirish, adapter chiqarilishini ko’rish.
«p99 spin ↑» → trassalar front → geytvey → provayder, provayder/kanallarni tekshirish, thread-pullar limitlari, tarmoq retraylari.
«Kafka lag ↑» → health konsumerlar, retrajlar prodyuserlari, backpressure, sekin sinks/DB.