使用场景

在prometheus server的角度看，抓取数据时server主动发起的，exporter必须要满足随时可以触发搜集数据。

但有些场景，比如执行调度任务脚本，只会在调度任务执行过程中产生数据。数据生成是瞬时性的，无法满足在server抓取的时候才去生成数据。

因此这种瞬时生成的数据就需要有一个中转站临时存放，当prometheus发起抓取数据时，再从中转站获取到数据，这个中转站就是pushgateway。

架构图

在原来的exporter的架构图上稍加改动，pushgatway的基础架构如下：

pushgateway实现进程级别监控 pushgateway 性能_数据

说明：

1、pushgateway就是个数据中转站。提供API，支持数据生产者随时将数据推送过来。

2、pushgateway提供exporter功能，在promethus抓取数据时，将自己保存的数据反馈给server端。

安装

安装就不说明了，跟prometheus还有其他exporter一样，二进制版本，解压即用。

启动成功后，也可以WEB访问<IP>:<Port>打开如下的pushgateway的一个WEB UI.

pushgateway实现进程级别监控 pushgateway 性能_推送_02

WEB UI提供了基本的查看和删除组的功能。

数据组织方式：

1、所有数据采用分组管理（Group），group由job name和一组描述job的标签唯一标识，job name在推送数据的URL中定义，描述job的标签可以有0个或者多个。

2、删除数据也是以组为最基本的单元。

3、所有的metric都放在/metrics这个endpoint下，所以，不同组的metric_name不允许冲突。

4、每个组都有push_time_seconds和push_failure_time_seconds两个metric，记录了push最后发生的时间戳。

可以使用push_failure_time_seconds>push_time_seconds表达式来判断推送是否存在失败的情况。

5、数据覆盖规则，数据覆盖的最小粒度为group下的metric单元。每次推送任务，若推送Group下metric name已存在，则会清空原metric下的所有数据，重新进行插入。若该Group下还有其他metric，则其他metric保持不变。因此，push_time_seconds这些时间是标识Group的最后push时间，而非所有metric的push时间。

基本使用

pushgateway也是跟prometheus一样，只提供了HTTP API。

所以从使用上，也是需要用curl命令或者其他网络工具来实现。这里以curl为例做下介绍。

**推送数据 **

推送一个group定义为{job=“some_job”}的数据

echo "some_metric 3.14" | curl --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job

推送一个group定义为{job=“some_job”,instance=“some_instance”}的数据

cat <<EOF | curl --data-binary @- http://pushgateway.example.org: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

说明：

  1. 推送路径的URL部分定义为
/metrics/job/<JOB_NAME>{/<LABEL_NAME>/<LABEL_VALUE>}

其中job是必须参数，label_name部分是可选的，URL中的job和label组合唯一标识pushgateway中的Group。

  1. 在推送的数据部分，格式定义如下：
## TYPE metric_name type
metric_name{lable_name="label_value",...}  value

其中TYPE注释部分非必须，metric_name可以有0个或者多个标签，value需为浮点数，这些都同promethues。

  1. URL中的label定义优先级高于数据部分的label定义，如发生冲突，URL中的会覆盖数据部分的。
  2. 从数据的最终态看，URL中的label跟数据部分的label没有区别，都会聚合到metric的定义部分。
  3. URL中的label部分可以理解为定义和描述job的，比如常用instance标签，标识数据主机来源。
  4. 数据部分的label最好定义为描述metric的。和URL中的定义还是要区分使用。主要原因是，在维护分组数据的时候（DELETE）会更方便。

删除数据

删除group定义为{job=“some_job”}下的所有数据

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

删除所有group下的所有metrics(启动pushgateway时需加上命令行参数–web.enable-admin-api)

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

说明：

  1. 删除数据是以Group为单位的，Group由job name和URL中的label唯一标识。
  2. 举例中删除{job=“some_job”}数据的语句并不会删除{job=“some_job”,instance=“some_instance”}的数据。因为属于不同的Group。如需要删除{job=“some_job”,instance=“some_instance”}下的数据，需要使用
curl -X DELETE http://pushgateway.example.org:9091/metrics/job/some_job/instance/some_instance
  1. 这里删除数据是指删除pushgateway中的数据，跟promethues没有关系。

API

上文只简单介绍了关于推送和删除的API用法，更多API查看官方文档。比如查询和健康检查等。

https://github.com/prometheus/pushgateway

和Prometheus的关系

从上面的架构图已经知道，pushgateway对于prometheus而言就是一个exporter。

只不过pushgateway中的数据不是实时触发搜集的，而是不同的数据来源推送到pushgateway临时存放的，但promethues并不知道这些，也不关心这些。

数据生产者向pushgateway推数据和prometheus向pushgateway拉数据是两个完全独立的过程，因此若推送比较频繁，比如10s中推一次，而prometheus30s拉一次数据，则可能存在部分数据不会存入prometheus。

时间戳

假如数据生产者推送数据的时间是t1，而prometheus拉取数据的时间为t2，则在prometheus落数据的时候，时间戳部分是t2，而非真正的数据生产时间。所以若需要准确的数据生产时间，最好将时间字段定义为一个metric进行单独维护。

job和instance

pushgateway中的数据一定有job标签，prometheus抓取pushgateway数据时也会为数据自动加上job和instance标签，因为标签冲突，prometheus会将原数据的job标签改写成exported_job，若存在instance标签则会被改写成exported_instance标签。

若需要保留原job和instance标签定义，需要在prometheus段定义job时使用honor_labels属性：该属性true就是以抓取数据中的标签为准 ，false就会重新命名抓取数据中的标签为“exported”形式，然后添加配置文件中的标签