API талдау және өнімділік метрикасы

1) Бұл не үшін қажет

• SLO және SLA,
• өткізу қабілетін және сұраныс экономикасын басқару,
• тозуды тез оқшаулау (p99-қалдықтар, 5xx жарылыстар),
• бизнеске әсері бойынша оңтайландыруға басымдық беру.

Мақсаты: бақылаудың бірыңғай моделі, онда әрбір сұрау салу жалпы сәйкестендіргіштермен және SLI-мен келісілген периметрден ДБ-ға дейін қадағаланады.

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

Техникалық: RPS, жасырындылық (p50/p95/p99), error rate (4xx/5xx), saturation (CPU, memory, file-desc), queue time.
Өнімдік: сәтті операциялар/мин, қадамды конверсиялау (200/total), rate-limited үлесі (429), ретраиялар, пайдаланушы сегменттер.
Құны: cost/request (CPU-ms + egress + БД-сұраулар), фича/эндпоинт құны, $/тенант, $/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% жалпы трафик.

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

• «кәдімгі» жолдар үшін 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 үлес, 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/саясат, гео/ASN кесінділері, ретра жарылыстары.

10) Алерталар (шекті және трендтік)

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

11) Сыйымдылық жоспарлау және өнімділік

Литтл заңы: 'L = λ· W' (кезектің орташа ұзындығы = трафик × орташа уақыт).
p95 мақсатты орналастырыңыз: 'ingress + app + DB + external + queue'.
Concurrency budget: write-операциялардың максимумын тіркейміз.
Budget-метрика: «сұранысқа CPU мс»; шыңға қарай 30-50% қор сақтаймыз.
rate-limit өзара әрекеттесу: квотаның «төбесіндегі» сұраныстардың үлесін және жасырындылыққа әсерін өлшеңіз.

12) Жүктемелік және синтетикалық тексерулер

Түрлері: базалық жүктеме, × 10, «сатылар», ұзақ мерзімді плато, стресс/chaos (түйінді өлтіру, желіні кідірту), клиенттік сценарийлер бойынша синтетика.
Бейіндеу: CPU/alloc/lock-contention, N + 1 (SQL/HTTP), баяу кодтар.
Регрестерді бақылау: р95/р99/релизге дейінгі/кейінгі қателерді салыстыру (канареялық).

13) Құны (Cost-Observability)

Шығын өлшемдері: 'cpu _ ms', 'egress _ bytes', 'db _ calls', '$ per 1k requests'.
Эндпоинт/тенант/фичке аллокация: оркестратордан биллинг тегтері + жүктеме метрикасы → 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 (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 «тігілген»).
Жоғары кардинальды лейблдер (raw user_id, IP).
Сыртқы провайдерлерді бөлек есепке алудың болмауы (PSP/3rd-party).
«Шу» бойынша алерта (бір терезе және бір табалдырық).
p99 (нақты деградацияны бүркемелейді).

18) Prod-әзірлікті бақылау тізімі

• SLI/SLO және error-budget анықталған, бизнеспен келісілген.
• latency бірыңғай гистограммалары және статус-кластар; p95/p99 дашбордтарда.
• Толық трасса (OTel), логтардың/метриктердің/трейстердің корреляциясы.
• Burn-rate (екі терезелі) алерттары, p99 және error-rate бойынша табалдырықтар.
• Пер-тенант/пер-жоспар қималар және құн бойынша есептер.
• Дашбордтар: Exec, Per-Route, Dependencies, Capacity, Abuse.
• Жүктеме сценарийлері (бурст/плато/стресс), бейіндеу.
• Ретрайлардың джиттермен саясаты; ретрациялардың RPS әсерін есепке алу.
• Серіктестер мен ашық клиенттер үшін SLA/SLO құжаттамасы.
• Журналды ретеншн/бүркемелеу, PII қорғау.

19) TL; DR

SLI/SLO және error-budget айналасында бақылау жасаңыз, RED/USE өлшеңіз, p95/p99 және «queue time» latency гистограммаларын жинаңыз, периметрден БД-ға дейін бірыңғай trace-id таратыңыз, tail/adaptive-sampling пайдаланыңыз, пер-тенантты ұстаңыз/құндық тіліктер және екі терезелі burn-rate-алертинг. Сыйымдылықты кезек заңдары және бизнес-метрикаға әсері бойынша жоспарлаңыз; антипаттерндер - перцентильдер орнына орташа, жоғары кардиналдылық және есепке алынбаған сыртқы тәуелділіктер.