რეალურ დროში მონიტორინგი

(განყოფილება: ოპერაციები და კონტროლი)

1) რატომ არის რეალურ დროში მონიტორინგი

• კრიტიკული მარშრუტების ხელმისაწვდომობისა და შეფერხებების მყისიერი ხილვადობა (p50/p95/p99);
• მოვლენების მთლიანობის კონტროლი (ვებჰუკი, გადახდები, RTP/ლიმიტები);
• ფინანსური უსაფრთხოება (1k მოვლენების egress/ღირებულება, კლირინგი/ესკიზი);
• შესაბამისობის დაცვა (ქვითრები, PII ჰიგიენა).

2) არქიტექტურული წრე

1. Producters: სერვისები, SDK, edge კვანძები, გადახდის/შინაარსის პროვაიდერები.

2. Ingest კარიბჭეები: მიმღები 'metrics/traces/logs/events' backpressure და კვოტებით.

3. Shina/Striming: ბროკერი ჯგუფური (tenant/region/route), replay replay.

4. Stream-processing: ფანჯრის აგრეგაციები (T + 5s/T + 1m), დედაპლატი, დროის ნორმალიზაცია, SLI გაანგარიშება.

5. საცავი: დროის სერია (ოპერატიული), OLAP (ისტორია), WORM ჟურნალები (აუდიტი).

6. ანალიტიკა და ალერტინგი: SLO წესები, სტატისტიკური დეტექტორები, ანომალიური.

7. დაშბორდები და რუნები: UI მოქმედებისთვის (pause/re-route/rollback/raise-limit).

• მონაცემთა კონტრაქტები მეტრიკზე/მოვლენებზე (სქემები, ვერსიები, შესაბამისობა).
• Outbox/CDC გარანტირებული დომენის მოვლენების გამოქვეყნებისთვის.
• Idempotency და dedup 'trace _ id/event _ id'.
• Clock sync: NTP/PTP, კორექტირება 'skew', ჩანჩქერები (ღონისძიების დრო).

3) ტელემეტრიული და სემანტიკის ტიპები

Metrics (SLI): მრიცხველები/გეი/ჰისტოგრამები p-percentiles.
Traces: 'trace _ id/spank _ id', RPC თაიგული - ვებჰუკის მოვლენები.
ლოგები: სტრუქტურირებული, 'tenant _ id/region/ვერსია'.
Business events: `PaymentAuthorized`, `WebhookDelivered`, `RTPWindowClosed`.
ჩანაწერები: ქვითრები/ხელმოწერები (ფინანსური/კრიტიკული ოპერაციებისთვის).

4) დრო და ფანჯრები

დროის ტიპები: ღონისძიების დრო, ინვესტიციის დრო, პროფესიის დრო.
ფანჯრები: მოცურების (5-30 გ), ნისლის (1-5 წთ), დაგვიანებული მოვლენებისთვის წყლის შეფერხებით (watermark).
კომპაქტურობა: დანერგეთ ნაკადში (ჰისტოგრამების ესკიზები), შეინახეთ მხოლოდ საჭირო პერცენტილის ბარები.

5) მონაცემების ნორმალიზაცია და ხარისხი

სავალდებულო შესასვლელი: სქემა/დიაპაზონი/სავალდებულო ველები; უარყოფილი - საკარანტინო მიზეზის ნიშნით.
დედუპლიკაცია: '(event _ id, producer, seq)'; შეინახეთ „seen-cache“ + KV მეხსიერებაში.
მეტრიკის კორექტირება: „ორმაგი ქვეყნის“ და „flatline“ წინააღმდეგ (სენსორები დუმს).
სიმულაცია: მაღალი QPS- სთვის - ადაპტირებული, შეცდომით; კრიტიკული SLI სავსეა.

6) SLI/SLO (რეფერენდუმი)

ჩრდილოეთ ვარსკვლავი: E2E Success Rate სამიზნე p95 რეგიონში.

• Per Channel/რეგიონის ხელმისაწვდომობა.
• ლატენტობა p50/p95/p99 საკვანძო მარშრუტებზე.
• Error-rate/Retry-rate.
• ვებჰუკების მიწოდების წარმატება (ქვითრების მიერ დადასტურებული%).
• ფასების/გადასახადების თანმიმდევრულობა ('ète = = checkout', ± 1 minor unit).
• Cost-SLI: 1K მოვლენების ღირებულება, ერთეული egress/ingress.

• ხელმისაწვდომობა 99. 95% 28-დღიან ფანჯარაში.
• p95: ვიტრინა 120 ms, é te/checkout 250 ms.
• ვებჰუკი წარმატებულია 99 ევრო. 5 %/5 წუთი ფანჯარა.
• Δ quote↔checkout = 0 (±1 minor unit).
• რეაქცია P1-10 წუთზე, MTTR-60 წუთზე.

7) ალერტინგი და რუნები (auto-actions)

დონე: P1 (SLO დაშლა/უიმედობა), P2 (დეგრადაცია), P3 (ტენდენცია/რისკები).
ხმაურის შემცირება: 'trace _ id' დედაპლატი, მიზეზობრივი ჯაჭვების კორელაცია.

• "PriceMismatch" - refresh დირექტორია, "fx _ version" შერიგება/tax _ rule _ version ", კომპენსაციის პოლიტიკა;
• „WebhookLag“ - ვორკერების ხელახალი მოწყობა, batch- ის ზრდა, რიგების პრიორიტეტი;
• „RTP Drift“ - პრომო პაუზა, გადახდის ცხრილის/ვერსიის შემოწმება, პროფილის დაბრუნება;
• „Egress Surge“ - ს შეუძლია ჩართოთ კომპრესია/ქეში პინინგი/ალტერნატიული მარშრუტი.
• ესკალაცია: მატრიცა 24 × 7, როტაცია, არხები (ჩატი/ზარი/SMS).

8) დაშბორდი (ოპერატიული ვიჯეტები)

პლატფორმის ჯანმრთელობა: წვდომა, p95/p99, error-rate, burn-down error ბიუჯეტი.
ინტეგრაცია/ვებჰუკი: წარმატება, ლაქი, დუბლირება/იდემპოტენტობა, ქვითრები.
Checkout/ფასები: ვიტრინის განსხვავებები - checkout, FX/Tax ვერსიები, უარის თქმის შემთხვევები.
RTP/ლიმიტები: თეორი. vs observed RTP, ლიმიტები, ექსპოზიცია.
FinOps: cost per 1k, egress/ingress, ბიუჯეტები/კაპი-ალერტები.
Security/Compliance: SoD, JIT, MFA, მოთხოვნები PII, ხელმოწერები კრეტა. ოპერაციები.
Release/Flags: ფიგურები, კანარის რეგიონები, ინციდენტებთან დაკავშირებული.

9) მულტირეგიონი და მულტი-ტენანტი

განაწილება 'tenant/region'.
დამოუკიდებელი SLO/კვოტები რეგიონებში; ჯვარედინი რეგიონალური ალერტების შეზღუდვები (ისე, რომ ადგილობრივი მარცხი არ „ხატავს“ მთელ სამყაროს).
მონაცემთა ნდობის ზონები: PII/ფინანსები - მხოლოდ იქ, სადაც ნებადართულია; ზოგადად, დაშბორდი არის აგრეგატები/ჰეში.

10) უსაფრთხოება, კონფიდენციალურობა, დადასტურება

ingest ავთენტიფიკაცია: გასაღებები/mutual-TLS, rate-limits, პაკეტების ხელმოწერები.
PII მინიმალიზაცია: ნიშნები პირველადი, ნიღბების/ჰეშტის იდენტიფიკატორების ნაცვლად.
ქვითრები: DSSE/ხელმოწერები ფინანსური/კრიტიკული მოვლენებისთვის.
WORM ჟურნალები: უცვლელი აუდიტის ლოგოები, მერკლის ნაჭრები.
წვდომის კონტროლი: RBAC/ABAC/ReBAC, JIT მგრძნობიარე პანელებისთვის.

11) ანომალიური და კორელაცია

Guardrails: სტატიკური ბარიერები SLI- ზე.
სტატისტიკა: Shewhart/CUSUM/EWMA ტენდენციებისთვის.
ML/სიგნალები: სეზონური/არხები/ASN/პროვაიდერები; გამოშვებების/ძიების გავლენა.
კორელაციები: დააკავშირეთ ინციდენტები რელიზებთან, კონფიგურაციის ცვლილებებთან, ტრაფიკის ზრდასთან, აქციებთან.

12) პროდუქტიულობა და ღირებულება

ტელემეტრიული ბიუჯეტი: cap QPS/მოცულობაზე; „ლაპარაკის“ მეტრიკის შერჩევა.
შეკუმშვა/აგრეგაცია: ისტორიის downsampling (1c-10s-1min), შეინახეთ პერცენტილის ესკიზები.
Egress კონტროლი: ადგილობრივი ქეში/დანაყოფები, edge წინსვლა.
Cost aware alerty: სიგნალი, თუ ღირებულება/1k მოვლენები ან egress გამოდის გეგმის მიხედვით.

13) ინტეგრაცია და API კონტრაქტები

'POST/ingest/metrics' (JSON/OTLP): ავთენტიფიკაცია, კვოტები, სქემა/ვერსია.
'POST/ingest/events' (ხელმოწერილი): ბაბუა/TTL/nonce.
`GET /kpis? filters = region, tenant, route '- აგრეგატები UI- სთვის.
'GET/traces/{ trace _ id' - ჯაჭვის პოპულარიზაცია.
Вебхуки: `IncidentRaised`, `QuotaCapReached`, `PriceMismatch`, `WebhookLag`, `RTPDrift`.

14) ინციდენტების ფლეიბუკი (მოკლე ფორმა)

P1 წვდომა: შეცვალეთ როუტინგი, ჩართეთ circuit-breakers, შეამციროთ მომხმარებელთა ტაიმაუტები, გადაუდებელი სტატუსის პოსტი.
P1 te Checkout: freeze პრომო/ფასების დინამიკა, ქეშის ინვალიდობა, FX/Tax ვერსიების შედარება, კომპენსაცია.
P1 WebhookLag: გაზარდოს ვორკერები/კონკურენტუნარიანობა, batch ზომა, გამორთეთ უმნიშვნელო ვებჰუკები.
P2 RTP Drift: ბონუსების პაუზა, გადახდის/ვერსიების ცხრილების გადამოწმება, სათვალთვალო ფანჯრის გაფართოება, ანგარიში.
P2 Egress Surge: კომპრესია, edge ქეში, ტრაფიკის ნაწილის გადაადგილება, დროებითი კვოტები.

15) თავად მონიტორინგის ხარისხის მეტრიკა

UI/API წვდომა 99. 9%.
Freshness: განახლებების lag 30 ოპერატიული პანელებისთვის.
Completeness: ≥ 99. წყაროების 5% -მა მონაცემები ფანჯარაში გაგზავნა.
Correctness: შეუსაბამობა სტანდარტთან 0. 1%.

MTTA/MTTR Alert pypline: P1 1/10 წთ

16) განხორციელების შემოწმების სია

• ჩრდილოეთ ვარსკვლავის განსაზღვრა და SLI/SLO ნაკრები რეგიონების/არხების მიხედვით.
• შეიყვანეთ მონაცემთა კონტრაქტები და სქემები ტელემეტრიული ყველა ნაკადისთვის.
• ingest კონფიგურაცია კვოტებით, backpressure და ბაბუით.
• განათავსეთ საბურავი/ნაკადი და ფანჯრის ნაწილები watermarks- ით.
• ააშენეთ დროის სერია/OLAP/WORM და ერთად ქვითრები.
• დაიწყეთ ალერტები + ავტო-რუნები, ესკალაციის მატრიცა 24 × 7.
• ჩამოაყალიბეთ დაშბორდები როლებით: SRE/Product/FinOps/Compliance/პარტნიორები.
• ჩართეთ PII მინიმალიზაცია, ხელმოწერები და RBAC/ABAC/ReBAC.
• შეიყვანეთ FinOps მეტრიკა (cost/1k, egress, შენახვა) და ქუდი.
• გამართეთ GameDay: Webhuk lag, ფასების რასსინქრონი, retray-burst, რეგიონის უკმარისობა.

17) iGaming/fintech

RTP & Limits: დაკვირვებული RTP და ლიმიტების კონტროლი წუთებში/საათებში, ალერტები over/under გადახდაზე.
გადახდა/გადახდა: ავტოკატასტროფების დასრულება, დასუფთავება და ქვითრები; SLA PSP.
Affiliates: კონვერტაციის მიწოდება (ვებჰუკი) და დავები - escrow/cross.
პრომო: ტრაფიკის ზრდა, რიგების დაცვა და egress ფასი; ბიუჯეტებისთვის guardrails.

18) FAQ

რეალური დრო სავალდებულოა ყველგან?
არა. ცხელი კონტურები - წამები/წუთი (ინციდენტები, გადახდები, ვებჰუკი). ეკონომიკა/ანალიტიკა - წუთი/საათი.

როგორ გავუმკლავდეთ ცრუ საზრუნავს?
SLO ორიენტირებული პირობები, შემაერთებელი და დედაპლატი 'trace _ id', კორელაცია გამოშვებებთან, რეიდის ჰისტეზია.

უნდა შევინარჩუნოთ ყველა ლოგიკა სამუდამოდ?
არა. WORM - მხოლოდ აუდიტის/კრიტიკული ნაკადებისთვის; დანარჩენი არის downsampling/TTL.

რატომ არის „qute-checkout“?
FX/Tax ვერსიები, ქეშის ინვალიდობა, დამრგვალება. მკურნალობენ ვერსიებით, SWR სტრატეგიით და კონსისტენციის ტესტებით.

რეზიუმე: რეალურ დროში მონიტორინგი არის დისციპლინა: მკაცრი მონაცემთა კონტრაქტები, ფანჯრის გამოთვლები, ნორმალიზებული დრო, ქვითრები და SLO ალერტები, პლუს მოქმედების ღილაკი თითოეულ ვიჯეტში. ამის გაკეთების შემდეგ, თქვენ ამცირებთ MTTR- ს, ინარჩუნებთ ბიუჯეტს კონტროლის ქვეშ და თავდაჯერებულად აყენებთ ეკოსისტემას რეგიონებსა და ტენანტებში.