分析和性能指標API

1）為什麼需要它

• 證明SLO和SLA的表現，
• 管理帶寬和查詢經濟性，
• 快速定位降解（p99尾巴，5xx爆發），
• 按業務影響優先優化。

目標：一個單一的可觀察性模型，其中每個查詢都通過共享標識符和一致的SLI從周長跟蹤到DB。

2）分類學指標

技術：RPS，潛伏期（p50/p95/p99），error rate（4xx/5xx），saturation（CPU，memory，file-desc），queue time。
雜貨店：成功運營/min，步驟轉換（200/total），限價股份（429），retrai，用戶細分。
成本：成本：cost/request （CPU-ms+egress+DB查詢）,fichi/Endpoint成本,$/tenant, $/1k呼叫。

3）「黃金信號」： RED和USE

• Rate-查詢/秒（按殘局/特南特/計劃）。
• Errors-4xx/5xx/429份額和絕對。
• 持續時間-p50/p95/p99端到端和階段（ingress → app → DB →第三方）。

• Utilization-CPU/IO/通道引導。
• Saturation-隊列（run-queue, backlog, DB wait）。
• 錯誤-驅動程序/時間軸錯誤。

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）」-隊列/組成貢獻。
錯誤預算（月份）在99。9％：'預算=0。1%時間_周期'。

推薦的腎小球直方圖： '［5ms, 10 ms, 25 ms, 50 ms, 100 ms, 250 ms, 500 ms, 1s, 2.5s, 5s]`.

5）SLI/SLO和按燃燒率排序

• 可用性：≥ 99。9%/30天。
• 「GET/wallet/balance」 <150 ms； 「POST/payments」 <400 ms.
• 錯誤'5xx' <0。2%。「429」（固體）<總流量的1%。

• 1小時預算的2%或6小時預算的5% →工程師。
• 每天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/錯誤/隊列/池時間：長度/延遲,active worker resource USE： CPU, RSS, FD, GD C停頓

商業標簽：「tenant_id」，「region」，「kyc_level」，「plan」，「feature_flag」。

7）跟蹤和相關性（OpenTelemetry）

所有跳躍上的W3C Trace-Context（「traceparent」，「tracestate」）。
按階段分開：ingress → authZ → app handler → DB/Redis → PSP/外部。

Attributes/標簽： 'http.route`, `enduser.id`, `tenant.id`, `idempotency.key`, `risk.score`.

Exemplars：將latency/error圖表上的點與特定的trace-id關聯起來。

Sampling:

基於1-10％的「常規」路徑，

基於尾巴的尾巴（采取緩慢/錯誤），

自適應的峰值和事件。
Baggage：將「tenant」/「risk」移至切口，而無需標記每個事件。

8） Logi： 結構和隱私

結構化的JSON；必填字段：'ts'、'trace_id'、'span_id'、'route'、'status'、'latency_ms'、'tenant'、'user_id_hash'。
PII政策：掩蓋PAN/PII；禁止秘密/代幣。
Log Sampling：高於4xx/5xx/429和「長」查詢。

9） dashbords地圖（最低設置）

1.Exec-Summary：RPS，可用性，錯誤率，p95/p99 latency，429份額，burn-rate預算。
2.Per-Route：RPS/錯誤/尾巴的最高內含物；版本比較（金絲雀）。
3.Per-Tenant/Plan：負載/成本/錯誤領導者。

4.Dependency Health： DB, cache, PSP/外部-latency,錯誤,aturation.

5.能力：CPU/RAM/FD，隊列，連接池，GC，容器限制。
6.Security/Abuse：401/403, 429/policy, geo/ASN切片,retrais爆發。

10）Alerta（閾值和趨勢）

'error_rate {route}> 2%（5分鐘）和RPS> N → ager。
'p99_latency {critical}'>目標閾值（10分鐘）。
預算中的「burn_rate」（請參閱第5節）。
DB 「timeouts」/「deadlocks」或「queue_time」> X ms的增長。
外部提供商：'outbound_5xx_rate {provider}> 1%+SLO依賴。

11）電容規劃和性能

小定律：「L=λ· W」（平均隊列長度=交通×平均時間）。
目標p95分布：「ingress+app+DB+external+queue」。
Concurrency budget：最大限度的同時寫操作。
預算指標：「ms CPU每個請求」；我們保持30-50%的存量達到峰值。
與rate-limit的交互：測量配額「上限」中的查詢比例以及對潛伏性的影響。

12）負載和合成檢查

物種：基本負載，bursts × 10，「臺階」，長期高原，壓力/混亂（殺死nod，網絡延遲），根據關鍵客戶場景合成。
分析：CPU/alloc/lock-contention, N +1 （SQL/HTTP）,慢代碼。
後退控制：p95/p99/發布前/發布後錯誤的比較（金絲雀）。

13）費用（成本）

成本指標：'cpu_ms'、'egress_bytes'、'db_calls'、'$per 1k requests'。
對端口/tenant/fich：來自編排器的計費標簽+負載度量→ unit經濟學API報告。
優化算法：我們根據「traffic × cost ×（p95 −目標）」的乘積選擇TOP端點。

14） Tenant Per-Analytics和「公平」

所有關鍵指標均帶有「tenant_id/plan」標簽。
「重型」客戶在p99尾巴中的份額；單獨的限額/配額和收支預算。
公平參觀：過載時，我們減少「高調」租戶的份額。

15） iGaming/財務細節

「kyc_level」，「risk_tier」，「payment_method」上的切口。
「現金」路徑的SLI（「POST/deposits」，「POST/withdrawals」）：下面的目標p95，單獨的錯誤預算。
時間到錢包（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）。
Alertes通過「噪音」（單向和單個閾值）。
p99不包括queue時間（掩蓋了實際退化）。

18）prod就緒清單

• 由SLI/SLO和錯誤預算定義，與業務一致。
• 單個latency直方圖和狀態類；p95/p99在行車記錄儀上。
• 完整跟蹤（OTel）, Log/Metric/Trace相關性。
• Alerta burn-rate（雙窗口）、p99閾值和error-rate。
• 精算師/精算師切割計劃和價值報告。
• Dashbords：Exec，Per-Route，Dependencies，Capacity，Abuse。
• 負載場景（burst/Plate/Stress）,分析。
• 有抖動的撤退政策；考慮撤退對RPS的影響。
• 針對合作夥伴和公共客戶的SLA/SLO文檔。
• 重建/掩蓋日誌,PII保護。

19) TL;DR

在SLI/SLO和error-budget周圍建立觀察力，測量RED/USE，收集帶有p95/p99和「queue time」的latency直方圖，將單個跟蹤id從外圍擴展到DB，使用尾巴/自適應采樣，保持主切口/價值切口和雙窗口。burn-rate-alerting。根據隊列規律和業務指標的影響來規劃容量；反模式-中位數而不是感光，高基數和不負責任的外部依賴性。