Prometheus自定义脚本监控实战：从Pushgateway到业务指标采集

1. 为什么需要Pushgateway？

在Prometheus的监控体系中，大部分场景都是通过Pull模式来采集数据的。Prometheus服务器会定期从配置好的Exporter中拉取指标数据。这种设计简单高效，但也存在一些局限性。比如，当我们需要监控一些短生命周期的任务或者批处理作业时，这些任务可能还没等到Prometheus来拉取数据就已经结束了。这时候，Pushgateway就派上用场了。

Pushgateway充当了一个中间缓存层的角色。短生命周期的任务可以将自己的监控指标推送到Pushgateway，然后由Prometheus从Pushgateway拉取这些数据。这样既保持了Prometheus整体的Pull架构，又解决了临时性任务监控的问题。

我在实际项目中就遇到过这样的情况：有一个每天凌晨运行的批处理任务，运行时间大概只有几分钟。最初我们尝试直接让Prometheus来拉取数据，但发现经常抓不到数据。后来引入Pushgateway后，这个问题就迎刃而解了。

2. Pushgateway的部署与配置

2.1 安装Pushgateway

Pushgateway是用Go语言编写的，安装非常简单。我们可以直接从Prometheus官网下载预编译好的二进制包：

wget https://github.com/prometheus/pushgateway/releases/download/v1.6.2/pushgateway-1.6.2.linux-amd64.tar.gz tar xvf pushgateway-1.6.2.linux-amd64.tar.gz cd pushgateway-1.6.2.linux-amd64

为了便于管理，我习惯将Pushgateway配置为系统服务。创建一个systemd服务文件：

cat > /etc/systemd/system/pushgateway.service <<EOF [Unit] Description=Prometheus Pushgateway After=network.target [Service] User=prometheus Group=prometheus ExecStart=/usr/local/bin/pushgateway \ --persistence.file=/var/lib/pushgateway/pushgateway.data \ --persistence.interval=5m Restart=on-failure [Install] WantedBy=multi-user.target EOF

这里有几个关键参数需要注意：

• --persistence.file：指定数据持久化文件路径
• --persistence.interval：数据持久化间隔时间

创建必要的目录并设置权限：

mkdir -p /var/lib/pushgateway chown -R prometheus:prometheus /var/lib/pushgateway

然后启动服务并设置开机自启：

systemctl daemon-reload systemctl start pushgateway systemctl enable pushgateway

2.2 Prometheus配置

要让Prometheus从Pushgateway拉取数据，需要在Prometheus的配置文件中添加对应的job配置。编辑prometheus.yml文件，添加如下内容：

- job_name: 'pushgateway' honor_labels: true scrape_interval: 30s static_configs: - targets: ['pushgateway-server:9091'] labels: instance: pushgateway

这里有个很重要的参数honor_labels需要特别注意。当设置为true时，Prometheus会优先使用Pushgateway传过来的标签，否则会覆盖这些标签。在大多数情况下，我们都希望保留推送时的标签信息，所以建议设置为true。

配置完成后，重新加载Prometheus配置：

systemctl reload prometheus

3. 数据推送实战

3.1 基础推送操作

最简单的推送方式是使用curl命令直接发送指标数据。比如我们要推送一个名为"example_metric"的指标，值为3.14：

echo "example_metric 3.14" | curl --data-binary @- http://pushgateway:9091/metrics/job/example_job

这条命令会将指标推送到Pushgateway，并关联到一个名为"example_job"的job。在Prometheus中查询时，这个指标会有job="example_job"的标签。

如果需要推送更复杂的指标，可以这样操作：

cat <<EOF | curl --data-binary @- http://pushgateway:9091/metrics/job/some_job/instance/some_instance # TYPE some_metric counter some_metric{label="val1"} 42 # TYPE another_metric gauge # HELP another_metric Just an example. another_metric 2398.283 EOF

这里我们推送了两个指标，并指定了它们的类型（TYPE）和帮助信息（HELP）。同时，我们还为这个推送组指定了instance标签。

3.2 数据删除操作

有时候我们需要删除Pushgateway中的旧数据。Pushgateway提供了几种删除方式：

删除特定instance的数据：

curl -X DELETE http://pushgateway:9091/metrics/job/some_job/instance/some_instance

删除整个job的数据：

curl -X DELETE http://pushgateway:9091/metrics/job/some_job

如果要删除所有数据（需要启动时启用admin API）：

curl -X PUT http://pushgateway:9091/api/v1/admin/wipe

注意最后一个操作需要Pushgateway启动时添加--web.enable-admin-api参数。

4. 实战：Shell和Python脚本集成

4.1 Shell脚本示例

在实际项目中，我们通常会用脚本来自动化指标的采集和推送。下面是一个实用的Shell脚本示例，它会收集系统信息并推送到Pushgateway：

#!/bin/bash # 定义Pushgateway地址和job名称 PUSHGATEWAY="http://pushgateway:9091" JOB_NAME="system_metrics" INSTANCE=$(hostname) # 收集系统指标 CPU_LOAD=$(cat /proc/loadavg | awk '{print $1}') MEM_FREE=$(free -m | awk '/Mem:/ {print $4}') DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}' | tr -d '%') # 推送指标到Pushgateway cat <<EOF | curl --data-binary @- ${PUSHGATEWAY}/metrics/job/${JOB_NAME}/instance/${INSTANCE} # TYPE cpu_load gauge cpu_load ${CPU_LOAD} # TYPE mem_free gauge mem_free ${MEM_FREE} # TYPE disk_usage gauge disk_usage ${DISK_USAGE} EOF

这个脚本会收集系统的CPU负载、可用内存和根分区使用率，然后推送到Pushgateway。我们可以把这个脚本放到crontab中定期执行：

*/5 * * * * /path/to/script.sh

4.2 Python脚本示例

对于更复杂的监控需求，Python可能是更好的选择。Python有官方的prometheus_client库，使用起来非常方便。首先安装客户端库：

pip install prometheus_client

下面是一个Python脚本示例，它会模拟监控一个应用的队列长度和处理延迟：

#!/usr/bin/env python from prometheus_client import CollectorRegistry, Gauge, push_to_gateway import random import time import socket # 配置信息 GATEWAY = 'http://pushgateway:9091' JOB_NAME = 'app_metrics' INSTANCE = socket.gethostname() # 创建注册表 registry = CollectorRegistry() # 定义指标 queue_size = Gauge('app_queue_size', 'Current size of processing queue', registry=registry) processing_time = Gauge('app_processing_time', 'Time to process an item (ms)', ['item_type'], registry=registry) def collect_metrics(): # 模拟获取队列长度 queue_size.set(random.randint(0, 100)) # 模拟处理不同类型的项目耗时 for item_type in ['image', 'video', 'text']: processing_time.labels(item_type=item_type).set(random.randint(10, 500)) # 推送指标 push_to_gateway(GATEWAY, job=JOB_NAME, registry=registry) if __name__ == '__main__': while True: collect_metrics() time.sleep(60) # 每分钟推送一次

这个脚本定义了两个指标：一个是简单的队列长度，另一个是带标签的处理时间（区分不同类型的处理项）。它会每分钟收集一次数据并推送到Pushgateway。

5. 常见问题与最佳实践

5.1 数据过期问题

Pushgateway的一个常见问题是数据不会自动过期。即使推送数据的进程已经终止，Pushgateway仍然会保留这些数据，直到被显式删除。这可能导致Prometheus中显示的数据与实际不符。

解决方案有几种：

1. 为短生命周期任务设置显式的过期时间（通过脚本在任务结束时删除数据）
2. 使用Pushgateway的--metric.timetolive参数（如果版本支持）
3. 定期清理旧数据

5.2 标签设计

在设计指标标签时，需要注意以下几点：

• 避免使用高基数的标签（如用户ID、会话ID等），这会导致Prometheus存储压力剧增
• 为job和instance使用有意义的名称，便于后续查询和告警
• 保持标签命名的一致性，遵循Prometheus的命名规范

5.3 性能考量

当监控规模较大时，Pushgateway可能成为性能瓶颈。以下是一些优化建议：

• 为Pushgateway配置足够的资源（特别是内存）
• 考虑使用多个Pushgateway实例并做负载均衡
• 适当调整Prometheus的抓取间隔，避免过于频繁
• 对于高频率更新的指标，考虑在应用端做适当聚合

5.4 监控Pushgateway自身

别忘了监控Pushgateway本身的健康状况。Prometheus自带的Pushgateway exporter会暴露一些有用的指标，比如：

• pushgateway_http_requests_total：请求计数
• pushgateway_http_request_duration_seconds：请求延迟
• pushgateway_build_info：版本信息

可以基于这些指标设置告警，确保Pushgateway正常运行。