分析和性能指标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。根据队列规律和业务指标的影响来规划容量；反模式-中位数而不是感光，高基数和不负责任的外部依赖性。