API ანალიტიკა და შესრულების მეტრიკა

1) რატომ არის ეს აუცილებელი?

• დაამტკიცეთ SLO და SLA შესრულება,
• აკონტროლებს მოთხოვნის გამტარუნარიანობასა და ეკონომიკას,
• სწრაფად ლოკალიზაცია დეგრადაციისთვის (p99 კუდი, 5xx აურზაური),
• ოპტიმიზაციის პრიორიტეტი ბიზნესზე გავლენის მოხდენისთვის.

მიზანი: ერთიანი სადამკვირვებლო მოდელი, სადაც თითოეული მოთხოვნა აკონტროლებს პერიმეტრიდან BD- ს ზოგადი იდენტიფიკატორებით და შეთანხმებულია SLI- სთან.

2) მეტრიკის ტაქსონომია

ტექნიკური: RPS, ლატენტობა (p50/p95/p99), error rate (4xx/5xx), saturation (CPU, memory, file-desc), queue დრო.
სასურსათო ოპერაციები: წარმატებული ოპერაციები/წთ, ნაბიჯის კონვერტაცია (200/ტოტალური), საბინაო-ლიმიტირებული (429) წილი, retrai, მომხმარებლის სეგმენტები.
ღირებულება: cost/request (CPU-ms + egress + BD მოთხოვნები), ფიჩხის/endpoint- ის ღირებულება, $/ტენანტი ,/$ 1k ზარები.

3) ოქროს სიგნალები: RED და USE

• Rate - მოთხოვნები/წმ (ენდოინტე/ტენანტი/გეგმის მიხედვით).
• Errors - 4xx/5xx/429 წილი და აბსოლუტური.
• Duration - p50/p95/p99 end-to-end და ეტაპზე (ingress-app-DB - მესამე მხარის).

• Utilization - CPU/IO/არხის დატვირთვა.
• Saturation - რიგები (run-queue, backlog, DB wait).
• Errors - დრაივერების/ტაიმაუტის შეცდომები.

4) ძირითადი განმარტებები და ფორმულები

Availability SLI: `1 − (5xx + gateway_timeout) / all_requests`.
Success SLI: '2xx/( all − 429 _ shadow)' („ჩრდილის“ ბლოკირების გამოკლებით).
Apdex: `(|T≤T| + 0. 5 | T-4T | )/all ', სადაც' T 'არის სამიზნე „კარგი“ ბარიერი.
Tail amplification: 'p99 _ total - max (p99 _ stage _ i) "- რიგების/კომპოზიციის წვლილი.
Error budget (თვე) 99. 9%: 'ბიუჯეტი = 0. 1% პერიოდის დრო '.

რეკომენდებული percentille bans ჰისტოგრამები: '[5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2. 5s, 5s]`.

5) SLI/SLO და burn-rate ალერტინგი

• წვდომა: 99 ევრო. 9 %/30 დღე.
• platence 'GET/wallet/balance' <150 ms; 'POST/payments' <400 ms.
• შეცდომები '5xx' <0. 2%. '429' (მყარი) მთლიანი ტრაფიკის <1%.

• ბიუჯეტის 2% 1 საათში ან 5% 6 საათში არის ინჟინერი.
• დღეში 10% RCA პრიორიტეტია.

6) მეტრიკის ნაკრები (რაც უნდა შეგროვდეს)

• `http_requests_total{route,method,status,tenant,plan}`
• 'http _ request _ duration _ seconds _ bucket {route,...' (ჰისტოგრამა)
• `retries_total{reason}`, `rate_limited_total{key,policy}`
• სხეულის ზომები: 'request _ bytes', 'response _ bytes'

• `db_client_requests_total{op,table}`, `db_latency_seconds_bucket{op}`
• 'cache _ ops _ ops _ total {op}', გარე ზარები hit-rate ქეში: 'Outbound _ calls _ total {provider, op}', latency/შეცდომები/ხაზები/puls: სიგრძე/შეფერხებები, აქტიური რესურსების აშშ: CPCPU U U U US S S S S S S S S S S S S S S S S S S S S S S S S AS S S S IS S S S s D, GC პაუზები

ბიზნეს ეტიკეტები: 'tenant _ id', 'region', 'kyc _ level', 'plan', 'feature _ flag'.

7) ტრეკინგი და კორელაცია (OpenTelemetry)

W3C Trace-Context ('traceparent', 'tracestate') ყველა ჰოპზე.
Span- ები ეტაპზე: ingress-authZ - app handler - DB/Redis - PSP/გარე.
Attributes/ეტიკეტები: 'http. route`, `enduser. id`, `tenant. id`, `idempotency. key`, `risk. score`.
Exemplars: დააკავშირეთ წერტილები latency/error- ის გრაფიკებზე სპეციფიკურ ტრასასთან.

• head-based 1-10% „ჩვეულებრივი“ ტრასებისთვის,
• tail-based კუდებისთვის (მიიღეთ ნელი/მცდარი),
• adaptive მწვერვალებისა და ინციდენტებისთვის.
• Baggage: გადატანა 'tenant '/' risk' ჭრილობებისთვის, თითოეული მოვლენის მარკირების გარეშე.

8) ლოგიკა: სტრუქტურა და კონფიდენციალურობა

სტრუქტურირებული JSON; სავალდებულო ველები: 'ts', 'trace _ id', 'span _ id', 'route', 'status', 'latency _ ms', 'tenant', 'user _ id _ hash'.
პოლიტიკა PII: შენიღბეთ PAN/PII; აკრძალეთ საიდუმლოებები/ნიშნები.
ლოგოების სემპლინგი: მაღალი 4xx/5xx/429 და „გრძელი“ მოთხოვნები.

9) დაშბორდის რუკა (მინიმალური ნაკრები)

1. Exec-Summary: RPS, Availability, Error-rate, p95/p99 latency, 429 წილი, ბიუჯეტის საბურღი.
2. Per Route: ტოპ ენდოინები RPS/შეცდომები/კუდები; ვერსიების შედარება (კანარი).
3. Per-Tenant/Plan: ლიდერები დატვირთვით/ღირებულებით/შეცდომებით.
4. ჯანმრთელობის დეფიციტი: DB, cache, PSP/გარე - ლატენტობა, შეცდომები, სატურნა.
5. Capacity: CPU/RAM/FD, რიგები, კონსოლის კავშირი, GC, კონტეინერების ლიმიტები.
6. Security/Abuse: 401/403, 429/პოლიტიკა, Geo/ASN strazes, ratrais.

10) ალერტა (ბარიერი და ტენდენცია)

'error _ rate {route}'> 2% (5 წუთი) და RPS> N პაგერი.
'p99 _ latence {critical}'> სამიზნე ბარიერი (10 წუთი).
'burn _ rate' ბიუჯეტში (იხ. § 5).
DB 'timeouts '/' deadlocks "ან ზრდა' queue _ time '> X ms.
გარე პროვაიდერები: 'outbound _ 5xx _ rate {provider}'> 1% + SLO დამოკიდებულია.

11) ტევადობის დაგეგმვა და შესრულება

Little კანონი: 'L = cow· W' (რიგის საშუალო სიგრძე = ტრაფიკი × საშუალო დრო).
სამიზნე p95 განლაგებულია: 'ingress + app + DB + external + queue'.
Concurrency budget: ჩაწერეთ მაქსიმალური ერთდროული write ოპერაციები.
ბუდეტის მეტრი: „ms CPU მოთხოვნისთვის“; შეინარჩუნეთ რეზერვი მწვერვალზე 30-50%.
ურთიერთქმედება საბაზო-ლიმიტთან: გაზომეთ კვოტის „ჭერის“ მოთხოვნის წილი და გავლენა ლატენტობაზე.

12) დატვირთული და სინთეზური შემოწმებები

სახეობები: ძირითადი დატვირთვა, bursts × 10, „ნაბიჯები“, გრძელვადიანი პლატო, სტრესი/ქაოსი (ხუმრობის მკვლელობა, ქსელის შეფერხება), კრიტიკული კლიენტის სცენარების მიხედვით სინთეზური.
პროფილირება: CPU/alloc/lock-contention, N + 1 (SQL/HTTP), ნელი კოდები.
რეგრესიის კონტროლი: p95/p99/შეცდომების შედარება გამოშვების შემდეგ (კანარის).

13) ღირებულება (Cost-Observability)

ხარჯების მეტრიკა: 'cpu _ ms', 'egress _ bytes', 'db _ calls', '$ per 1k requests'.
Endpoint/tenant/fich- ის ალოკაცია: ბილინგის ჭდეები ორკესტრიდან + დატვირთვის მეტრიდან - ანგარიში API ერთეულის ეკონომიკის შესახებ.
ოპტიმიზაციის ალგორითმი: შეარჩიეთ TOP endpoints 'traffic × cost × (p95 - მიზანი)'.

14) ანალიტიკოსის პერ-ტენანტი და „სამართლიანობა“

ყველა ძირითადი მეტრიკა არის ეტიკეტი 'tenant _ id/plan'.
„მძიმე“ მომხმარებლების წილი p99 კუდებში; ცალკეული ლიმიტები/კვოტები და რეტრის ბიუჯეტები.
სამართლიანი შეერინგი: გადატვირთვისას, ჩვენ ვამცირებთ „გახმაურებული“ მოიჯარეების წილს.

15) iGaming/ფინანსების სპეციფიკა

ჭრილობები 'kyc _ level', 'risk _ tier', 'payment _ method'.
SLI „ფულადი“ ბილიკებისთვის ('POST/deposits', 'POST/withdrawals'): უფრო დაბალია, ვიდრე მიზნობრივი p95, შეცდომების ცალკეული ბიუჯეტები.
Time-to-Wallet (TTW) მეტრიკა, ანტიფროდული ავტობუსების წილი, გადახდის კონვერტაცია.
აუდიტი: უცვლელი ჟურნალები ფინანსური მოქმედებებისა და ანტიფროდული გადაწყვეტილებებისთვის.

16) ინსტრუმენტაცია: განხორციელების პრაქტიკა

• `api_http_requests_total` (counter)
• `api_http_request_duration_seconds` (histogram)
• `api_outbound_requests_total`, `api_db_query_duration_seconds`
• `api_rate_limited_total`, `api_retry_total{reason}`

Лейблы: `route`, `method`, `status_class`, `tenant`, `region`, `version`, `canary`, `provider`, `db_table`.
კარდინალობა: თავიდან აიცილეთ უფასო მნიშვნელობები (user _ id), გამოიყენეთ „ბაკეტები “/ჰაში.
Exemplars: დაუკავშირდით p95/p99 ჰისტოგრამებს.

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

პერცენტილის ნაცვლად საშუალო; სტატუსის კლასებად დაყოფის არარსებობა.
არაკოორდინირებული 'route '/' path' (დინამიური ID „shits“ ეტიკეტებში).
მაღალი კარდინალური ეტიკეტები (raw user _ id, IP).
გარე პროვაიდერების ცალკეული აღრიცხვის არარსებობა (PSP/3rd-party).
„ხმაურის“ ალერტები (ერთსულოვანი და ერთი ბარიერი).
p99, queue time- ის გამოკლებით (ნამდვილი დეგრადაციის ნიღაბი).

18) მზადყოფნის საკონტროლო სია

• განსაზღვრულია SLI/SLO და error-budget, რომლებიც შეთანხმებულია ბიზნესთან.
• ერთიანი ჰისტოგრამები და სტატუსის კლასები; p95/p99 დაშბორდებზე.
• სრული ტრეკი (OTel), ლოგოების/მეტრიკის/ტრეისების კორელაცია.
• Alerta burn-rate (ორსართულიანი), p99 და error-rate ბარიერები.
• Pere tenant/prome ჭრის გეგმა და ხარჯების ანგარიშები.
• დაშბორდები: Exec, Per-Route, Dependencies, Capacity, Abuse.
• დატვირთული სკრიპტები (მშვილდი/პლატო/სტრესი), პროფილირება.
• რეტრაის პოლიტიკოსები ჯიტერთან; RPS- ზე რეაგირების გავლენის აღრიცხვა.
• SLA/SLO დოკუმენტაცია პარტნიორებისა და საჯარო მომხმარებლებისთვის.
• ლოგოების გადაკეთება/შენიღბვა, დაცვა PII.

19) TL; DR

ააშენეთ დაკვირვება SLI/SLO და error-budget გარშემო, გაზომეთ RED/USE, შეაგროვეთ ლატენტობის ჰისტოგრამები p95/p99 და „queue time“, გაავრცელეთ ერთი ტრაიდი პერიმეტრიდან BD- მდე, გამოიყენეთ tail/adadadadaptaptivaptivaptive-sling-sling, ტენანტი/ღეროვანი ჭრილობები და ორმაგი ფანჯრის ბურნის ალერტინგი. დაგეგმეთ შესაძლებლობები რიგების კანონების შესაბამისად და ბიზნეს მეტრებზე გავლენის მოხდენაზე; ანტიპატერები - პერცენტილების ნაცვლად საშუალო, მაღალი კარდინალობა და გარე დამოკიდებულებები.