დაკვირვება და ტელემეტრია

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

დაკვირვება არის პასუხის უნარი „რატომ მუშაობს ასე?“ ახალი ბილეთების გამოშვების გარეშე. IGaming- ში ეს კრიტიკულია: პიკის ტურნირები, გადახდის მწვერვალები, მრავალფეროვნება და პასუხისმგებელი გამბინგის მოთხოვნები/PII. საფუძველი არის მეტრიკა, ლოგოები, ტრეკები, რომლებიც გაერთიანებულია ზოგადი იდენტიფიკატორებისა და სტანდარტებით (OpenTelemetry), SLO კონტრაქტებით, ხმაურიანი ალერტინით და ღირებულების კონტროლით.

1) დაკვირვების ჩარჩო: რა შედგება

მეტრიკა (დროის ნომრები): RED/USE, ბიზნეს KPI, SLI. ინახება TSDB- ში.
ლოგოები (მოვლენები ტექსტში/JSON): აუდიტი, შეცდომები, ბიზნეს ფაქტები, უსაფრთხოება.
კვალი (სპანები): მოთხოვნის გზა სერვისების, ლატენტობის, შეფერხებების მიზეზების საშუალებით.
პროფილინგი: CPU/მეხსიერება/eBPF ნაკადები, heap/ლოკის კონტენტი.
RUM და სინთეზური: რეალური მომხმარებლები (ვებ/app) + რობოტის შემოწმება.
ტელემეტრიული კატალოგი: სქემები, PII პოლიტიკა, შენახვის დრო, ღირებულების ტეგები.

2) სიგნალების და პრინციპების ტაქსონომია

RED для API: Rate, Errors, Duration.
USE ინფრასტრუქტურისთვის: Utilization, Saturation, Errors (CPU, დისკები, ქსელი, რიგები).
SLI/SLO: გაზომილი ინდიკატორები (მაგალითად, წარმატებული მოთხოვნები/ყველა, p95 ლატენცია), ხელმისაწვდომობის მიზნები (მაგ., "99. 9% 30 დღეში"), შეცდომების ბიუჯეტი - პროცესების გამომწვევი.
მაღალი სტანდარტული გონებით: ეტიკეტები სასარგებლო უნდა იყოს განყოფილებებში (რეგიონი/ტენანტი/პროვაიდერი), მაგრამ არ აფეთქდეს TSDB.

3) სტანდარტები და კორელაცია

OpenTelemetry (OTel): ერთი SDK/პროტოკოლი მეტრიკის, ლოგებისა და ტრეკებისთვის.
იდენტიფიკატორები: 'trace _ id', 'spank _ id', 'correlation _ id', 'player _ id' (ფსევდონიმი), 'payment _ route'.
ID ნაკადი: შეყვანის კარიბჭე - ყველა მიკროსერვისი - გადახდა/PSP - რიგები/ჯობი, ლოგები/მეტრიკები/სპანები.

მაგალითი: კორელაციის სათაურები

traceparent: 00-<trace_id>-<span_id>-01 x-request-id: <correlation_id>

4) მეტრიკა: რა და როგორ გავზომოთ

სახელები/ეტიკეტები

`service="payments-api"`, `env="prod"`, `region="eu-west"`, `tenant`, `provider="pspX"`.

მაგალითები Prometheus

prometheus
RED http_requests_total{service="api",route="/deposit",method="POST",status="200"}
http_request_duration_seconds_bucket{service="api",le="0. 25",route="/deposit"} 1234 http_request_errors_total{service="api",route="/deposit"}

USE cpu_utilization_ratio{node="n1"} 0. 71 queue_depth{queue="withdrawals"} 128

Бизнес payments_success_total{psp="X",currency="EUR"} 4521 payment_conversion_ratio{route="pspX"} 0. 948

Histograms და exemplars

შეინახეთ ლატენტობის ჰისტოგრამები (native-histograms/cuckets) და დააკავშირეთ exemplar 'trace _ id- ით „ნელი ბაკეტიდან“ კონკრეტულ ტრეკზე გადასასვლელად.

5) ლოგები: სტრუქტურირებული და უსაფრთხო

მხოლოდ JSON (გაყიდვაში არ არის „უფასო ფორმა“).
Поля: `timestamp`, `severity`, `service`, `trace_id`, `correlation_id`, `player_id_hash`, `event`, `amount`, `currency`, `ip_hash`.
შენიღბვა/ჰაშირება PII, ინდივიდუალური ინდექსები/რეპენტაცია მგრძნობიარე.
Logs Payplines: პარსინგი - ნორმალიზაცია, გამდიდრება (geo/ASN), PII რედაქტირება და ინდექსაცია.

JSON მოვლენის მაგალითი

json
{
"ts":"2025-11-05T10:42:31Z",
"sev":"ERROR",
"service":"payments-api",
"event":"psp_timeout",
"trace_id":"9c5e...e2",
"route":"pspX",
"duration_ms": 3100,
"attempt":2,
"player_id_hash":"p:1b7f...",
"pii_redacted":true
}

6) ტრეკები: სად იკარგება დრო

სპანები: შესასვლელი მოთხოვნა, პროვაიდერების ზარები (PSP/თამაშის პროვაიდერები), BD/ქეში, ოფშორული RPC.
ატრიბუტები: 'db. system`, `net. peer. name`, `messaging. system`, `psp. route`, `game. provider`.

• მოცულობისთვის head-based (სავარაუდო),
• tail-based (პირობებით: შეცდომები, p95 +, VIP სეგმენტი),
• guaranteed-keep გადახდის/PII კრიტიკული.

7) წინა და მობილური დაკვირვება

RUM: TTFB, FCP/LCP/CLS/INP, JS შეცდომები, ქსელი და SPA როუტინგი.
ავარიის რეპორტები: სიმბოლიზმი, დეობუსკაცია, ბილეთის ვერსია, მოწყობილობა/OS.
სინთეზური: შესვლის/ანაბრის/განაკვეთების სკრიპტები; გეოგრაფიული შემოწმებები.

8) SLO, SLI და შეცდომების ბიუჯეტი

მაგალითი SLO (ფსევდო-YAML)

yaml service: payments-api sli:
- name: availability expr: sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
- name: latency_p95 expr: histogram_quantile(0. 95, rate(http_request_duration_seconds_bucket[5m]))
targets:
availability: "99. 9%/30d"
latency_p95: "<=250ms/30d"
error_budget_policy:
fast_burn: 5% for 1h -> page, freeze deploy slow_burn: 20% for 24h -> incident, improvement plan

საბიუჯეტო შეცდომების ალერტინგი და არა „ყველა მეტრიკა“.
უფასო პროცედურები ბიუჯეტის დაწვის დროს: შეზღუდეთ გამოშვებები/კანარი.

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

Multi window, multi-burn წესები: მოკლე/გრძელი ფანჯარა.
დედუპლიკაცია/რუტინგი: სერვისები/რეგიონები/კრიტიკა on-call.
Runbook URL და კონტექსტის მანქანა (ბოლო დეპოზიტები, კონფიგურაციის ცვლილებები, დამოკიდებულების გრაფიკი).
მშვიდი საათი და დათრგუნვა დაგეგმილი მუშაობის დროს.

წესის მაგალითი (იდეა PromQL)

promql alert: PaymentsSLOFastBurn expr: slo_error_rate_5m > 2 slo_budget_rate for: 15m labels: { severity="page", service="payments-api" }
annotations:
summary: "SLO fast burn"
runbook: "https://runbooks/payments/slo"

10) პროფილინგი და eBPF

eBPF/პროფილერები: flame გრაფიკები CPU/alloc, I/O ლატენტობა, ქსელის ფრაგმენტები, Syscall ანომალიები.
სასარგებლოა ვიწრო ადგილებში p99, „ჯიტერი“ და იშვიათი ხრახნები.

11) ბიზნესის დაკვირვება

ფინანსები/მონეტიზაცია: დეპოზიტების კონვერტაცია, TTW (time-to-wallet), ავტორები ./settl, გაუქმება/ჩარჟბეკი.
თამაშის აქტივობა: retenshn/strick, ცოცხალი განაკვეთების წილი, პროვაიდერების „წებოვანი“.
ანტიფროდი/აბიუსი: მოქმედების სიჩქარე, მოწყობილობების დამთხვევა/IP, კორელაცია.
RG ინდიკატორები: გრძელი სესიები, „დოგონი“, სტეიკების ზრდა.
ბიზნეს მეტრიკა დაკავშირებულია ტექნიკასა და გამოშვებასთან (annotation events).

12) უსაფრთხოება, PII და შესაბამისობა

Data-zones: Datasets/logs ჭდეები ('pii = true', 'region = EU').
შენიღბვა ინდექსაციამდე, იდენტიფიკატორის ფსევდონიმი.
WORM აუდიტის საცავი; როლური წვდომა ლოგოზე.
შენახვის ვადა: განსხვავებული ტექნოლოგია/აუდიტი/ბიზნესი.
ნედლეულის საიდუმლოებების აკრძალვა; სკანირების შემოწმება CI- ში.

13) FinOps

კარდინალობის ზღვარი: ფრთხილად 'user _ id', 'session _ id'.
განაწილება/გადაშენება: ცხელი (7-14 დღე), თბილი (30-90), ცივი (არქივი).
Tail-based და downsampling მეტრიკა.
ბილინგი 'team', 'service', 'tenant': მოხსენებები „ვინ იწვის დაკვირვებას“.

14) ინსტრუმენტარიუმი (რეფერენდუმის დასტის)

მეტრიკი: Prometheus/Lake მეტრიკისთვის, Grafana dashbords.
Loki/ELK; ingestion წესები, reduction/პარსინგი.
ტრეისი: Tempo/Jaeger/OTel კოლექციონერები; ექსპერიმენტული ლინქები მეტრიკიდან.
სინთეზური: Blackbox ექსპორტიორი, ბრაუზერის რობოტები.
ალერტინგი: Alertmanager/chat ინტეგრაცია, როტაცია.
პროფილინგი: eBPF/Continuous profiling.

15) მაგალითები: ბაზის სწრაფად დანერგვა

python from prometheus_client import Counter, Histogram, start_http_server reqs = Counter('http_requests_total','', ['route','method','status'])
lat = Histogram('http_request_duration_seconds','', ['route'])
def handle(req):
with lat. labels(route=req. route). time():
status = app(req)
reqs. labels(route=req. route,method=req. method,status=str(status)). inc()

go tid:= ctx. Value("trace_id")
logger = logger. With("trace_id", tid)
logger. Info("deposit-accepted", "amount", amt, "route", route)

prometheus http_request_duration_seconds_bucket{..., le="0. 25"} 1023 # exemplar: trace_id=9c5e...

16) პროცესები და ოპერაციები

ერთი მეტრიკის/ეტიკეტის ლექსიკონი (naming guide) და დაშბორდის შაბლონი.
Release-annotations ტყვიამფრქვევი გრაფიკებში.
ინციდენტები: ბარათი, დრო, RCA ბრალდების გარეშე, მოქმედება.
ტრენინგი („თამაშის დღე“): დაცემის იმიტაცია, PSP შეფერხებები, ქეში გადახურვა.
Runbooks: ეტაპობრივი ინსტრუქციები და ალერტების ავტომაგისტრალები.

17) სიმწიფის ჩეკი

1. OTel SDK/კოლექციონერი არის მეტრიკის/ლოგოების/ტრეისების ერთიანი ექსპორტი.
2. RED/USE მოიცავს ყველა სერვისს + SLI/SLO საკვანძო API.
3. კორელაცია 'trace _ id' არის logs-metrics (exemplars, jump-links).
4. შეცდომების ბიუჯეტის ალერტები მრავალ-ბურნიდან და რუნაბუკის ბმულებით.
5. RUM + სინთეზური „ანაბარი/განაკვეთი/გამომავალი“.
6. პროფილინგი (eBPF) თეთრი სიის გასაყიდად.
7. PII პოლიტიკა: შენიღბვა, ზონა, დაშვება, შენახვის დრო.
8. ფინანსური ანგარიში ტელემეტრიული ღირებულების შესახებ (ჭდეები 'team/service').
9. „მზადყოფნა პიკის დატვირთვისთვის“: ტესტის გეგმა, ქეში დათბობა, ალერტის შაბლონები.
10. რეგულარული RCA და SLO/რეიდების გადასინჯვა.

18) ანტიპატერები

Logs „ფურცლები“ სტრუქტურის გარეშე და „trace _ id“.
ალერტა თითოეული მეტრიკისთვის - ალერტ-ფეტიგი.
ჰისტოგრამა სწორი ბანკეტების გარეშე არის „ბრტყელი“ p95.
ეტიკეტების შეუზღუდავი კარდინალობა - ღირებულების აფეთქება.
RUM/სინთეზის არარსებობა არის „ყველაფერი კარგი“, მაგრამ მომხმარებელი არ არის.
PII ნაზავი ტექნოლოგებთან, შეუზღუდავი რეტენციით.
ტელემეტრიული იზოლაცია ბიზნეს KPI- დან - „ლატენტობა ეცემა, შემოსავალიც“.

შედეგები

ძლიერი დაკვირვება არის საერთო ენა პროდუქტს, SRE, უსაფრთხოებას და გადახდებს შორის. OTel- ის მახლობლად მეტრიკის, ლოგიკის, ტრასების შეერთებით, SLO- ს შეცდომების ბიუჯეტით შემოღებით, ალერტინგი ჭკვიანურად და კონტროლირებადი ღირებულებით, თქვენ იღებთ სისტემას, რომელიც ადრე ამჩნევს პრობლემებს, სწრაფად აღდგება და პროგნოზირებულად გადის ტრაფიკის მწვერვალები და ტურნირის დატვირთვები.