4. 四大黄金信号之错误：错误率定义、HTTP错误码分类、业务错误与基础设施错误的区分

错误（Errors）是黄金信号中直接反映服务质量劣化的核心指标。与延迟或流量不同，错误信号通常意味着系统已经无法正常完成用户请求，是触发告警和应急响应的最高优先级信号之一。本节将系统性地定义错误率、解析HTTP错误码分类，并深入区分业务错误与基础设施错误的本质差异。

4.1 错误率的精确定义

错误率并非简单的“请求失败次数/总请求次数”。在可观测性实践中，错误率需要从请求维度和时间维度两个层面进行定义：

4.2 HTTP错误码分类与可观测性映射

HTTP错误码是错误信号最直接的来源。在可观测性平台中，错误码需要被分类、聚合和关联，才能转化为有效的告警和诊断信息。以下是HTTP错误码的完整分类及其在可观测性中的含义：

4.3 业务错误与基础设施错误的本质区分

在可观测性架构中，错误信号不能仅停留在HTTP状态码层面。业务错误（Business Errors）和基础设施错误（Infrastructure Errors）具有完全不同的根因、影响范围和修复策略。以下是两者的系统性对比：

4.4 错误信号的层次化架构

为了在可观测性平台中有效管理错误信号，建议采用层次化架构，将错误从底层基础设施到上层业务逻辑进行分层采集和关联。以下SVG图展示了这一架构：

4.5 错误率计算的最佳实践

在实际的可观测性平台中，错误率的计算需要遵循以下最佳实践：

1. 区分硬错误与软错误：硬错误（如5xx、连接失败）必须计入SLO；软错误（如业务逻辑失败、4xx）根据业务影响决定是否计入。
2. 使用滑动窗口聚合：避免使用固定日历窗口，推荐使用1分钟、5分钟、1小时的滑动窗口计算错误率，并设置多级告警阈值。
3. 按维度拆分错误率：按服务、端点、地域、版本、用户等维度拆分错误率，快速定位故障范围。
4. 建立错误预算：基于SLO计算错误预算，当错误预算消耗超过一定比例时触发告警。
5. 关联错误与变更：将错误率峰值与部署、配置变更、流量峰值等事件关联，加速根因分析。

# 服务端错误率（5xx）
rate(http_requests_total{status=~"5.."}[5m])
/
rate(http_requests_total[5m])
* 100

# 业务错误率（自定义指标）
rate(business_errors_total{service="order-service"}[5m])
/
rate(business_requests_total{service="order-service"}[5m])
* 100

# 综合错误率（包含业务和基础设施）
(
  rate(http_requests_total{status=~"5.."}[5m])
  +
  rate(business_errors_total[5m])
)
/
(
  rate(http_requests_total[5m])
  +
  rate(business_requests_total[5m])
)
* 100

4.6 错误信号的告警策略

基于错误信号的告警需要避免“告警风暴”和“误报”。以下是推荐的告警策略：

4.7 错误信号的可观测性平台集成

在可观测性平台中，错误信号需要与Metrics、Logs、Traces三大支柱深度集成。以下SVG图展示了错误信号在平台中的流转与关联：

4.8 错误信号监控的常见陷阱

4.9 本章小结

错误信号是黄金信号中最具“杀伤力”的指标，它直接反映了系统是否能够正常提供服务。本章的核心要点包括：

• 错误率需要从请求维度、时间维度和用户感知维度进行精确定义，并与SLO绑定。
• HTTP错误码需要分类处理：5xx必须计入错误率，4xx根据业务定义选择性计入，业务错误需要独立监控。
• 业务错误与基础设施错误在定义、检测方式、根因范围和修复策略上存在本质差异，必须分层采集和关联。
• 错误信号的告警应基于错误预算消耗率和动态阈值，避免静态阈值导致的误报和漏报。
• 可观测性平台需要将错误信号与Metrics、Logs、Traces深度集成，实现从基础设施到业务的全链路错误关联。