3. 黄金指标概念

RED 方法（Rate、Errors、Duration）是 Tom Wilkie 在 2015 年提出的面向服务的监控模型，最初用于 Prometheus 微服务监控。在日志领域，RED 方法将三个核心信号从指标空间映射到日志事件空间，使 SRE 能够通过日志直接判断服务的健康状态，而无需依赖指标系统。

3.1 RED 三要素的日志语义

3.2 RED 日志黄金指标架构

下图展示了 RED 方法在日志系统中的完整映射链路，从服务请求产生日志，到 Loki 摄取、查询，最终形成三个黄金信号的可视化面板。

3.3 Rate（速率）的日志实现

Rate 在日志中对应的是请求事件的发生频率。与指标系统直接计数不同，日志需要先通过 LogQL 过滤出代表请求开始或结束的事件行，再计算速率。

# 计算每分钟请求速率（基于 REQUEST_START 标记）
sum by (service, endpoint) (
  rate({app="order-service"} |= "REQUEST_START" [1m])
)

# 计算每分钟请求速率（基于状态码存在性）
sum by (service) (
  rate({app="api-gateway"} |~ "status=\d{3}" [1m])
)

3.4 Errors（错误）的日志实现

Errors 在日志中对应的是错误级别事件或错误状态码的出现频率。日志的错误检测比指标更灵活，可以基于日志级别、状态码范围或错误关键字进行多维过滤。

# 计算错误率（错误请求 / 总请求）
sum by (service) (
  rate({app="api"} |= "status=5" [1m])
) / sum by (service) (
  rate({app="api"} |~ "status=\d{3}" [1m])
) * 100

3.5 Duration（持续时间）的日志实现

Duration 在日志中对应的是请求处理时间的数值提取与分位数计算。这是 RED 三要素中日志实现最复杂的一环，需要日志中包含结构化的耗时字段，并通过 unwrap 操作提取数值。

# 提取 duration 字段并计算 P99 延迟
quantile_over_time(0.99,
  {app="order-service"} |= "REQUEST_END"
  | json
  | unwrap duration [5m]
)

# 按 endpoint 分组计算 P50 延迟
quantile_over_time(0.50,
  {app="api-gateway"} |= "REQUEST_END"
  | json
  | unwrap duration [5m]
) by (endpoint)

3.6 RED 日志标签治理原则

为了高效支持 RED 查询，日志标签（Label）的设计必须遵循以下原则：

• Rate 标签： 至少包含 service、endpoint、method，用于按服务维度聚合速率。
• Errors 标签： 至少包含 status_code、error_type，用于按错误类型分类。
• Duration 标签： 至少包含 duration 字段（作为日志行内的结构化字段，而非标签），避免高基数标签爆炸。
• 公共标签： app、env、host、trace_id 作为所有日志的基座标签。

3.7 RED 日志查询性能对比