【可能是全中文网最全】pushgateway入门笔记

参考链接： 官方文档中文类官方文档 prometheus官方指南博客

一 概念

Pushgateway 是一种中介服务，它允许从无法抓取的作业中推送指标。

其为了允许临时和批处理作业向 Prometheus 公开其指标。由于这些类型的job可能存在的时间不够长而无法被抓取，因此他们可以将指标推送到 Pushgateway。然后 Pushgateway 将这些指标公开给 Prometheus。

通常，Pushgateway 唯一有效的用例是用于捕获服务级批处理作业的结果, “服务级别”批处理作业是与特定机器或作业实例在语义上不相关的作业。此类作业的指标不应包含机器或实例标签，以将特定机器或实例的生命周期与推送的指标分离。这减轻了在 Pushgateway 中管理陈旧指标的负担。

优缺点

使用它的原因主要是：

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

缺点有：

• 将多个节点数据汇总到 pushgateway, 如果 pushgateway 挂了，受影响比多个 target 大。
• Prometheus 拉取状态 up 只针对 pushgateway, 无法做到对每个节点有效。
• Pushgateway 可以持久化推送给它的所有监控数据。因此，即使你的监控已经下线，prometheus 还会拉取到旧的监控数据，需要手动清理 pushgateway 不要的数据。Pushgateway 作为指标缓存的生命周期与将指标推送给它的进程的生命周期根本上是分开的。将此与 Prometheus 通常的pull式监控进行对比：当一个实例消失（有意或无意）时，它的指标将自动随之消失。使用 Pushgateway 时，情况并非如此，您现在必须手动删除任何过时的指标或自己自动执行此生命周期的同步。

二 配置与使用

1 安装pushgateway

可以直接访问官网下载其二进制文件： https://github.com/prometheus/pushgateway/releases，下面演示以最新版本的1.4.3为例：

最简单的执行，可以直接解压并运行：

./pushgateway

默认监听的是9091端口。可以通过以下配置进行更改：

usage: pushgateway [<flags>]
Flags:
      --web.listen-address=":9091"  		监听Web界面，API和遥测的地址。
      --web.telemetry-path="/metrics"  		公开metrics的路径。
      --web.external-url=        			可从外部访问Pushgateway的URL.
      --web.route-prefix=""      			Web端点内部路由的前缀。 默认为--web.external-url的路径.
      --persistence.file=""      			归档以保留metrics。 如果为空，则metrics仅保留在内存中.
      --persistence.interval=5m  			写入持久性文件的最小间隔。
      --log.level="info"         			仅记录具有给定严重性或更高严重性的消息。 有效级别：[debug, info, warn, error, fatal]
      --log.format="logger:stderr"  		设置日志目标和格式。 示例：“ logger：syslog？appname = bob＆local = 7”或“ logger：stdout？json = true”
      --version                  			显示应用程序版本。

本机测试改为9095端口（不知道为啥9091的web界面访问不了），将pushgateway移到/usr/local/bin下，启动命令为

/usr/local/bin/pushgateway --web.listen-address=:9095

此时访问网页 ip:9095 即可看到前端页面

访问 ip:9095/metrics，可以看到其指标页面

2 接入prometheus

更改prometheus配置文件，增加

  - job_name: 'pushgateway_name' 
    scrape_interval: 30s 
    honor_labels: true  #加上此配置，exporter节点上传数据中的一些标签将不会被pushgateway节点的相同标签覆盖 
    static_configs: 
        - targets: ["127.0.0.1:9095"] 
          labels: 
              instance: pushgateway_instance               
# pushgateway 中的数据我们通常按照 job 和 instance 分组分类，所以这两个参数不可缺少。

重启Prometheus服务，或进行热加载

curl -X POST http://127.0.0.1:9090/-/reload

此时访问prometheus界面，即可看到targets中出现了 pushgateway相关信息，其中 instance 与 job 都是在配置文件中规定的。job必填，instance没有就为 “” 空字符串。

3 推送数据

推送的指标按组进行管理，由任意数量标签的分组键标识，其中第一个必须是job标签。

curl发送形式说明

–data-binary 与-d, --data类似，如果以@开头，则后面必须跟着文件名，并且文件中的换行符，回车符会保留，也不会做将要发送的数据写入文件“名字”，作用是将文件中的数据发送到指定地方

示例1 ：简单推送

单个样本推入由 标识的组中 {job="example_job"}：

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

可以看到有个 UNTYPED 。因为没有提供了类型信息,所以some_metric将类型的无类型。因为我们只写了job的名称，所以可以看到instance那一列为 空字符串。

示例2：加lable

echo "example_metric 3.14" | curl --data-binary @- http://127.0.0.1:9095/metrics/job/example_job/lable1/example_lable

示例3：复杂推送

cat <<EOF | curl --data-binary @- http://127.0.0.1:9095/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

示例4： 删除

删除由标识的组中的所有指标 ，{job="some_job",instance="some_instance"}

curl -X DELETE http://127.0.0.1:9095/metrics/job/some_job/instance/some_instance

删除除由 标识的组中的所有指标{job="some_job"}（请注意，这不包括  {job="some_job",instance="some_instance"}上一个示例中组中的指标，即使这些指标具有相同的作业标签）

curl -X DELETE http://127.0.0.1:9095/metrics/job/some_job

删除所有组的所有指标

curl -X PUT http://127.0.0.1:9095/api/v1/admin/wipe #需要通过命令行标志启用管理 API --web.enable-admin-api

三 分析

1 prometheus配置问题

Pushgateway 必须配置为 Prometheus 抓取的目标，使用其中一种常用方法。但是，您应该始终honor_labels: true 在抓取配置中进行设置

配置前后，在Prometheus抓取数据的格式如下

echo "example_metric 3.15" | curl --data-binary @- http://127.0.0.1:9095/metrics/job/example_job/instance/i123

example_metric{exported_instance="i123", exported_job="example_job", instance="pushgateway_instance", job="pushgateway_name"} 3.15 # 配置前 example_metric{instance="i123", job="example_job"}

即如果不配置的话, job跟instance都是默认的Pushgateway的属性，而不是推送主体的属性.

pushgateway 中的数据我们通常按照 job 和 instance 分组分类，所以这两个参数不可缺少。因为 Prometheus 配置 pushgateway 的时候，也会指定 job 和 instance, 但是它只表示 pushgateway 实例，不能真正表达收集数据的含义。所以在 prometheus 中配置 pushgateway 的时候，需要添加 honor_labels: true 参数，从而避免收集数据本身的 job 和 instance 被覆盖。

2 时间戳问题

Prometheus 每个样本只知道一个时间戳，无法区分“推送时间”和“抓取时间”。没有任何用例可以附加不同的时间戳，并且许多用户试图错误地这样做（尽管没有客户端库支持），Pushgateway 拒绝任何带有时间戳的推送。如果您在时间t1

推送指标，您可能会相信 Prometheus 会使用相同的时间戳 t1抓取它们。相反，Prometheus 作为时间戳附加的是它抓取 Pushgateway 的时间。

3 数据类型问题

所有指标必须保持一致：同名的指标必须具有相同的类型，即使它们被推送到不同的组，并且不能重复，即具有相同名称和完全相同的标签对的指标。会导致不一致的推送被拒绝，状态码为 400。

 text format parsing error in line 1: expected float as value, got "abc"

4 数据有效性

pushgateway并不是将Prometheus的pull改成了push，它只是允许用户向他推送指标信息并记录。

而Prometheus每次从pushgateway拉取的数据是最后一次push上来的数据，并不是期间用户推送上来的所有数据。所以设置推送时间与Prometheus拉取的时间相同(

如果客户端一直没有推送新的指标到pushgateway，那么Prometheus将始终拉取最后push上来的数据。

5 推送链接

默认 URL 地址为：http://:9091/metrics/job/{/<LABEL_NAME>/<LABEL_VALUE>}

其中job是必填项，为 job 标签值，后边可以跟任意数量的标签对，一般我们会添加一个 instance/ 实例名称标签，来方便区分各个指标。