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 pushgateway2.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 prometheus3. 数据推送实战
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.sh4.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中显示的数据与实际不符。
解决方案有几种：
- 为短生命周期任务设置显式的过期时间（通过脚本在任务结束时删除数据）
- 使用Pushgateway的
--metric.timetolive参数（如果版本支持） - 定期清理旧数据
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正常运行。
