3. 故障模式分析:Exporter 进程崩溃、端口监听失效、指标数据延迟、网络分区导致的采集失败
在生产环境中,Exporter 链路故障并非单一场景,而是由多种底层故障模式叠加或独立触发。本章对四种最常见的故障模式进行结构化分析,明确每种模式的根因、现象、影响范围及可观测性特征,为后续自愈剧本的触发条件与恢复动作提供精确依据。
3.1 故障模式总览
下表从故障层、根因、典型现象、影响范围四个维度对四种模式进行对比,帮助 SRE 快速建立故障分类心智模型。
| 故障模式 | 故障层 | 典型根因 | 典型现象 | 影响范围 |
|---|---|---|---|---|
| Exporter 进程崩溃 | 进程层 | OOM、panic、依赖库异常、配置错误 | 进程消失、systemd 状态为 failed、日志无输出 | 单节点 Exporter 完全不可用 |
| 端口监听失效 | 网络层 | 端口被占用、防火墙规则变更、listen backlog 满 | 进程存活但端口无响应、curl 超时或 connection refused | 采集端无法建立 TCP 连接 |
| 指标数据延迟 | 数据层 | 采集耗时过长、目标端响应慢、scrape_timeout 配置过小 | up == 1 但 scrape_duration_seconds 接近 timeout、指标时间戳滞后 | 指标数据陈旧,告警延迟或误报 |
| 网络分区 | 基础设施层 | 交换机故障、路由黑洞、带宽打满、iptables 丢包 | 采集端与 Exporter 之间 ping 丢包、TCP 重传率高、up == 0 | 批量 Exporter 同时不可达 |
3.2 Exporter 进程崩溃
进程崩溃是最直接的故障模式。Exporter 进程因资源耗尽、代码缺陷或外部依赖异常而异常退出,导致 Prometheus 采集端在下一个 scrape 周期内立即感知到 up == 0。
3.2.1 根因分类
- 内存溢出(OOM):Exporter 在处理大量指标时内存占用持续增长,被 cgroup 或系统 OOM Killer 终止。
- 运行时 panic:Go/Rust 等语言编写的 Exporter 在遇到未捕获异常时直接崩溃。
- 配置热加载失败:Exporter 在 reload 配置时出现语法错误,导致进程退出。
- 依赖服务不可用:Exporter 依赖的数据库或 API 超时,导致主线程阻塞后 watchdog 触发重启。
3.2.2 可观测性特征
- 进程级:systemd 单元状态为
failed,journalctl中可看到Main process exited, code=exited, status=1。 - 指标级:Prometheus 中
up{job="xxx"}从 1 跳变为 0,scrape_samples_scraped归零。 - 日志级:Exporter 日志最后一条通常包含
fatal、panic或OOM关键字。
自愈触发条件:
up == 0 持续超过 2 个 scrape 周期(默认 30s),且 probe_success == 0(如配置了 blackbox 探针)。自愈动作:systemd restart 或容器重启。
3.3 端口监听失效
进程存活但端口无法建立连接,是比进程崩溃更隐蔽的故障模式。采集端看到 connection refused 或 connection timeout,但进程本身仍在运行。
3.3.1 典型场景
- 端口冲突:另一个进程占用了 Exporter 配置的端口,Exporter 启动时绑定失败但未退出。
- 防火墙/安全组变更:iptables 或云安全组规则被修改,导致采集端 IP 被拒绝。
- listen backlog 溢出:高并发连接导致 TCP 全连接队列满,新连接被内核丢弃。
3.3.2 诊断命令
# 检查端口是否在监听
ss -tlnp | grep :9100
# 检查进程是否存活
ps aux | grep node_exporter
# 测试端口连通性
curl -v --connect-timeout 3 http://192.168.1.10:9100/metrics
3.4 指标数据延迟
指标数据延迟是一种“灰色故障”——Exporter 进程正常、端口正常、up == 1,但返回的指标时间戳严重滞后,导致 Prometheus 存储的数据无法反映当前系统状态。
3.4.1 延迟产生路径
- 目标端响应慢:Exporter 在采集目标指标时(如查询数据库、读取大文件)耗时过长。
- scrape_timeout 配置过小:Prometheus 在 timeout 内未收到完整响应,放弃本次采集。
- 指标队列积压:Exporter 内部指标生成速度超过 HTTP 响应发送速度。
3.4.2 关键指标
| 指标名 | 正常范围 | 异常阈值 |
|---|---|---|
scrape_duration_seconds |
< 1s | > 5s 或接近 scrape_timeout |
scrape_timeout_seconds |
10s(默认) | 实际 duration 超过 80% timeout |
up |
1 | 0 或 1 但伴随高 duration |
注意:指标数据延迟会导致告警引擎基于陈旧数据做出错误决策。例如,CPU 使用率已下降,但 Prometheus 仍使用 5 分钟前的数据触发告警,造成误报。
3.5 网络分区导致的采集失败
网络分区是影响范围最大的故障模式。当采集端与 Exporter 之间的网络路径出现中断或严重劣化时,批量 Exporter 会同时不可达,造成大规模采集空洞。
3.5.1 网络分区类型
- 硬分区:物理链路中断、交换机宕机、光纤被挖断。现象:100% 丢包,
up == 0批量出现。 - 软分区:路由黑洞、BGP 会话中断、带宽打满导致 TCP 重传。现象:部分丢包,
scrape_duration_seconds飙升,up间歇性为 0。 - 对称分区 vs 非对称分区:对称分区下采集端无法到达 Exporter,Exporter 也无法回包;非对称分区下请求可达但响应丢失,表现为 TCP 连接超时。
3.5.2 影响特征
- 批量性:同一网段或机架内的 Exporter 同时出现
up == 0。 - 时间相关性:故障时间点与网络变更、部署操作高度相关。
- 指标特征:
probe_success(blackbox)为 0,node_network_transmit_drop_total或node_network_receive_drop_total在交换机侧飙升。
3.6 故障模式关联 SVG 图
下图展示了四种故障模式在 Exporter 链路中的位置、检测信号以及自愈入口点,帮助理解故障传播路径。
3.7 故障模式与自愈策略映射
每种故障模式对应不同的自愈策略,错误的恢复动作可能加剧故障。下表给出推荐的自愈动作与前置条件。
| 故障模式 | 推荐自愈动作 | 前置条件 | 回滚条件 |
|---|---|---|---|
| 进程崩溃 | systemd restart 或容器重启 | 确认进程已退出(up == 0) | 重启后 up 恢复为 1 |
| 端口监听失效 | 释放端口并重启 Exporter | 进程存活但端口无响应 | 端口监听恢复,curl 成功 |
| 指标数据延迟 | 动态调整 scrape_timeout 或扩容 Exporter | scrape_duration_seconds 持续超过 5s | duration 回落至 1s 以下 |
| 网络分区 | 切换采集路径或启用备用 Exporter | 批量 Exporter 同时不可达 | 主路径恢复后切回 |
最佳实践:建议为每个 Exporter 配置至少两个检测信号源(Prometheus 直接采集 + blackbox 探针),避免因单一检测信号误判故障模式。例如,进程崩溃时 up == 0 且 probe_success == 0;而网络分区时 up == 0 但 probe_success 可能为 1(如果探针路径不同)。