黄金信号

四个问题

服务出问题时，首先要问：它慢吗？它在接收流量吗？它在失败吗？它是不是快用尽某种资源了？黄金信号直接对应这四个问题。围绕它们组织的仪表盘能帮助值班工程师在深入 trace 或日志之前快速定位方向。

# Latency: p95 by route
histogram_quantile(0.95, sum by (route, le) (rate(http_request_duration_seconds_bucket[5m])))

# Errors: 5xx ratio
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# Saturation: connection pool in use
db_pool_in_use / db_pool_max

拆分延迟与错误

把快速失败和慢速成功混在一个平均值里，会同时掩盖两者。要分别统计成功和失败请求的延迟，并使用分位数而不只是均值。平均 50 毫秒、p99 却达到 4 秒的服务，对尾部用户来说就是坏的。

饱和度预测悬崖

CPU 90% 对批处理任务可能没事，对延迟敏感的 API 却是致命的。队列深度、线程池占用、连接池占用和内存压力，往往比单独的 CPU 更能反映饱和度。对真正限制吞吐的资源告警，并测试达到极限时的行为。

何时使用

把黄金信号作为请求型服务的默认仪表盘和告警框架。优点是一小组可行动的指标覆盖大多数事故；缺点是它不解释原因或业务影响。与穷举式指标相比，黄金信号减少噪音，但需要 trace、日志和业务指标补全全貌。