1. Exporter 概述
1.1 Exporter 在 Prometheus 生态中的角色
Prometheus 采用“拉取（Pull）”模式采集监控指标。然而，大多数业务系统、中间件或硬件设备并不原生暴露 Prometheus 格式的 HTTP /metrics 端点。Exporter 正是填补这一鸿沟的适配器：它负责从目标系统中获取原始状态数据，将其转换为 Prometheus 可识别的指标格式，并在 HTTP 端口上等待 Prometheus Server 定期抓取。
核心定位： Exporter 是 Prometheus 生态中“数据采集的最后一公里”，是连接目标系统与监控平台的桥梁。
下图展示了 Exporter 在 Prometheus 整体架构中的位置与数据流向：
1.2 常见 Exporter 类型
根据采集目标的不同，Exporter 可分为以下几大类。实际生产环境中，通常需要组合部署多种 Exporter 以覆盖完整的监控面。
| 类别 | 代表 Exporter | 采集目标 | 典型端口 |
|---|---|---|---|
| 基础设施 | node_exporter | CPU、内存、磁盘、网络、系统负载 | 9100 |
| 数据库 | mysqld_exporter / pg_exporter / mongodb_exporter | 连接数、查询性能、复制状态、缓存命中率 | 9104 / 9187 / 9216 |
| 中间件 / 消息队列 | kafka_exporter / rabbitmq_exporter / redis_exporter | 吞吐量、队列深度、延迟、连接数 | 9308 / 9419 / 9121 |
| Web 服务器 / 反向代理 | nginx_exporter / apache_exporter | 请求速率、连接状态、响应时间 | 9113 / 9117 |
| 云原生 / 容器 | cadvisor / kube-state-metrics / blackbox_exporter | 容器资源、K8s 对象状态、网络探测 | 8080 / 8081 / 9115 |
| 硬件 / 网络设备 | snmp_exporter / ipmi_exporter | SNMP OID、传感器温度、电源状态 | 9116 / 9290 |
| 自定义业务 | 自定义 Exporter（本课程重点） | 业务指标：订单量、用户活跃、支付成功率 | 自定义 |
选型建议： 优先使用官方或社区成熟的 Exporter，避免重复造轮子。仅在标准 Exporter 无法满足业务指标采集需求时，才考虑开发自定义 Exporter。
1.3 Exporter 工作原理
Exporter 的内部工作流程可以抽象为三个核心阶段：连接与采集 → 数据转换与指标构建 → HTTP 暴露与响应。下面通过一个通用流程图展示其完整生命周期：
1.4 核心概念：指标类型与标签
Exporter 输出的每个指标都遵循 Prometheus 数据模型。理解以下四个核心概念是开发 Exporter 的基础：
- Metric Name（指标名称）： 唯一标识，如
http_requests_total、node_cpu_seconds_total。 - Labels（标签）： 键值对，用于区分同一指标的不同维度，如
method="GET"、status="200"。 - Value（值）： 一个 float64 数值，代表当前采样点的实际数据。
- Timestamp（时间戳）： 可选，由 Prometheus Server 在抓取时自动添加，Exporter 通常不主动设置。
常见误区： 不要在指标名称中编码维度信息（如
http_requests_get_total），应使用标签（http_requests_total{method="GET"}）。前者会导致指标基数爆炸，后者更灵活且符合 Prometheus 最佳实践。
1.5 Exporter 开发的核心原则
在开始编写自定义 Exporter 之前，需要牢记以下原则，它们将贯穿本课程始终：
- 幂等性： 每次抓取都是独立的，Exporter 不应依赖上一次采集的状态。
- 轻量无状态： Exporter 不存储历史数据，只做实时转换，避免内存泄漏。
- 并发安全： 多个抓取请求可能同时到达，指标更新必须使用线程安全的数据结构。
- 错误隔离： 单个目标采集失败不应影响其他指标的暴露，使用
up指标标记采集状态。 - 可观测性： Exporter 自身也应暴露运行指标（如采集耗时、错误计数），便于运维监控。