第4章 Exporter实战

4. Exporter实战：Node Exporter部署与指标采集、自定义Exporter开发（Python版）、Exporter注册与健康检查

好，咱们进入Exporter实战环节。这一章我打算把三个核心问题讲透：怎么部署Node Exporter、怎么用Python写一个自己的Exporter、以及怎么让Exporter在Prometheus里“活”起来。说白了，就是让你从会用工具到能造工具。

4.1 Node Exporter部署与指标采集

Node Exporter是Prometheus生态里最经典的“数据采集器”。它专门负责从Linux系统里扒拉各种指标——CPU、内存、磁盘、网络，你想到的系统层面数据它基本都能搞。

部署其实很简单，我个人习惯用二进制方式，因为可控性高。你可以在官方下载页找到对应平台的压缩包。解压后直接运行：

wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
tar xvf node_exporter-1.6.0.linux-amd64.tar.gz
cd node_exporter-1.6.0.linux-amd64
./node_exporter

启动后默认监听在9100端口。你可以用浏览器或者curl验证一下：

curl http://localhost:9100/metrics

你会看到一大串以# HELP和# TYPE开头的文本。这就是Prometheus能理解的指标格式。嗯，这里要注意：Node Exporter默认会采集所有它能采集的指标，但有些指标你可能用不上。我建议用--collector.disable-defaults参数关闭默认采集，然后按需开启：

./node_exporter --collector.disable-defaults \
  --collector.cpu \
  --collector.meminfo \
  --collector.filesystem \
  --collector.netdev

我在项目中遇到过一个问题：默认开启的采集器太多，导致目标机器负载飙升。尤其是磁盘I/O密集型的服务器，diskstats采集器会频繁读取/proc/diskstats，反而影响了业务。所以，按需采集是运维的第一原则。

小技巧：你可以用--collector.textfile.directory参数指定一个目录，Node Exporter会读取该目录下所有.prom后缀的文件，把它们的内容作为指标暴露出来。这样你就能在不修改Exporter代码的情况下，注入自定义指标。

4.2 自定义Exporter开发（Python版）

Node Exporter虽然强大，但总有它覆盖不到的场景。比如你想采集某个业务进程的QPS、某个API的响应时间，或者某个中间件的连接数。这时候就需要自己写Exporter了。

我推荐用Python，因为Prometheus官方提供了prometheus_client库，封装得很好。你想想看，写一个Exporter本质上就是启动一个HTTP服务，暴露/metrics端点，返回Prometheus格式的文本。

先装库：

pip install prometheus_client

一个最简单的Exporter长这样：

from prometheus_client import start_http_server, Gauge
import time
import random

# 定义一个Gauge类型的指标
request_count = Gauge('myapp_requests_total', 'Total number of requests')

def collect_metrics():
    while True:
        # 模拟采集业务数据
        count = random.randint(100, 200)
        request_count.set(count)
        time.sleep(15)

if __name__ == '__main__':
    # 启动HTTP服务，监听8000端口
    start_http_server(8000)
    collect_metrics()

启动后访问http://localhost:8000/metrics，你就能看到myapp_requests_total这个指标了。

但实际场景不会这么简单。我做过一个自定义Exporter，用来采集某个老旧中间件的连接池状态。那个中间件没有暴露任何监控接口，我只能通过它的管理命令去解析输出。嗯，这里的关键是：采集逻辑要稳定，不能因为采集失败导致Exporter崩溃。

一个更完整的示例：

from prometheus_client import start_http_server, Gauge, Counter, Histogram
import time
import subprocess
import re

# 定义指标
db_connections = Gauge('db_connections', 'Current database connections', ['host'])
query_duration = Histogram('db_query_duration_seconds', 'Query duration in seconds', ['query_type'])

def parse_db_status():
    try:
        # 模拟执行管理命令
        result = subprocess.run(['dbctl', 'status'], capture_output=True, text=True, timeout=5)
        # 用正则解析输出
        match = re.search(r'connections: (\d+)', result.stdout)
        if match:
            db_connections.labels(host='localhost').set(int(match.group(1)))
    except Exception as e:
        # 采集失败时记录日志，但不影响Exporter运行
        print(f"采集失败: {e}")

if __name__ == '__main__':
    start_http_server(8000)
    while True:
        parse_db_status()
        time.sleep(30)

避坑指南：我曾经在自定义Exporter里忘记处理subprocess的超时，结果管理命令卡住了，整个Exporter也跟着卡死。Prometheus那边收不到数据，报警直接炸了。所以，所有外部调用都要加超时，这是血的教训。

4.3 Exporter注册与健康检查

Exporter写好了，怎么让Prometheus知道它的存在？说白了就是两步：配置scrape_configs，然后确保Exporter活着。

注册到Prometheus：

在Prometheus的配置文件prometheus.yml里添加一个job：

scrape_configs:
  - job_name: 'myapp'
    scrape_interval: 30s
    static_configs:
      - targets: ['192.168.1.100:8000']

重启Prometheus，它就会每隔30秒去拉一次数据。你可以在Prometheus的Web UI的Targets页面看到这个Exporter的状态。

健康检查怎么做？

Prometheus本身不提供主动的健康检查机制，它只会在拉取指标时判断Exporter是否可达。如果连续几次拉取失败，Prometheus会把这个Target标记为DOWN。

但Exporter自己可以提供一个健康检查端点。我习惯在自定义Exporter里加一个/health端点：

from flask import Flask, jsonify
from prometheus_client import generate_latest, CONTENT_TYPE_LATEST

app = Flask(__name__)

@app.route('/metrics')
def metrics():
    return generate_latest(), 200, {'Content-Type': CONTENT_TYPE_LATEST}

@app.route('/health')
def health():
    # 检查内部状态，比如数据库连接是否正常
    return jsonify({'status': 'ok'}), 200

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8000)

这样，你可以在外部监控系统（比如Consul、Kubernetes的探针）里定期检查/health端点。如果返回非200，就说明Exporter出问题了。

  核心要点：Exporter的健康检查不只是检查进程是否活着，更要检查它的采集能力是否正常。比如数据库Exporter，如果数据库连接断了，Exporter进程还在，但采集的数据全是错的。这时候/health应该返回503。

知识体系总览

我把这一章的核心逻辑画成了一张图，方便你理解Exporter在监控体系中的位置：

这张图把三个核心模块串起来了。Node Exporter是入门，自定义Exporter是进阶，注册与健康检查是落地。你想想看，如果只部署了Node Exporter但不会写自定义的，那遇到业务指标就只能干瞪眼。反过来，如果只会写Exporter但不会注册和健康检查，那数据也进不了Prometheus。

我个人建议的学习路径是：先玩熟Node Exporter，把系统指标搞明白；然后尝试用Python写一个简单的自定义Exporter，比如采集某个进程的CPU使用率；最后再把它注册到Prometheus里，加上健康检查。每一步都踩实了，后面遇到复杂场景才不会慌。

实战建议：你可以先在自己的开发机上部署Node Exporter，然后用Prometheus的graph页面看看CPU使用率曲线。等熟悉了指标格式，再试着用Python写一个采集当前在线用户数的Exporter。嗯，这样上手最快。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

4. Exporter实战：Node Exporter部署与指标采集、自定义Exporter开发（Python版）、Exporter注册与健康检查

4.1 Node Exporter部署与指标采集

4.2 自定义Exporter开发（Python版）

4.3 Exporter注册与健康检查

知识体系总览