大数据-218 Prometheus Node Exporter 1.8.2 + Pushgateway 1.10.0：下载、启动、接入与避坑

TL;DR

• 场景：Rocky Linux（类 CentOS）上给 Prometheus 增加主机指标与短任务指标采集。
• 结论：常驻服务用 node_exporter（pull），短任务/批处理用 pushgateway（push→pull）；Pushgateway 需处理“过期数据”和“单点”问题。
• 产出：node_exporter-1.8.2 与 pushgateway-1.10.0 的安装启动流程、Prometheus job 配置、常见故障定位修复卡。

官方网站

目前我们需要安装 exporter，我们的机器是 Rocky Linux，当然其他类 CentOS 也可以，我们需要用 node_exporter 来提供监控。 这里 Prometheus 已经提供好了：

https://prometheus.io/download/

页面需要往下滚动，找到对应的内容：

下载配置

cd /opt/software
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz

执行结果如下图所示：

解压配置

cd /opt/software
tar -zxvf node_exporter-1.8.2.linux-amd64.tar.gz
mv node_exporter-1.8.2.linux-amd64 ../servers/

部分内容如下图所示：

启动服务

 cd /opt/servers/node_exporter-1.8.2.linux-amd64
 ./node_exporter

执行结果如下图所示：

访问服务

我们访问刚才的 targets，可以看到 h121-wzk-icu 已经 UP 了：

PushGateway

基本介绍

Prometheus Pushgateway 是一个专门设计的中间组件，用于帮助 Prometheus 监控短期任务和批处理任务。在标准的 Prometheus 监控体系中，Prometheus 服务器采用主动拉取（pull）模型，通过定期从各被监控服务的 HTTP 端点（通常是/metrics）获取指标数据。这种模式适用于长期运行的守护进程和服务，如 Web 服务器、数据库等。

然而，对于一些特殊场景中的工作任务，这种拉取模型存在明显局限性：

1. 短期运行任务：例如一次性执行的脚本、定时任务（cron job）或命令行工具，这些任务可能在 Prometheus 下一次拉取周期前就已经完成并退出
2. 批处理作业：如 ETL 流程、数据分析任务等，它们运行时间可能从几秒到几小时不等
3. 无法直接暴露指标的服务：某些运行在受限环境中的任务可能无法开放 HTTP 端口供 Prometheus 拉取

Pushgateway 的工作机制是：

• 任务在启动时或运行期间将指标数据推送到 Pushgateway
• Pushgateway 会持久化存储这些指标
• Prometheus 服务器像监控常规目标一样，定期从 Pushgateway 拉取这些指标
• 指标会一直保留在 Pushgateway 中，直到被新数据覆盖或手动删除

典型的使用场景包括：

• 监控每日的数据备份作业（记录备份大小、耗时等）
• 跟踪批处理任务的执行状态（成功/失败次数）
• 收集 CI/CD 流水线的构建指标（构建时间、测试通过率）
• 记录一次性迁移任务的进度和性能数据

需要注意的是，Pushgateway 不是用来替代常规服务监控的方案，而是专门为那些不适合使用标准拉取模型的任务提供的补充方案。使用时应当注意指标的时效性和清理策略，避免 Pushgateway 成为单点故障或存储大量过期数据。

综上，PushGateway 是 Prometheus 生态中的一个重要的工具，使用它的主要原因是：

• Prometheus 采用 PULL 模式，可能由不再一个子网或者防火墙的原因，导致 Prometheus无法直接拉去各个 Target 数据
• 在监控业务数据的时候，需要将不同数据汇总，由 Prometheus 统一收集。

由于以上的原因，不得不使用 PushGateway，但在使用之前，有必要了解一下弊端：

• 将多个节点数据汇总到 PushGateway，如果它挂了，受到影响节点比多个 Target 大。
• Prometheus 拉去状态 UP 只针对 PushGateway，无法做到对每个节点都生效
• PushGateway 可以持久化推送给它的所有监控数据

Pushgateway 允许应用程序将数据主动推送到一个中介，之后 Prometheus 可以从中提取数据并存储到时间序列数据库中。这对短期的、瞬态的批处理任务特别有用，例如：

• 定期运行的批处理任务（如夜间作业）
• 编译和打包任务
• 自动化的备份任务
• 临时的数据库迁移脚本等

因此，即使你的监控已经下线，Prometheus 还会拉取旧的监控数据，需要手动清理 PushGateway 不要的数据。

工作流程

• 任务或批处理作业启动：任务或作业在运行过程中生成指标数据。
• 推送到 Pushgateway：在作业结束时，作业将指标推送到 Pushgateway。
• Prometheus 拉取数据：Prometheus 定期从 Pushgateway 拉取数据，记录在数据库中。
• 显示在监控系统：指标数据可以在 Grafana 等监控系统中进行展示和分析。

注意事项

• 持久性问题：Pushgateway 默认不持久化数据，重启后数据会丢失。可以使用磁盘持久化来保存指标。
• 数据过时问题：Pushgateway 适合单次批量数据推送，而不是长期的服务健康监测。如果批处理任务没有新的数据推送，Prometheus 也不会自动将旧数据删除，可能会导致监控面板显示过时数据。因此，推荐通过 push_time_seconds 标签来跟踪数据的推送时间。
• 避免泛用：Pushgateway 适用于短期任务，不建议用于长期任务监控，否则可能造成数据过时以及系统负担。

拓扑图

对应的拓扑图如下：

官方地址

https://prometheus.io/download/#pushgateway/

对应的内容如下图所示：

下载配置

cd /opt/software
wget https://github.com/prometheus/pushgateway/releases/download/v1.10.0/pushgateway-1.10.0.linux-amd64.tar.gz

执行结果如下图所示：

解压配置

cd /opt/software
tar -zxvf pushgateway-1.10.0.linux-amd64.tar.gz
mv pushgateway-1.10.0.linux-amd64 ../servers/

对应的内容如下所示：

配置服务

cd /opt/servers/pushgateway-1.10.0.linux-amd64

我们需要将 pushgateway 放置到 Prometheus 中：

cp pushgateway ../prometheus-2.53.2.linux-amd64/
chmod +x pushgateway

此外，我们还需要修改配置文件：

vim prometheus.yml

将 pushgateway 配置进去：（如果你之前跟着上文配置了， 这里就不需要了，已经配置过了）

  - job_name: "wzk-icu-grafana"
    static_configs:
      - targets: ["h121.wzk.icu:9091"]

对应的内容如下所示：

使用场景

• CI/CD 流程中的指标监控：Pushgateway 可以在 Jenkins、GitLab CI 等工具的管道中用于推送编译、测试、发布的状态数据。例如，在 Jenkins 流水线中，可以在构建阶段结束后推送构建耗时、单元测试通过率等指标；在部署阶段推送部署版本号、部署耗时等关键指标。这些数据可以帮助 DevOps 团队快速定位问题环节，优化持续交付流程。

• 自动化脚本和批处理任务：自动化作业完成后推送成功或失败状态，便于实时跟踪系统作业执行情况。典型的应用场景包括：

  • 每日定时执行的数据库备份脚本
  • 周期性运行的日志清理任务
  • 系统维护自动化脚本 通过为每个作业设置唯一的 job 标签，可以清晰区分不同任务的执行状态。作业完成后推送执行时间、返回码等指标，在 Grafana 中可直观展示任务执行情况。

• 批量数据处理作业：批处理工作如 Spark、Flink 等完成特定任务后，将关键的作业数据推送到 Pushgateway，确保执行的详细状态能够被监控到。具体可监控的指标包括：

  • 数据处理耗时
  • 处理记录数
  • 错误记录数
  • 资源使用情况 这些指标对于大数据团队评估作业性能、优化资源配置具有重要价值。

Pushgateway 是 Prometheus 中一个重要的扩展工具，特别适合短期作业和批处理任务的监控。它不适合长期监控使用（如 7x24 小时运行的服务），但在以下场景中具有显著优势：

1. 大规模数据处理场景：如 Hadoop、Spark 作业集群，可以确保每个作业的执行指标都被完整采集
2. DevOps 自动化场景：CI/CD 流水线、自动化运维任务的状态监控
3. 定时任务场景：cron 作业、计划任务的执行跟踪

通过 Pushgateway，可以确保 Prometheus 捕获到所有临时性任务的数据，显著提升监控系统的覆盖率和有效性。建议配合 Grafana 仪表盘使用，可以直观展示各类短期作业的执行情况和趋势分析。

错误速查

症状	根因	定位	修复
Prometheus Targets 显示 DOWN（node_exporter）	进程没起来/已退出	机器上看进程与监听端口（确认 exporter 是否在跑、端口是否监听）	重新启动 node_exporter；建议改为 systemd 托管避免 SSH 断开后退出
Targets DOWN 但本机能 curl 到 /metrics	Prometheus 到目标网络不通（路由/ACL/防火墙）	Prometheus 机器侧对目标 ip:port 连通性检查	放通端口；同网段/安全组策略调整；必要时考虑反代或调整网络拓扑
Targets 反复 UP/DOWN	端口冲突或进程不稳定（OOM/被杀）	查看启动日志与系统日志；检查端口是否被占用	换端口或停止冲突服务；降低资源压力；用 systemd 设置 Restart 策略
node_exporter 启动失败：permission denied / cannot execute	文件没执行权限/目录权限/下载损坏	ls -l 看权限；校验文件大小与解压结果	chmod +x node_exporter；重新下载解压；确保在正确目录执行
pushgateway targets UP，但看不到预期作业指标	没有任何作业 push 指标到 pushgateway	访问 Pushgateway 的 /metrics 看是否存在目标 job/instance label	在作业结束时 push 指标；确保 job/instance 标签一致且唯一
面板长期显示旧数据（Pushgateway）	Pushgateway 指标不会自动过期删除	观察指标的 push 时间（如推送时间相关标签/指标）与最近一次推送	建立清理机制（删除旧 job/instance）；推送时带时间指标用于判别新鲜度
Prometheus 只看到 Pushgateway 的 UP，无法代表每个节点	UP 语义只覆盖 Pushgateway 服务本身	对比“Pushgateway target 状态”与“作业指标是否更新”	用作业侧自定义成功/失败指标 + 推送时间做健康判定；不要用 Pushgateway 替代常驻服务监控
修改 prometheus.yml 后不生效	Prometheus 未 reload 配置/配置写错	Prometheus 日志与配置校验；检查缩进与 job_name/targets 格式	修正 YAML；执行 Prometheus reload（按你的部署方式触发）并确认生效
Pushgateway 重启后指标丢失	未启用持久化（默认不持久化）	重启前后对比 /metrics 内容	按需启用磁盘持久化；同时评估是否应将“短任务指标”写入更合适的存储链路

其他系列

🚀 AI篇持续更新中（长期更新）

AI炼丹日志-29 - 字节跳动 DeerFlow 深度研究框斜体样式架 私有部署 测试上手 架构研究，持续打造实用AI工具指南！ AI研究-132 Java 生态前沿 2025：Spring、Quarkus、GraalVM、CRaC 与云原生落地

💻 Java篇持续更新中（长期更新）

Java-218 RocketMQ Java API 实战：同步/异步 Producer 与 Pull/Push Consumer MyBatis 已完结，Spring 已完结，Nginx已完结，Tomcat已完结，分布式服务已完结，Dubbo已完结，MySQL已完结，MongoDB已完结，Neo4j已完结，FastDFS 已完结，OSS已完结，GuavaCache已完结，EVCache已完结，RabbitMQ已完结，RocketMQ正在更新... 深入浅出助你打牢基础！

📊 大数据板块已完成多项干货更新（300篇）：

包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！ 大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT案例 详解