业务指标与系统指标必须分离设计，每个业务指标需绑定明确动因、采用domain_action_result{label=value}命名、覆盖端到端原子路径、带统一trace_id、禁用网关聚合、动态基线告警、强制健康检查及统一SDK埋点。
业务指标和系统指标必须分开设计
业务监控不是把 CPU、内存、HTTP 状态码堆在一起就完事。用户真正关心的是“今天下单失败了多少单”“支付成功率跌到 92% 是不是风控策略出了问题”，这些无法从 psutil 或 prometheus_client 默认指标里直接推导出来。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 每个业务指标必须对应一个明确的业务动因，比如
order_submit_fail_count要绑定到订单提交接口的异常分支，而不是笼统地统计“所有 5xx” - 避免用系统维度反推业务逻辑，例如不能靠
http_request_duration_seconds_bucket的 P99 上升来判断“用户下单变慢”，得单独埋点order_submit_duration_ms并按渠道、用户等级打标 - 指标命名采用
domain_action_result{label=value}格式，如payment_process_result{status="timeout",channel="wxpay"}，不加业务上下文的指标后期根本查不动
关键路径必须有“端到端可追溯”的原子指标
一个订单从点击下单到支付成功，中间可能经过网关、风控、库存、营销、支付等多个服务。如果只在最外层记一个 order_success_total，出问题时根本不知道卡在哪一环。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 对每段关键调用都记录原子事件：比如风控服务返回
fraud_check_result{decision="reject",reason="blacklist"}，库存服务返回stock_lock_result{sku="1001",result="failed"} - 所有原子指标带统一 trace_id 标签，且必须与日志中的
trace_id完全一致，否则 Grafana 里点开报警没法跳转到对应日志 - 禁止在客户端或网关层聚合指标后再上报，比如不要在 API 网关里把各下游状态合并成一个“整体成功率”，会丢失下游差异性
告警阈值不能固定写死，得按业务节奏动态调整
凌晨三点的下单量只有白天的 5%，如果对 order_submit_fail_rate 统一设 3% 告警，要么半夜狂响，要么大促时完全不响。
