მონიტორინგი და ლოჯისტიკა

1) რატომ არის ეს მნიშვნელოვანი iGaming- ში

რეალურ დროში ფული: დეპოზიტების მიღება, მყისიერი გადახდები, განაკვეთების გაანგარიშება და მოგება, ტურნირები - ყველაფერი მგრძნობიარეა შეფერხებებისა და ჩავარდნების მიმართ.
მარეგულირებელი და აუდიტი: საჭიროა მოქმედების სრული ტრეკირება (KYC/AML, გადახდები, საპასუხისმგებლო თამაშის ლიმიტები).
რთული განაწილებული არქიტექტურა: API კარიბჭეები, გადახდის ორკესტრი, EDA/Kafka, პროვაიდერების სერვისები, მობილური კლიენტები, ფრონტები, BI საბურავი.
მიზანი: შეამციროს MTTD/MTTR, შეინარჩუნოს SLO ოქროს სიგნალებით და უზრუნველყოს ინციდენტების წინსვლა.

2) დაკვირვების ძირითადი ცნებები

ლოგიკა: დეტალური მოვლენები (სტრუქტურირებული JSON), რომლებიც შესაფერისია გამოძიებისა და აუდიტის მიზნით.
მეტრიკა: დროის ერთეულები (TSDB) შესაფერისია SLO/alerts- ისთვის.
ტრეისი: მიზეზობრივი საგამოძიებო მოთხოვნის ჯაჭვები (trace/span) სერვისების/ბროკერების/BD მეშვეობით.
ტირიფები: აფეთქების ღუმელის მოვლენები (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).
• Logs: hot (ინდექსირებული )/warm (ნაკლებად ინდექსირებული )/cold (ობიექტის საცავი, WORM).
• Traces: time-indexex სცენა ჭრილობებით და 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 (ჩვენ მხოლოდ პოლიტიკას ვიცავთ), ელ.ფოსტა/ტელეფონი - ჰაში/ნიშანი.
• შეინახეთ IP მდე/24, შეინახეთ ცალკე GeoIP.
• ჩვენ კრძალავს 'extra- ს უფასო ტექსტს მომხმარებლის შეყვანის გარეშე.

6) კორელაცია: trace _ id, correlation _ id, idempotency _ key

დაამატეთ 'trace _ id "(OTel- დან),' spank _ id ',' correlation _ id '(ბიზნესის პროცესის დასრულების შემდეგ),' idempotence _ key '(გადახდის მოთხოვნით).
გადმოგცეთ baggage (tenant/brand, barket, A/B ვარიანტი) ნაჭრების ასაშენებლად.

7) მეტრიკა: ტექნიკური და ბიზნესი

ტექნიკური: RPS, p95 latence, error rate, saturation, GC, აუზი, Kafka consumer lag.
ბიზნესი: CR რეგისტრაცია - ანაბარი, წარმატებული ავტორიზაცია, გადახდის გაუქმება, NGR/GGR, ARPPU, RTP ანომალიები, 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, grRPC metadata.
ჩვენ ვაძლევთ სპილოებს დომენის მოვლენებით: 'BetPlaced', 'WithdrawalRequested'.

9) ალერტინგი ხმაურის გარეშე

მრავალსაფეხურიანი ბარიერები (warning/critical), flupping ჩახშობა, დედუპლიკაცია, დროის სლოტი.
კორელაცია: ჩვენ ვუკავშირებთ „ზრდას 5xx“ + „Kafka lag“ + „p95 latency PSP“ - ერთ ინციდენტს.
SLO-based alerty: ხარჯვა 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- ზე, ლატენტობა მეთოდით, რეგიონების რუკა, SLA პროვაიდერები.
Game Core: RPS პროვაიდერების მიხედვით, p95 უკანა, error ratio SDK, RTP ანომალიები სლოტებში.
Player Journey: რეგისტრაცია - KUS - ანაბარი - თამაში - დასკვნა (კონვერსიული ძაბრი, ნაბიჯებს შორის დრო).
Infra: Kafka lag, DB Connections, cache hit ratio, Kubernetes მტევანი (ქვე/კვანძების ქსელი).

12) შენახვა, რეტენციები და ღირებულება (FinOps)

კონტროლირებადი კარდინალობა: თავიდან აიცილოთ მეტრიკი მაღალი შემცვლელი ეტიკეტებით (user _ id).
რეცენზიები: მეტრიკა ცხელი 30-90 დნ., downsampling 13 თვემდე; logs hot 7-14 Dn., warm 30-90 Dn., cold 1-3 წელი (მარეგულირებლის გათვალისწინებით).
WORM/immutability audit ლოგებისთვის, Object Lock.
შეკუმშვა/განაწილება და ILM პოლიტიკა; ინდივიდუალური ინდექსები audit/PII-safe.
ლოგოების ნიმუში INO/DEBUG; ERROR/AUDIT - სრული.

13) უსაფრთხოება და შესაბამისობა

PII/PCI: ტოქსიკაცია, ჰაშირება, შენიღბვა; მონაცემთა მინიმიზაცია.
RBAC/ABAC: ლოგებზე/ტრეისებზე წვდომა - როლები, ქურთუკების გამიჯვნა.
საიდუმლოებები და გასაღებები: არ გააკეთოთ credentials/ნიშნები; საიდუმლოების დეტექტორები CI- ზე.
აუდიტის ბილიკი: დანართში შესვლა, შეზღუდვების/გადახდების ცვლილებები, ბალანსის სახელმძღვანელო კორექტირება - მხოლოდ AUDIT ინდექსში, უცვლელია.
Legal-hold: გამოძიების დროს ჭრის გაყინვის მექანიზმი.

14) ტელემეტრიული მონაცემების ხარისხი

Schema Registry dogs/Ivents (ვერსია, თავსებადობა).
ველების ერთიანი კონფიგურაცია (snake _ case, გაზომვის ერთეული).
ნებადართვა ინჟესტზე (ბინძური მოვლენების ფრაგმენტი, ქორწინების მეტრიკა).
Backpressure და დაცვა „ლოგოების ქარიშხლებისგან“.

15) SRE პროცესები, ონკოლი და რუნბუკი

ონკოლ მატრიცა და ესკალაცია; Quiet Hours და როტაცია.
რუნბუკები უკავშირდება ალერტებს (დიაგნოზის ნაბიჯები, SQL/LogQL რეცეპტები, დეგრადაციისთვის ფიჩეფლაგები).
Postmortem სასჯელის გარეშე, მოქმედება items მფლობელებთან და ვადებთან.
გუნდის ინდიკატორები: MTTD/MTTR, ხმაურიანი ალერტების პროცენტი, რუნბუკებით დაფარვა.

16) RUM და სინთეზური

RUM: WebVitals (LCP, CLS, INP), წინა შეცდომები, მოწყობილობების ანაბეჭდები, რეგიონები/პროვაიდერები.
სინთეზური: სკრიპტები „რეგისტრაცია, ანაბრის ანაბეჭდისა და სპინ-გამონადენი“ სხვადასხვა რეგიონიდან; პირადი ადგილები შიდა ტრასებისთვის (ადმინისტრაციული/სარეზერვო ოფისი).

17) განთავისუფლების, ექსპერიმენტებისა და ძაფების პრაქტიკა

Linkue trais გამოშვების ვერსიებით (commit/artefact).
A/B ჭდეები baggage - dashboard „ექსპერიმენტის გავლენა SLI- ზე“.
Canary/Blue-Green: ცალკეული კანარის პანელები, error-budget ბურნი.

18) ანომალიების და ანტი-ფროიდის სიგნალების აღმოჩენა

სტატისტიკური გამომწვევი (seasonality aware) decline-rate/chargeback-risk/ახალი ბარათების ზრდა.
კორელაციები: „წარუმატებელი დეპოზიტების ზრდა + PSP ადაპტერის ახალი გამოშვება“.
ნაკადის წესები (Kafka - Flink) რეაქციებისთვის.

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 და ალერტები ბურნის გზაზე.
• Tail-sampling შედის გადახდის შეცდომებისა და მაღალი ლატენტებისთვის.
• ILM/რეტენციები და WORM შექმნილია აუდიტის ლოგოებისთვის.
• RBAC ტელემეტრიაზე, წვდომის აუდიტი.
• დაშბორდები Payments/Game Core/Player Journey/Infra.
• რუნბუკები მიბმული არიან თითოეულ კრიტიკულ ალერტთან.
• postmortems და აქცია 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 სპინი“ - წინა ხაზის კვალი - პროვაიდერი, პროვაიდერის/არხების გადამოწმება, სამი ტყვიის ლიმიტები, ქსელის რეკრუტირება.
„Kafka lag“ არის ჯანმრთელობის კონსულები, პროდიუსერების რესტავრაცია, backpressure, ნელი sinks/BD.