1. Exporter 基础概念
1.1 Exporter 在 Prometheus 生态中的角色
Prometheus 采用“拉取（Pull）”模式采集指标，但大多数业务系统、中间件或基础设施组件并不原生暴露 Prometheus 格式的 HTTP /metrics 端点。Exporter 正是填补这一鸿沟的适配层：它负责从目标系统中读取状态数据，将其转换为 Prometheus 可识别的指标格式，并在 HTTP 端口上等待 Prometheus Server 周期性抓取。
核心角色：Exporter 是 Prometheus 生态的“指标翻译器”与“数据网关”，将非标准、非 Prometheus 原生系统的可观测数据统一接入监控体系。
在标准采集链路中，Exporter 位于 Prometheus Server 与监控目标之间：
1.2 常见 Exporter 类型
社区和官方维护了上百种 Exporter，覆盖基础设施、数据库、消息队列、网络设备、存储、云服务等场景。以下是课程中频繁涉及的几类核心 Exporter：
| Exporter 名称 | 监控目标 | 默认端口 | 典型指标示例 |
|---|---|---|---|
| Node Exporter | Linux / Unix 主机 | 9100 | node_cpu_seconds_total, node_memory_MemAvailable_bytes, node_filesystem_avail_bytes |
| Blackbox Exporter | HTTP / HTTPS / TCP / ICMP 端点 | 9115 | probe_success, probe_duration_seconds, probe_http_status_code |
| MySQL Exporter | MySQL / MariaDB 数据库 | 9104 | mysql_global_status_connections, mysql_global_status_threads_connected |
| Redis Exporter | Redis 缓存 | 9121 | redis_up, redis_memory_used_bytes, redis_connected_clients |
| cAdvisor | 容器 / Docker 运行时 | 8080 | container_cpu_usage_seconds_total, container_memory_usage_bytes |
| SNMP Exporter | 网络设备（交换机、路由器） | 9116 | snmp_ifInOctets, snmp_ifOutOctets, snmp_ifOperStatus |
选型建议：对于主机级监控，Node Exporter 是首选；对于黑盒探测（如外部 URL 健康检查），必须使用 Blackbox Exporter；对于数据库和中间件，优先使用官方或 CNCF 推荐的专用 Exporter。
1.3 Exporter 的工作原理
Exporter 的内部工作流程可以抽象为三个核心阶段：数据采集 → 指标转换 → HTTP 暴露。下面以 Node Exporter 为例，拆解其运行时行为：
- 采集器（Collector）注册：Exporter 启动时注册多个 Collector，每个 Collector 负责一类子系统（如 CPU、内存、磁盘、网络、文件系统）。
- 指标抓取触发：Prometheus Server 向 Exporter 的 /metrics 端点发起 HTTP GET 请求，Exporter 收到请求后遍历所有已注册的 Collector。
- 数据读取：每个 Collector 调用系统接口（如 /proc、/sys、/etc 下的虚拟文件）读取原始状态数据。例如 CPU Collector 读取 /proc/stat，内存 Collector 读取 /proc/meminfo。
- 指标转换与格式化：原始数据被转换为 Prometheus 指标格式，包括指标名称、标签（Label）、时间戳（由 Prometheus Server 赋值）和样本值。
- 响应返回：Exporter 将所有指标以纯文本格式（Prometheus 文本协议）写入 HTTP Response Body，并设置 Content-Type: text/plain; version=0.0.4。
常见故障点：采集阶段可能因系统文件权限不足、内核接口变更、文件描述符耗尽而失败；转换阶段可能因指标名称冲突、标签基数爆炸导致性能问题；HTTP 暴露阶段可能因端口冲突、TLS 配置错误、并发抓取超时而中断。
以下 SVG 展示了 Node Exporter 单次抓取请求的内部执行流程：
1.4 Exporter 指标输出格式示例
以下是从 Node Exporter 的 /metrics 端点截取的真实指标片段，展示了 Prometheus 文本协议的典型结构：
# HELP node_cpu_seconds_total Seconds the cpus spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 284123.45
node_cpu_seconds_total{cpu="0",mode="system"} 3892.12
node_cpu_seconds_total{cpu="0",mode="user"} 12567.89
# HELP node_memory_MemAvailable_bytes Memory information field MemAvailable_bytes.
# TYPE node_memory_MemAvailable_bytes gauge
node_memory_MemAvailable_bytes 8.123456e+09
# HELP node_filesystem_avail_bytes Filesystem space available to non-root users in bytes.
# TYPE node_filesystem_avail_bytes gauge
node_filesystem_avail_bytes{device="/dev/sda1",fstype="ext4",mountpoint="/"} 5.4321e+10
关键字段说明：
•
•
•
•
•
# HELP：指标描述，用于可读性说明。•
# TYPE：指标类型（counter / gauge / histogram / summary），决定 PromQL 的聚合行为。•
{} 内为标签：用于维度区分，如 cpu、mode、device、mountpoint。•
数值：浮点数或整数，Prometheus 统一使用 float64 存储。
1.5 Exporter 的部署与生命周期管理
在生产环境中，Exporter 通常以以下方式部署：
- 二进制进程：直接下载编译好的二进制文件，通过 systemd 或 supervisor 管理，适合物理机或虚拟机。
- 容器化：以 Docker 容器运行，通过 docker-compose 或 Kubernetes DaemonSet / Deployment 编排，适合云原生环境。
- Sidecar 模式：在 Kubernetes Pod 中作为 Sidecar 容器与业务容器同生命周期，用于采集业务自定义指标。
Exporter 本身是无状态的，不存储历史数据，每次抓取都是独立的全量采集。这意味着 Exporter 的故障不会导致历史指标丢失，但会导致抓取窗口出现数据空洞，直接影响误差预算的准确性。
误差预算影响：如果 Exporter 在 Prometheus 抓取周期内响应超时或返回错误，Prometheus 会将该次抓取标记为失败（up == 0），导致该时间点的指标缺失。在计算 SLI 和误差预算时，缺失数据点会被视为“未知”或“失败”，从而扭曲实际的可用性统计。