4、核心指标详解:错误(Errors)分类
在日志工程中,错误(Errors)是 Golden Signals 中衡量系统健康度的关键指标。不同于业务层面的逻辑错误,日志管道中的错误具有明确的工程语义,必须按故障发生阶段进行精细化分类,才能快速定位根因。
根据日志数据流经的路径,我们将错误划分为四大类:采集错误、传输错误、存储错误和副本同步错误。每一类错误的监控阈值、处理策略和恢复手段均不相同。
4.1 错误分类全景图
下图展示了日志从产生到持久化的完整链路,并标注了各阶段可能出现的错误类型。理解这张图是进行错误指标配置的前提。
4.2 采集错误(Collection Errors)
采集错误发生在日志代理(Agent)从源端读取日志文件或数据流的过程中。这是日志管道的第一个故障点,通常与操作系统环境或应用配置相关。
| 错误子类 | 典型场景 | 影响 | 推荐监控指标 |
|---|---|---|---|
| 文件权限拒绝 | Agent 以非 root 用户运行,无法读取 /var/log/ 下的日志 | 日志完全丢失 | file_read_errors_total |
| 日志轮转丢失 | 日志文件在 Agent 读取前被 logrotate 压缩或删除 | 日志片段丢失 | log_rotation_miss_total |
| 编码解析失败 | 日志包含非 UTF-8 字符,Agent 无法解析 | 单条日志丢弃 | parse_errors_total |
| 多行合并超时 | Java 堆栈日志跨多行,合并等待超时 | 堆栈日志被截断 | multiline_timeout_total |
配置建议: 采集错误应配置为 P1 级告警。建议设置
file_read_errors_total 在 5 分钟内持续 > 0 时触发告警,因为文件权限问题通常需要人工介入修复。
4.3 传输错误(Transmission Errors)
传输错误发生在日志数据从 Agent 发送到中间件(如 Kafka)或直接发送到存储层的过程中。网络抖动、服务端限流、数据包损坏是常见原因。
| 错误子类 | 典型场景 | 影响 | 推荐监控指标 |
|---|---|---|---|
| 网络连接超时 | Agent 与 Kafka Broker 之间的 TCP 连接超时 | 批量数据重传或丢失 | network_timeout_total |
| 序列化/反序列化失败 | 日志包含特殊字符导致 Avro/Protobuf 序列化异常 | 单条日志丢弃 | serialization_errors_total |
| 服务端限流拒绝 | Kafka 或 Logstash 触发 backpressure,拒绝连接 | 数据积压在 Agent 缓冲区 | rejected_connections_total |
| SSL/TLS 握手失败 | 证书过期或配置错误 | 传输通道中断 | tls_handshake_errors_total |
关键阈值: 传输错误中的
rejected_connections_total 通常预示着下游服务过载。建议设置告警阈值为:连续 3 个 1 分钟窗口内,该指标 > 10,并立即检查 Kafka 或 Logstash 的 CPU/内存使用率。
4.4 存储错误(Storage Errors)
存储错误发生在日志数据写入 Elasticsearch 或其他存储引擎时。这类错误通常与索引配置、集群资源或数据格式有关。
| 错误子类 | 典型场景 | 影响 | 推荐监控指标 |
|---|---|---|---|
| 索引拒绝(Index Rejection) | 写入请求超过索引的 index.translog.flush_threshold_size |
批量写入失败 | index_rejection_count |
| 映射冲突(Mapping Conflict) | 同一字段在不同日志中类型不一致(如 string vs long) | 单条日志写入失败 | mapper_parse_exception_count |
| 磁盘空间不足 | 数据节点磁盘使用率超过 95% | 集群只读,写入全部失败 | disk_watermark_reached_count |
| 分片队列满 | 写入线程池队列积压,拒绝新请求 | 写入延迟飙升 | thread_pool_write_rejected |
4.5 副本同步错误(Replica Sync Errors)
副本同步错误是分布式存储系统特有的错误类型,发生在主分片(Primary Shard)与副本分片(Replica Shard)之间。这类错误直接影响数据的高可用性和持久性。
| 错误子类 | 典型场景 | 影响 | 推荐监控指标 |
|---|---|---|---|
| 分片未分配 | 副本分片因节点故障无法分配到目标节点 | 数据冗余度降低 | unassigned_shards |
| 复制延迟过高 | 主分片写入过快,副本同步跟不上 | 主分片故障时丢失最近写入数据 | replication_lag_in_bytes |
| 同步线程池拒绝 | 副本节点资源不足,拒绝同步请求 | 副本分片落后或离线 | thread_pool_replication_rejected |
| 版本冲突 | 主分片与副本分片对同一文档的版本号不一致 | 数据不一致 | version_conflict_count |
副本均衡配置要点: 在 Elasticsearch 中,副本同步错误通常与
cluster.routing.allocation 配置相关。建议设置 cluster.routing.allocation.enable: all 确保副本可以自动分配;同时监控 unassigned_shards 指标,当该值持续大于 0 时,应检查集群节点状态和磁盘水位线。
4.6 错误指标聚合与告警策略
在实际运维中,不应孤立地监控每一类错误,而应建立分层聚合策略。下表展示了推荐的错误指标聚合维度及对应的告警级别。
| 聚合维度 | 包含错误类型 | 告警级别 | 响应时间要求 |
|---|---|---|---|
| 管道级错误率 | 采集 + 传输 + 存储 | P0(Critical) | 5 分钟内响应 |
| 数据完整性错误率 | 副本同步 + 存储映射冲突 | P1(High) | 15 分钟内响应 |
| 瞬时错误率 | 网络超时 + 序列化失败 | P2(Medium) | 30 分钟内响应 |
| 配置类错误率 | 文件权限 + SSL 握手失败 | P3(Low) | 下一个工作日 |
避坑指南: 不要将所有错误类型都配置为 P0 告警。例如,
mapper_parse_exception_count 通常由应用日志格式变更引起,属于配置类问题,设置为 P2 即可。过度告警会导致告警疲劳,反而掩盖真正的管道级故障。