ტელემეტრია და მოვლენების შეგროვება

1) დანიშვნა და პრინციპები

• მოვლენების ერთიანი და პროგნოზირებადი ნაკადი ანალიტიკოსებისთვის, ანტიფროდისთვის, RG, კომპლენსისთვის და ML- სთვის.
• კვალდაკვალ (მომხმარებლის/სესიის/ნაკადის/ტრასის) და რეპროდუქცია.
• PII- ის მინიმიზაცია და კონფიდენციალურობის მოთხოვნების დაცვა.

Принципы: schema-first, privacy-by-design, idempotency-by-default, observability-by-default, cost-aware.

2) მოვლენების ტაქსონომია

გადახდა: 'payment. deposit`, `payment. withdrawal`, `payment. chargeback`.
თამაში: 'game. session_start/stop`, `game. bet`, `game. payout`, `bonus. applied`.
მომხმარებლის: 'auth. login`, `profile. update`, `kyc. status_changed`, `rg. limit_set`.
ოპერაციული: 'ap. request`, `error. exception`, `release. deploy`, `feature. flag_changed`.
შესაბამისობა: 'aml. alert_opened`, `sanctions. screened`, `dsar. requested`.

თითოეულ ტიპს აქვს მფლობელი, სქემა და ახალი SLO.

3) სქემები და კონტრაქტები

• `event_time` (UTC), `event_type`, `schema_version`, `event_id` (UUID/ULID),
• `trace_id`/`span_id`, `request_id`, `user. pseudo_id`, `session_id`,

json
{
"event_id": "01HFY1S93R8X",
"event_time": "2025-11-01T18:45:12. 387Z",
"event_type": "game. bet",
"schema_version": "1. 4. 0",
"user": {"pseudo_id": "p-7a2e", "age_band": "25-34", "country": "EE"},
"session": {"id": "s-2233", "device_id": "d-9af0"},
"game": {"id": "G-BookOfX", "provider": "StudioA", "stake": {"value": 2. 00, "currency": "EUR"}},
"ctx": {"ip": "198. 51. 100. 10", "trace_id": "f4c2...", "request_id": "req-7f91"},
"labels": {"market": "EE", "affiliate": "A-77"}
}

სქემების ევოლუცია: სემანტიკური ვერსიები; backward compatible - დაამატეთ nullable ველი; breaking - მხოლოდ ახალ ვერსიაში ('/v2 ') ორმაგი ჩაწერის პერიოდით.

4) ინსტრუმენტაცია: სად და როგორ

4. 1 კლიენტი (ვებ/მობილური/Desktop)

SDK ტელემეტრია ადგილობრივი ბუფერით, batch გაგზავნა, ექსპონენციალური რეკრუტები.
ავტო მოვლენები: ვიზიტები, კლიშეები, ბლოკების ხილვადობა, ვებ - ვიტალები (TTFB, LCP, CLS), JS შეცდომები.
იდენტიფიკატორები: 'Device _ id' (სტაბილური, მაგრამ პირადი), 'session _ id' (განახლებულია), 'user. pseudo_id`.
„ხმაურისგან“ დაცვა: dedup 'event _ id', trottling, client-side sampling.

4. 2 სერვერი/ზურგჩანთა

OpenTelemetry (OpenTlemetry) - აფეთქების ღუმელის მინანქარი.
'Trace _ id' სავალდებულო გადინება edge/gateway- დან ყველა downstream სერვისებში.
Outbox შაბლონი დომენის მოვლენების გარიგების გამოქვეყნებისთვის.

4. 3 პროვაიდერები/მესამე მხარეები

კონექტორები (PSP/KYC/სტუდია) მასპინძელი სქემების ნორმალიზაციით; ოფიციალური გადამყვანები.
Payload- ის მთლიანობის ხელმოწერა/შემოწმება, პერიმეტრის ჟურნალისტიკა (ingest audit).

5) OpenTelemetry (OTel)

ბილიკები: თითოეული მოთხოვნა იღებს 'trace _ id'; ჩვენ ვუკავშირებთ ლოგებს/მოვლენებს 'trace _ id '/' spank _ id' საშუალებით.
ლოგიკა: გამოიყენეთ OTel Logs/გადამყვანი; საშუალო სამსახურის ეტიკეტები. name`, `deployment. env`.
მეტრიკა: RPS/latence/error-rate სერვისები, ბიზნეს მეტრიკა (GGR, კონვერტაცია).
კოლექტორი: ერთი მისაღები წერტილი/ბუფერი/ექსპორტი კაფკაში/HTTP/გრაფიკში. დასტის.

6) იდენტიფიკატორები და კორელაცია

'event _ id' არის უნიკალურობა და იდემპოტენტობა.
`user. pseudo _ id '- სტაბილური ფსევდონიმი (ცალკე და შეზღუდული).
'session _ id', 'request _ id', 'trace _ id', 'device _ id' სავალდებულოა დასრულების ანალიზისთვის.
ID- ის კოორდინაცია API კარიბჭის და SDK- ის დონეზე.

7) სემპლაცია და მოცულობის კონტროლი

წესები: per-event ტიპი, per-barket, დინამიური (ადაპტირებული) დატვირთვით.
ზუსტად გადაღებული მოვლენები: გადახდა/შესაბამისობა/ინციდენტები - არ არის შერწყმული.
ანალიტიკური მოვლენები: დასაშვებია 10-50% -იანი მაკორექტირებელი წონა ფანჯრებში.
Server side side downsampling: მაგალითად, მაღალი ფრენის მეტრიკისთვის.

8) კონფიდენციალურობა და შესაბამისობა

მინიმუმამდე დაიყვანეთ PII: შეამოწმეთ PAN/IBAN/email; IP - გეო კოდი/ASN ingest.
რეგიონალიზაცია: გაგზავნეთ რეგიონალურ ინგესტის ენდოინტებში (EEA/UK/BR).
DSAR/RTBF: პროექციების შერჩევითი დამალვის მხარდაჭერა; იურიდიული ოპერაციების ჟურნალი.
შენახვის პოლიტიკა: ტიპის ვადები (ანალიტიკა უფრო მოკლეა, მარეგულირებელი უფრო გრძელია); Legal Hold.

9) ტრანსპორტი და ბუფერიზაცია

კლიენტი Edge: HTTPS (HTTP/2/3), 'POST/telemetry/batch' (100-მდე მოვლენა).
Edge - Shina: Kafka/Redpanda 'user- ით. pseudo_id`/`tenant_id`.
ფორმატები: JSON (ingest), Avro/Protobuf (ავტობუსში), Parquet (ტბაში).
საიმედოობა: retrais ერთად jitter, DLQ, poison-pill იზოლაცია.

json
{
"sdk": {"name":"igsdk-js","version":"2. 7. 1"},
"sent_at": "2025-11-01T18:45:12. 500Z",
"events": [ {... }, {... } ]
}

10) საიმედოობა და იდემპოტენტურობა

Client-generated 'event _ id' + სერვერის დედაპლატი '(event _ id, წყარო)'.
Outbox სერვისებზე, Exactly-Once სემანტიკა ნაკადში (keyed state + dedupe).
შეკვეთა კლავიშში: განაწილება 'user/session'.
დროის კონტროლი: NTP/PTP, დასაშვები დრიფტი (მაგალითად, 200 ms), 'received _ at' სერვერზე.

11) ტელემეტრიული ხარისხი (TQ) და SLO

Completeness: ≥ 99. კრიტიკული ტიპების მოვლენების 5% T- სთვის.
Freshness: p95 მიწოდების შეფერხება Silver-15..
Correctness: მოქმედი სქემები 99. 9%, drop-rate < 0. 1%.
Trace coverage: მოთხოვნების წილი 'trace _ id' 98% -ით.
Cost/GB: მიზნობრივი ბიუჯეტი ინგესტის/შენახვის დომენებისთვის.

12) დაკვირვება და დაშბორდები

• Lag ingest (p50/p95) წყაროების და რეგიონების მიხედვით.
• კომპლექსი მოვლენების ტიპებსა და ბაზრებზე.
• მიკროსქემის/კონფიგურაციის შეცდომები.
• SDK ვერსიების რუკა და მოძველებული მომხმარებლების პროცენტი.
• ვებ - ვიტალების კორელაცია - კონვერტაცია/უკმარისობა.

13) კლიენტის SDK: მოთხოვნები

მსუბუქი footprint, ოფლაინ-ბუფერი, შეფერხებული ინიციალიზაცია.
პარამეტრები: sampling, max batch size, max queue age, კერძო მოდის (no-PII).
დაცვა: პაკეტის ხელმოწერა/anti-tamper, ღილაკების შეფუთვა.
განახლება: feature დროშები ხმაურიანი მოვლენების გამორთვისთვის.

14) Edge ფენა და დაცვა

Rate limit, WAF, schema ვალიდაცია, კომპრესია (gzip/br).
ტოკენის ბუკეტი კლიენტისთვის; anti replay ('request _ id', TTL).
IP და UA- ს ამოღება არის ნორმალიზაცია/გამდიდრება „ნედლი“ პაილოდის გარეთ.

15) ინტეგრაცია კონვეიერთან

Bronze: შეუქცევად-დამატებული ნედლეული payload (საყრდენისთვის).
ვერცხლი: ნორმალიზებული ცხრილი ბაბუის/გამდიდრებით.
ოქროს: ფანჯრები BI/AML/RG/პროდუქტისთვის.
ლინგინგი მოვლენებსა და მოხსენებებს შორის; ტრანსფორმაციების ვერსიები.

16) კლიენტის ხარისხის ანალიტიკა

„მშვიდი მომხმარებლების“ კოეფიციენტი (არ არსებობს მოვლენები N საათში).
„ქარიშხლის“ ანომალიები.
„მოძველებული SDK- ის“ წილი ვერსიებისა და პლატფორმების მიხედვით.

17) პროცესები და RACI

R: Data Platform (ingest/საბურავი/მიმღები), App Teams (SDK ინსტრუმენტაცია).
A: Head of Data/Architecture.
C: Compliance/DPO (PII/retention), SRE (SLO/ინციდენტები).
I: BI/მარკეტინგი/რისკი/პროდუქტი.

18) გზის განხორციელების რუკა

1. V1 + JSON სქემების მოვლენების ტაქსონომია 6-8 ტიპისთვის.

2. SDK (Web/Android/iOS) с batch и sampling; Edge `/telemetry/batch`.

3. Kafka + Bronze ფენა; ძირითადი ვალიდატორები და დედაპლატი.

4. Dashboard ingest lag/completeness, alertes drop/completator.

• OTel Collector, სავაჭრო კორელაცია; ვერცხლის ნორმალიზაცია და DQ წესები.
• რეგიონალური ენდოინები (EEA/UK), კერძო მოდის, DSAR/RTBF პროცედურები.
• SDK ვერსიების რუკა, რგოლების განახლებები.

• Exactly-Once ნაკადებში, Feature Store, ანტიფროგრამის ონლაინ ფიდები.
• Rule-as-Code სქემებისა და მოვალეობებისთვის, ცვლილებების სიმულაციისთვის (impact analysis).
• ღირებულების ოპტიმიზაცია: adaptive sampling, Z-order/კლასტერიზაცია ტბაში.

19) ხარისხის ჩეკის სია გამოშვებამდე

• შევსებულია სქემის სავალდებულო ველები და სწორი ტიპები.
• არის 'trace _ id '/' request _ id '/' session _ id'.
• SDK მხარს უჭერს batch, retry, sampling.
• Edge უხელმძღვანელებს სქემას და ზღუდავს payload- ის ზომას.
• ჩართულია ფილტრების კონფიდენციალურობა და მგრძნობიარე ველების ტოქსიკაცია.
• SLO/alerty და dashbords მორგებულია.
• დოკუმენტაცია დომენებისთვის (მოვლენის მაგალითი, owner, SLA).

20) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

ნედლეული მოვლენები სქემების გარეშე: შეიყვანეთ რეგისტრი და CI სავალდებულო.
არ არსებობს idempotention: მოითხოვეთ 'event _ id' და შეინახეთ ბაბუის ფანჯრები.
PII ნაზავი და ანალიტიკოსები: გამოყავით მაპინგები, შეავსეთ ველები.
ტრეიზინგის ნაკლებობა: განათავსეთ 'trace _ id' gateway სერვისების საშუალებით.
უკონტროლო მოცულობა: გამოიყენეთ sampling/trottling და budget კვოტები.
გლობალური endpoint რეგიონების გარეშე: გამოიყენეთ რეგიონალიზაცია და მონაცემთა აღდგენა.

21) გლოსარიუმი (მოკლედ)

OpenTelemetry (OTel) არის ღია სტანდარტი ტრეისების/მეტრიკის/ლოგებისთვის.
Outbox არის დომენის მოვლენების გარიგების გამოქვეყნება.
DLQ არის „გატეხილი“ შეტყობინებების რიგი.
Sampling - ღონისძიებების ნაწილის შერჩევა მოცულობის შესამცირებლად.
მონაცემთა აღდგენა - მონაცემთა შენახვა სასურველ იურისდიქციაში.

22) შედეგი

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