Exporter 生态概览：Prometheus Exporter 原理、常见 Exporter 类型
在可观测性体系中，Exporter 是 Prometheus 生态的“数据采集器”。它负责将目标系统的内部指标转换为 Prometheus 能够抓取的格式，是打通“监控目标”与“监控系统”的关键桥梁。理解 Exporter 的工作原理与常见类型，是编写自愈剧本、定位采集异常的基础。
Exporter 核心原理
Exporter 本质上是一个 HTTP 服务，遵循以下工作模型：
- 指标暴露：Exporter 通过 /metrics 端点对外暴露指标数据。
- 数据格式：指标以纯文本格式（Prometheus Exposition Format）返回，每行代表一个指标样本。
- 抓取模型：Prometheus Server 定期（默认 15s）向 Exporter 的 /metrics 发起 HTTP GET 请求，拉取指标。
- 指标类型：支持 Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）、Summary（摘要）四种核心类型。
关键理解：Exporter 是“被动”的，它只负责暴露数据，不负责推送。Prometheus 是“主动”的，它负责拉取。这种 Pull 模型简化了监控架构，但也意味着 Exporter 必须保持 HTTP 服务可用，否则 Prometheus 将无法获取数据。
常见 Exporter 类型
根据监控目标的不同，Exporter 可分为系统级、网络级、应用级和自定义四大类。下表对比了最常用的三种 Exporter 的核心特性：
| Exporter 类型 | 监控目标 | 核心指标 | 典型端口 | 自愈关注点 |
|---|---|---|---|---|
| Node Exporter | Linux/Windows 主机 | CPU、内存、磁盘、网络、文件系统 | 9100 | 进程挂死、端口占用、磁盘满导致无法写日志 |
| Blackbox Exporter | 网络端点（HTTP/HTTPS/TCP/ICMP） | 响应时间、状态码、证书过期时间、TLS 版本 | 9115 | 配置错误、ICMP 权限不足、DNS 解析失败 |
| Custom Exporter | 业务应用、中间件、数据库 | QPS、延迟、错误率、连接数、队列深度 | 自定义 | 代码 bug、依赖服务不可用、指标格式错误 |
Node Exporter：主机级监控的基石
Node Exporter 是 Prometheus 生态中部署最广泛的 Exporter，几乎每台 Linux 主机都会运行。它通过读取 /proc、/sys 等内核接口暴露主机指标。
- 核心指标分类：CPU 使用率（node_cpu_seconds_total）、内存使用（node_memory_MemAvailable_bytes）、磁盘 I/O（node_disk_io_time_seconds_total）、网络流量（node_network_receive_bytes_total）。
- 自愈常见场景：进程被 OOM Killer 杀死、端口被其他进程占用、磁盘空间不足导致 Exporter 无法写入 PID 文件。
- 配置要点：默认启用所有采集器，可通过 --collector.disable-defaults 和 --collector.enable 精确控制。
自愈提示：Node Exporter 异常时，优先检查 systemctl status node_exporter 和 journalctl -u node_exporter。如果进程消失，自愈剧本应尝试重启并检查 OOM 日志。
Blackbox Exporter：网络探测的瑞士军刀
Blackbox Exporter 通过“黑盒”方式探测网络端点，不关心目标内部状态，只关注外部可达性和响应质量。
- 探测模块：支持 HTTP/HTTPS、TCP、ICMP（ping）、DNS、gRPC 等多种协议。
- 核心指标：probe_success（探测是否成功）、probe_duration_seconds（探测耗时）、probe_http_status_code（HTTP 状态码）、probe_ssl_earliest_cert_expiry（证书过期时间）。
- 自愈常见场景：配置文件 YAML 语法错误、ICMP 探测需要 root 权限或 CAP_NET_RAW、DNS 解析超时。
避坑指南：Blackbox Exporter 的配置文件（blackbox.yml）中模块名称大小写敏感。如果 Prometheus 的 scrape_config 中引用了不存在的模块名，会导致所有探测任务失败。自愈剧本应包含配置校验步骤。
Custom Exporter：业务指标的最后一公里
当标准 Exporter 无法满足业务监控需求时，需要开发自定义 Exporter。Prometheus 官方提供了多种语言的 Client Library，其中 Python 和 Go 最为常用。
以下是一个使用 Python 的 prometheus_client 库实现的最小化 Custom Exporter 示例：
from prometheus_client import start_http_server, Gauge
import time
import random
# 定义指标：业务订单量（Gauge 类型）
orders_total = Gauge('app_orders_total', 'Total number of orders', ['status'])
def update_metrics():
while True:
orders_total.labels(status='success').set(random.randint(100, 500))
orders_total.labels(status='failed').set(random.randint(0, 20))
time.sleep(15)
if __name__ == '__main__':
start_http_server(8000) # 暴露 /metrics 在 8000 端口
update_metrics()- 开发要点：指标命名遵循
app_<component>_<unit>规范，避免使用特殊字符。 - 自愈常见场景：Python 依赖缺失、端口被占用、指标更新协程 panic（Go 版）、指标格式不符合 Prometheus 规范导致抓取失败。
- 最佳实践：为 Custom Exporter 添加 /healthz 健康检查端点，方便自愈剧本判断 Exporter 是否存活。
Exporter 异常自愈的通用思路
无论哪种 Exporter，异常自愈剧本都应遵循以下通用步骤：
- 检测：Prometheus 抓取失败（up == 0）或指标缺失。
- 诊断：检查 Exporter 进程状态、端口监听、日志输出。
- 恢复：重启 Exporter 进程、清理磁盘、修正配置。
- 验证：确认 /metrics 端点返回 200，Prometheus 重新抓取成功。