2. Exporter 基础：Prometheus Exporter 的工作原理、常见 Exporter 类型

在 Prometheus 生态中，Exporter 是连接目标系统与监控系统的桥梁。它负责将目标系统的非 Prometheus 原生指标（如操作系统状态、HTTP 探针结果、业务自定义数据）转换为 Prometheus 能够抓取的格式，并通过 HTTP 端点暴露。理解 Exporter 的工作原理与常见类型，是构建可靠数据采集链路的第一步。

2.1 Exporter 工作原理

Exporter 的核心逻辑遵循一个简洁的“采集 → 转换 → 暴露”循环：

1. 采集：通过系统调用、API 请求、文件读取或协议交互，从目标源获取原始数据。
2. 转换：将原始数据映射为 Prometheus 的四种核心指标类型（Counter、Gauge、Histogram、Summary），并附加适当的标签（Labels）。
3. 暴露：在指定的 HTTP 端点（通常是 /metrics）上，以 Prometheus 文本格式响应 GET 请求。

2.2 常见 Exporter 类型

根据采集目标的不同，Exporter 可分为三大类：系统级、网络/服务级 和 自定义业务级。下表对比了三种最常用的 Exporter 及其核心特征：

2.3 Node Exporter 详解

Node Exporter 是 Prometheus 官方维护的“黄金标准”Exporter，用于采集 Linux 内核暴露的主机级指标。它通过读取 /proc、/sys 等虚拟文件系统获取数据，几乎不产生额外性能开销。

• 采集方式：默认启用多个 Collector（如 cpu、meminfo、diskstats、netstat），每个 Collector 负责一个子系统。
• 指标命名：遵循 node_<subsystem>_<metric> 格式，例如 node_cpu_seconds_total、node_memory_MemAvailable_bytes。
• 常用启动参数：--collector.disable-defaults 可关闭默认 Collector，--collector.textfile.directory 可加载自定义文本文件指标。

2.4 Blackbox Exporter 详解

Blackbox Exporter 采用“黑盒”探测模式，从外部对目标端点发起主动探测，而非被动等待指标暴露。它支持多种探测模块（Module），每个模块定义一种探测协议和参数。

典型的探测流程如下：

1. Prometheus Server 向 Blackbox Exporter 发起带有 target 和 module 参数的 HTTP 请求。
2. Blackbox Exporter 根据 module 配置执行探测（如 HTTP GET、TCP 连接、ICMP ping）。
3. 探测结果（成功/失败、响应时间、状态码、证书信息）被转换为 Prometheus 指标并返回。

2.5 Custom Exporter 开发要点

当官方 Exporter 无法满足业务需求时，需要开发 Custom Exporter。Prometheus 官方提供了多种语言的 Client Library，推荐使用 Python（prometheus_client）或 Go（prometheus/client_golang）。

以下是一个使用 Python 开发的简单 Custom Exporter 示例：

from prometheus_client import start_http_server, Gauge
import time
import random

# 定义指标：业务 QPS 模拟
business_qps = Gauge('business_requests_per_second', 'Current business QPS', ['service'])

def collect_metrics():
    while True:
        # 模拟采集业务数据
        qps_value = random.randint(100, 500)
        business_qps.labels(service='order_api').set(qps_value)
        time.sleep(15)

if __name__ == '__main__':
    start_http_server(8000)  # 暴露 /metrics 端点
    collect_metrics()

开发 Custom Exporter 时需遵循以下原则：

• 指标命名规范：使用 <namespace>_<subsystem>_<metric> 格式，避免与官方指标冲突。
• 标签设计：标签基数（Cardinality）控制在 1000 以内，避免高基数导致 Prometheus 内存膨胀。
• 采集频率：与 Prometheus 的 scrape_interval 对齐，通常为 15s 或 30s。
• 错误处理：采集失败时返回空指标或错误指标，不要阻塞 HTTP 响应。

2.6 选型建议与避坑指南

在实际生产环境中，Exporter 的选型直接影响数据采集链路的稳定性与可维护性。以下是一些经过验证的经验：