تجزیه و تحلیل API و معیارهای عملکرد

1) چرا شما به آن نیاز دارید

• اثبات اجرای SLO و SLA،
• مدیریت پهنای باند و اقتصاد پرس و جو،
• به سرعت تخریب محلی (p99-tails، 5xx bursts)،
• اولویت بندی بهینه سازی تاثیر کسب و کار.

هدف: یک مدل قابل مشاهده که در آن هر درخواست از محیط به DB با شناسه های مشترک و SLI های سازگار ردیابی می شود.

2) طبقه بندی معیارها

فنی: RPS، تاخیر (p50/p95/p99)، نرخ خطا (4xx/5xx)، اشباع (CPU، حافظه، فایل desc)، زمان صف.
محصول: عملیات موفق/دقیقه، تبدیل مرحله (200/کل)، سهم نرخ محدود (429)، بازپرداخت، بخش های کاربر.
هزینه: هزینه/درخواست (CPU-ms + خروج + درخواست پایگاه داده)، هزینه ویژگی/نقطه پایانی، $/مستاجر، $/1k تماس.

3) «سیگنال های طلایی»: قرمز و استفاده

• نرخ - درخواست/ثانیه (توسط نقطه پایانی/مستاجر/طرح).
• خطاهای 4xx/5xx/429 کسرها و مطلق.
• مدت زمان - p50/p95/p99 پایان به پایان و مراحل (ورود → برنامه → DB → شخص ثالث).

• استفاده - بار CPU/IO/کانال.
• اشباع - صف (صف اجرا، backlog، انتظار DB).
• خطاها - خطاهای راننده/وقفه.

4) تعاریف و فرمول های اساسی

در دسترس بودن SLI: '1 − (5xx + gateway_timeout )/ all_requests'.
SLI موفقیت: '2xx/( همه − 429_shadow)' (به استثنای قفل سایه).
Apdex: (|T≤T| + 0. 5·|T≤4T| )/all '، جایی که «T» آستانه «خوب» هدف است.
تقویت دم: 'p99 _ total − max (p99_stage_i)' - سهم صف/ترکیب.
بودجه خطا (ماه) در 99. 9٪: "بودجه = 0. 1% period _ time ".

سطل های درصد توصیه شده هیستوگرام های تاخیر: [5ms، 10ms، 25ms، 50ms، 100ms، 250ms، 500ms، 1s، 2. 5 ها، 5 ها].

5) SLI/SLO و هشدار توسط نرخ سوختگی

• دسترسی: ≥ 99 9 %/30 روز
• تاخیر p95 'GET/کیف پول/تعادل' <150 ms ؛ 'پست/پرداخت' <400 ms.
• خطاهای «5xx» <0. 2%. 429 (جامد) <1٪ از کل ترافیک.

• 2٪ از بودجه برای 1 ساعت یا 5٪ برای 6 ساعت → صفحه به مهندس.
• 10٪ در روز → اولویت بندی RCA.

6) مجموعه ای از معیارها (چه چیزی برای جمع آوری اجباری است)

• 'http _ requests _ total {مسیر، روش، وضعیت، مستاجر، طرح}'
• 'http _ request _ duration _ seconds _ bucket {مسیر،...}' (هیستوگرام)
• 'reries _ 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}', cache hit-rate external calls: 'outbound _ calls _ total {provider, op}', latency/errors/queue timeouts/pools: طولها/تأخیرها, منابع فعال استفاده از کارگران: CPU, RSS, FD, GC مکث میکند

برچسبهای تجاری: «tenant _ id»، «region»، «kyc _ level»، «plan»، «feature _ flag».

7) ردیابی و همبستگی (OpenTelemetry)

W3C Trace-Context ('traceparent'، 'tracestate') در تمام هاپ ها.
فاصله ها توسط مراحل: ورود → authZ → کنترل کننده برنامه → DB/Redis → PSP/خارجی.
ویژگیها/برچسبها: "http. مسیر '،' کاربر نهایی. من مستاجر هستم. من، ناتوانی. کلید «،» خطر. امتیاز بدهید.
نمونه ها: نقاط مربوط به نمودارهای تأخیر/خطا را با شناسه ردیابی خاص مرتبط کنید.

• 1-10٪ برای مسیرهای «عادی»،
• tail-based for tails (آهسته/اشتباه),
• سازگار برای قله ها و حوادث.
• چمدان: حمل «مستاجر »/« خطر» برای کاهش بدون علامت هر رویداد.

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 share, burn-rate budget.

2. در هر مسیر: Endoints بالا توسط RPS/خطا/دم ؛ مقایسه نسخه ها (canary)

3. Per-Tenant/Plan: رهبران بار/هزینه/خطا.
4. سلامت وابستگی: DB، کش، PSP/خارجی - تاخیر، خطاها، اشباع.
5. ظرفیت: CPU/RAM/FD، صف، استخر اتصال، GC، محدودیت ظرف.
6. امنیت/سوء استفاده: 401/403، 429/سیاستمداران، تکه های جغرافیایی/ASN، سنبله های مجدد.

10) هشدارها (آستانه و روند)

'error _ rate {route}> 2% (5 دقیقه) و RPS> N → پیجر.
'p99 _ latency {critical}'> آستانه هدف (10 دقیقه).
'burn _ rate' by budget (نگاه کنید به § 5).
DB 'timeouts '/' بن بست' یا رشد 'queue _ time'> X ms.
ارائه دهندگان خارجی: 'outbound _ 5xx _ rate {provider}> 1٪ + وابسته به SLO.

11) برنامه ریزی و عملکرد خازنی

قانون Little's: «L = λ· W» (میانگین طول صف = ترافیک × زمان متوسط).
هدف p95 تجزیه شده است: 'ورود + برنامه + DB + خارجی + صف'.
بودجه همروندی: حداکثر تعداد عملیات نوشتن همزمان را ثابت کنید.
بودجه متریک: «CPU ms در هر درخواست» ؛ ما 30 تا 50 درصد تا قله فاصله داريم.
تعامل با محدودیت نرخ: نسبت درخواست ها را در «سقف» سهمیه و تأثیر آن بر تأخیر اندازه گیری کنید.

12) چک های بار و مصنوعی

انواع: بار پایه, پشت سر هم × 10, «مراحل», فلات بلند مدت, استرس/هرج و مرج (کشتن گره, تاخیر شبکه), مصنوعی با توجه به حالات مشتری بحرانی.
پروفایل: CPU/-/lock-contention، N + 1 (SQL/HTTP)، کدهای آهسته.
کنترل رگرسیون: مقایسه خطاهای p95/p99/قبل/بعد از انتشار (canary).

13) هزینه قابل مشاهده

معیارهای هزینه: «cpu _ ms»، «egress _ bytes»، «db _ calls»، «$ در هر درخواست 1k».
تخصیص به نقطه پایانی/مستاجر/ویژگی: برچسب های صدور صورت حساب از ارکستر + معیارهای بار → گزارش اقتصاد واحد API.
الگوریتم بهینه سازی: TOP-endpoints را با محصول «traffic × cost × (p95 − target)» انتخاب کنید.

14) تجزیه و تحلیل هر مستاجر و «عدالت»

تمام معیارهای کلیدی «tenant _ id/plan» برچسب گذاری می شوند.
سهم مشتریان «سنگین» در دم p99 ؛ محدودیت ها/سهمیه های فردی و بودجه های بازپرداخت.
برش عادلانه: هنگامی که بیش از حد بارگذاری می شود، سهم مستاجران «برجسته» را کاهش می دهیم.

15) ویژگی های iGaming/امور مالی

بخشهای «kyc _ level»، «risk _ tier»، «payment _ method».
SLI برای مسیرهای «پول» («POST/deposits»، «POST/withdrawals»): هدف پایین p95، بودجه خطای جداگانه.
معیارهای زمان به کیف پول (TTW)، سهم قفل خودکار ضد تقلب، تبدیل پرداخت.
حسابرسی: سیاهههای مربوط تغییر ناپذیر برای اقدامات مالی و تصمیمات ضد تقلب.

16) ابزار دقیق: شیوه های پیاده سازی

• 'api _ http _ requests _ total' (شمارنده)
• 'api _ http _ request _ duration _ seconds' (هیستوگرام)
• '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)، استفاده از «سطل «/هش.
نمونه: اتصال به هیستوگرام p95/p99 → کلیک بر روی ردیابی.

17) ضد گلوله

متوسط به جای درصد ؛ بدون تقسیم به کلاس های وضعیت.
«مسیر »/« مسیر» ناسازگار (شناسه های پویا به برچسب ها «دوخته» می شوند).
برچسب ها با کاردینالیتی بالا (user_id خام، IP).
بدون حسابداری جداگانه از ارائه دهندگان خارجی (PSP/3rd-party).
هشدارها توسط «سر و صدا» (پنجره تک و یک آستانه).
p99 به استثنای زمان صف (ماسک تخریب واقعی).

18) تولید لیست آمادگی

• SLI/SLO و خطا بودجه تعریف شده، موافق با کسب و کار.
• هیستوگرام های تک تاخیر و کلاس های وضعیت ؛ p95/p99 در داشبورد.
• ردیابی کامل (OTel)، همبستگی ورود/متریک/ردیابی.
• هشدار نرخ سوختگی (دو پنجره)، آستانه p99 و نرخ خطا.
• در هر مستاجر/در هر برنامه بخش و گزارش هزینه.
• داشبورد: Exec، Per-Route، وابستگی ها، ظرفیت، سوء استفاده.
• سناریوهای بار (پشت سر هم/فلات/استرس)، پروفایل.
• سیاست های Jitter Retray ؛ محاسبه اثر retrays در RPS.
• مستندات SLA/SLO برای شرکا و مشتریان عمومی.
• حفظ/ورود به سیستم ماسک، حفاظت PII.

19) TL ؛ دکتر متخصص

ایجاد قابلیت مشاهده در اطراف SLI/SLO و بودجه خطا، اندازه گیری RED/USE، جمع آوری هیستوگرام های تاخیر با p95/p99 و زمان صف، توزیع یک ردیابی شناسه از محیط به DB، استفاده از نمونه برداری دم/تطبیقی، نگه داشتن در هر مستاجر/کاهش هزینه و دو پنجره burn-rate-alert. ظرفیت برنامه ریزی با توجه به قوانین صف و تاثیر بر معیارهای کسب و کار ؛ antipatterns - متوسط به جای صدک، کاردینالیتی بالا و وابستگی های خارجی حساب نشده.