API аналитика жана аткаруу метрика

1) Эмне үчүн керек

• SLO жана SLA аткарылышын далилдөө,
• жөндөмдүүлүгүн жана суроо-талаптардын экономикасын башкаруу,
• тез деградацияны локалдаштыруу (p99-куйруктары, 5xx жарылуулары),
• бизнеске тийгизген таасири боюнча оптималдаштырууга артыкчылык берүү.

Максаты: ар бир суроо жалпы идентификаторлор жана макулдашылган SLI менен DD үчүн периметри байкоо бирдиктүү модели.

2) Метриктердин таксономиясы

Техникалык: RPS, жашыруун (p50/p95/p99), ката (4xx/5xx), saturation (CPU, memory, file-desc), queue time.
Азык-түлүк: ийгиликтүү иш/мин, кадам которуу (200/жалпы), rate-limited үлүшү (429), Retray, колдонуучу сегменттер.
Баасы: cost/request (CPU-ms + egress + BD-суроолор), fich/end-point наркы, $/tenant, $/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% убакыт _ мезгил '.

Сунушталган гистограммалар latency бин: '[5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2. 5s, 5s]`.

5) SLI/SLO жана burn-rate боюнча алертинг

• Жеткиликтүү: ≥ 99. 9 %/30 күн.
• p95 жашыруун 'GET/wallet/balance' <150 мс; 'POST/payments' <400 мс.
• Каталар '5xx' <0. 2%. '429' (катуу) <1% жалпы жол.

• 2% бюджет 1 саат же 5% 6 саат → page инженер.
• 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 _ total {op}', hit-rate кэш тышкы чалуулар: 'outbound _ calls _ total {provider, op}', latency/каталар/таймаут кезек/пулдар: узундуктар/кечигүүлөр, активдүү воркерлер ресурстук USE: CPU, RSS, FD, GC-тыныгуу

Бизнес-лейблдер: 'tenant _ id', 'region', 'kyc _ level', 'plan', 'feature _ flag'.

7) Trace жана корреляция (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: конкреттүү trace-id менен latency/error сүрөттөр боюнча пункттарды байланыштырып.

• head-based 1-10% "кадимки" жолдор үчүн,
• куйруктары үчүн tail-based (жай/ката алып),
• чокулары жана окуялар үчүн adaptive.
• Багаж: ар бир окуяны белгилебестен 'tenant '/' risk' деп которуу.

8) Логи: түзүлүшү жана купуялуулук

Структураланган JSON; Милдеттүү талаалар: 'ts', 'trace _ id', 'span _ id', 'route', 'status', 'latency _ ms', 'tenant', 'user _ id _ hash'.
PII саясаты: PAN/PII жашыруу; сырларды/токендерди тыюу.
Sampling Logs: 4xx/5xx/429 жана "узун" суроолор үчүн жогорку.

9) Дашборд картасы (минималдуу топтому)

1. Exec-Summary: RPS, Availability, Error-rate, p95/p99 latency, 429 үлүшү, burn-rate бюджет.
2. Per-Route: RPS/каталар/куйруктары боюнча жогорку эндоинттер; версияларды салыштыруу (канарейка).
3. Per-Tenant/Plan: жүктөө/наркы/каталар боюнча лидер.
4. Dependency Health: DB, cache, PSP/тышкы - latency, каталар, saturation.
5. Capacity: CPU/RAM/FD, кезек, connection pool, GC, контейнер чектери.
6. Security/Abuse: 401/403, 429/саясат, GEO/ASN тилкелери, retrains.

10) Алерталар (босого жана тренддик)

'error _ rate {route}'> 2% (5 мүнөт) жана RPS> N → pager.
'p99 _ latency {critical}'> максаттуу босого (10 мүнөт).
Бюджет боюнча 'burn _ rate' (§ 5 караңыз).
DB 'timeouts '/' deadlocks' же 'queue _ time'> X ms.
Тышкы провайдерлер: 'outbound _ 5xx _ rate {provider}'> 1% + SLO көз каранды.

11) Сыйымдуулугун пландаштыруу жана аткаруу

Little мыйзамы: 'L = λ· W' (орточо кезек узундугу = жол × орточо убакыт).
Максаттуу p95 жайгаштыруу: 'ingress + app + DB + external + queue'.
Concurrency budget: Биз бир эле учурда write-бүтүмдөрдүн максималдуу жазып.
Budget-метрика: "өтүнүч боюнча MS CPU"; биз чокусуна 30-50% запасын сактап.
Rate-limit менен өз ара аракеттенүү: "шыптагы" квотадагы суроо-талаптардын үлүшүн жана жашыруун таасирди өлчөө.

12) Жүктөө жана синтетикалык текшерүү

Түрлөрү: негизги жүк, бурстары × 10, "кадамдар", узак мөөнөттүү плато, стресс/chaos (nod өлтүрүү, тармак кечигүү), кардарлардын оор жагдайлар боюнча синтетика.
Профилдөө: CPU/alloc/lock-contention, N + 1 (SQL/HTTP), жай коддору.
Regress Control: p95/p99/каталарды релизге чейин/кийин салыштыруу (канарейка).

13) Наркы (Cost-Observability)

Чыгымдардын көрсөткүчтөрү: 'cpu _ ms', 'egress _ bytes', 'db _ calls', '$ per 1k requests'.
EndPoint/Tenant/Fichu боюнча аллокация: Оркестратордун биллинг теги + жүктүн метрикасы → API бирдик экономикасы боюнча отчет.
Оптималдаштыруу алгоритми: 'traffic × cost ×' (p95 − максат) 'чыгаруусу боюнча TOP-пункттарын тандоо.

14) Пер-тенант аналитика жана "адилеттүүлүк"

Бардык негизги көрсөткүчтөр - 'tenant _ id/plan' этикеткасы менен.
p99 куйруктарында "оор" кардарлардын үлүшү; өзүнчө лимиттер/квоталар жана ретрайлардын бюджеттери.
Адилеттүү шейринг: ашыкча жүктөөдө "катуу" ижарачылардын үлүшүн азайтабыз.

15) iGaming/каржы өзгөчөлүктөрү

'kyc _ level', 'risk _ tier', 'payment _ method' боюнча тилкелер.
"Акча" жолдору үчүн SLI ('POST/deposits', 'POST/withdrawals'): төмөнкү максаттуу p95, жеке ката бюджеттери.
Time-to-Wallet Metrics (TTW), antifrodom autoblock үлүшү, төлөм которуу.
Аудит: каржылык иш-аракеттер жана antifrod чечимдер үчүн өзгөрүлбөс журналдар.

16) Instrumentation: ишке ашыруу практикасы

• `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 → click trace гистограммаларына туташтырыңыз.

17) Антипаттерндер

Перцентилдин ордуна орточо; статустук класстарга бөлүүнүн жоктугу.
Координацияланбаган 'route '/' path' (динамикалык ID этикеткага "тигилген").
Жогорку кардиналдуу (raw user_id, IP).
Тышкы провайдерлердин өзүнчө эсебинин жоктугу (PSP/3rd-party).
Алерта "ызы-чуу" (бир терезе жана бир босого).
p99 жок queue time (чыныгы деградацияны жашырат).

18) Prod-даярдык контролдук тизмеси

• SLI/SLO жана error-budget аныкталган, бизнес менен макулдашылган.
• Бирдиктүү гистограммалар latency жана статус класстары; p95/p99 дашборддо.
• Толук Tracking (OTel), Логин/Метрика/Trace корреляция.
• Alerty burn-rate (эки терезе), p99 жана error-rate боюнча босоголор.
• Per-tenant/per-план кесүү жана наркы боюнча отчеттор.
• Дашборддор: Exec, Per-Route, Dependencies, Capacity, Abuse.
• Жүктөө сценарийлери (бурст/плато/стресс), профилдөө.
• Jitter менен retrains саясаты; RPS боюнча ретрациялардын таасирин эсепке алуу.
• SLA/SLO документтери өнөктөштөр жана ачык кардарлар үчүн.
• Retenshn/камуфляж, PII коргоо.

19) TL; DR

SLI/SLO жана error-budget айланасында байкоо түзүү, RED/USE өлчөө, p95/p99 жана "queue time" менен latency гистограммаларын чогултуу, периметрден БДга чейин бирдиктүү trace-id таратуу, tail/adaptive-sampling колдонуңуз, per-tenant кармаңыз/наркы кесилген жана эки терезе burn-rate-alerting. Сыйымдуулукту кезектердин мыйзамдары жана бизнес-метрикага тийгизген таасири боюнча пландаштырыңыз; антипаттерндер - перцентилдердин ордуна орточо, жогорку кардиналдуулук жана эсепке алынбаган тышкы көз карандылыктар.