3. 数据采集异常分类：Exporter进程挂掉、端口不可达、指标数据延迟、数据格式错误、认证失效
在可观测性体系中，Exporter 是数据采集的“最后一公里”。Exporter 自身的稳定性直接决定了上游监控系统（如 Prometheus、Thanos、Grafana）的数据质量与告警时效。根据生产环境中的故障统计，Exporter 数据采集异常可归纳为以下五大类，每一类都有其独特的根因、表现特征与自愈切入点。
核心原则： 自愈剧本的设计前提是对异常类型的精确分类。错误的分类会导致自愈动作误判，甚至引发“误杀”或“雪崩”。本章将逐一拆解这五类异常，为后续的剧本编排奠定基础。
3.1 Exporter 进程挂掉
这是最严重的一类异常，意味着数据采集完全中断。进程挂掉通常由操作系统级事件触发，而非 Exporter 自身的业务逻辑错误。
| 检测维度 | 检测方法 | 自愈切入点 |
|---|---|---|
| 进程是否存在 | systemctl is-active 或 pgrep | systemd 自动重启 / Supervisor 守护 |
| 退出码分析 | 检查 systemd journal 或 dmesg | OOM 则调整内存限制；Panic 则回滚版本 |
| 资源耗尽 | 监控内存/文件描述符使用率 | 触发资源扩容或重启释放 |
生产经验： 对于关键 Exporter（如 kube-state-metrics、node-exporter），建议同时配置 systemd 的
Restart=always 和外部健康检查（如 Prometheus Blackbox Exporter），形成双重保障。
3.2 端口不可达
进程虽然存活，但无法建立 TCP 连接。这类异常在容器化环境和动态网络策略变更时尤为常见。
- 常见场景： Kubernetes 网络策略（NetworkPolicy）误配置、宿主机 iptables 规则被覆盖、Exporter 监听地址从
0.0.0.0变为127.0.0.1。 - 检测手段： 使用
nc -zv或curl -I进行端口探测，结合 Prometheus 的up指标。 - 自愈策略： 自动恢复 iptables 规则、重启 Exporter 强制重新绑定端口、或通过 Service Mesh 进行流量重定向。
3.3 指标数据延迟
Exporter 进程运行正常，端口可达，但返回的指标数据时间戳严重滞后或缺失最新数据点。这是“慢性病”，容易被忽视。
| 延迟类型 | 表现 | 根因 |
|---|---|---|
| 采集延迟 | Exporter 抓取目标接口耗时 > 30s | 目标系统负载高、数据库慢查询 |
| 上报延迟 | Exporter 本地时间戳与 Prometheus 服务器时间差 > 5min | 时钟不同步、网络传输积压 |
| 处理延迟 | Exporter 内部队列积压，指标被丢弃 | 并发采集数超过 Exporter 处理能力 |
注意： 数据延迟的自愈不能简单依赖“重启”。重启会清空队列，导致数据永久丢失。正确的做法是先降级采集频率，再排查上游瓶颈。
3.4 数据格式错误
Exporter 返回了 HTTP 200，但响应体无法被 Prometheus 解析。这类异常通常发生在 Exporter 版本升级或配置变更后。
- 典型错误： 指标名称包含非法字符、标签值未转义、HELP/TYPE 注释行缺失、暴露了非 OpenMetrics 格式的文本。
- 检测方式： Prometheus 的
prometheus_target_scrapes_exceeded_sample_limit_total和prometheus_target_scrapes_sample_duplicate_timestamp_total等指标。 - 自愈动作： 自动回滚 Exporter 至上一稳定版本、或触发配置校验脚本（
promtool check metrics）。
3.5 认证失效
当 Exporter 启用了 Basic Auth、Bearer 或 mTLS 时，认证凭证失效会导致数据采集被拒绝。这类异常在凭证轮换周期和证书过期时高频发生。
| 认证类型 | 失效表现 | 自愈方案 |
|---|---|---|
| Basic Auth | HTTP 401 Unauthorized | 自动从密钥管理服务（Vault/KMS）拉取最新凭证 |
| Bearer | HTTP 403 Forbidden | 触发 刷新流程，更新 Prometheus 配置中的 bearer__file |
| mTLS | TLS 握手失败 | 自动检测证书有效期，提前 7 天触发证书续期 |
最佳实践： 在 Exporter 自愈剧本中，认证失效应作为“高优先级”异常处理。因为凭证问题通常影响整个采集集群，而非单个实例。建议在剧本中加入“凭证有效性预检”步骤，在采集失败前主动预警。
3.6 异常分类总结矩阵
下表从检测难度、影响范围、自愈成功率三个维度对五类异常进行横向对比，帮助 SRE 团队确定自愈剧本的优先级。
| 异常类型 | 检测难度 | 影响范围 | 自愈成功率 | 推荐自愈优先级 |
|---|---|---|---|---|
| 进程挂掉 | 低 | 单实例 | 高（重启即可） | P0 |
| 端口不可达 | 低 | 单实例/局部 | 中（需排查网络策略） | P0 |
| 指标数据延迟 | 中 | 单实例 | 中（需降级而非重启） | P1 |
| 数据格式错误 | 高 | 全局（版本问题） | 高（回滚即可） | P1 |
| 认证失效 | 中 | 全局（凭证问题） | 高（刷新凭证） | P0 |
设计提示： 在编写自愈剧本时，建议将 P0 级别的异常（进程挂掉、端口不可达、认证失效）设计为“立即触发自愈”，而 P1 级别的异常（数据延迟、格式错误）设计为“观察窗口 + 分级自愈”，避免过度自动化导致系统震荡。