使用 Prometheus Pushgateway 推送监控指标
作者 |阳明
来源 | k8s技术圈(ID:kube100)
我们知道 Prometheus 采用的 pull 模式,但是某些网络场景下面(比如不在一个子网或者防火墙),Prometheus 无法直接拉取监控指标数据,这个时候我们可能就需要一种能够主动 push 的模式了。而 Pushgateway 就是 Prometheus 生态中来解决这个问题的一个工具。
但是 Pushgateway 也不是万能的,其本身也存在一些弊端:
- 将多个节点数据汇总到 pushgateway, 如果 pushgateway 挂了,受影响范围更大
- Prometheus 拉取状态 up 只针对 pushgateway, 无法做到对每个目标有效
由于 Pushgateway 可以持久化推送给它的所有监控数据,所以即使你的监控已经下线,Prometheus 还会拉取到旧的监控数据,需要手动清理 Pushgateway 不要的数据。
Pushgateway 的存在是为了允许临时和批处理作业向 Prometheus 暴露其指标。由于这些类型的任务可能存在的时间不够长而无法被抓取,因此他们可以将指标推送到 Pushgateway,然后 Pushgateway 将这些指标暴露给 Prometheus。有一点我们需要明白的是 Pushgateway 不是将指标主动 push 给 Prometheus,而是通过脚本将指标数据主动 push 给 Pushgateway 后,Prometheus 仍然通过 pull 模式去抓取指标。
前面我们也介绍过 node-exporter 中的 textfile 收集器也可以用来采集指标,似乎和 Pushgateway 比较相似,这二者有什么区别吗?textfile 通常是用于节点级别的指标,而 Pushgateway 是用于服务级别的指标。
安装
同样要安装 Pushgateway 也非常简单,直接从 Release 页面 下载适用于你平台的二进制版本并解压即可使用。如果你想从源码自行编译,可以在代码根目录下面直接执行 make 命令即可编译。
直接执行 Pushgateway 二进制文件即可启动了,要更改监听的地址,可以通过 --web.listen-address 标志(例如0.0.0.0:9091或:9091)指定。默认情况下 Pushgateway 不保留指标。但是 --persistence.file 标志允许我们指定一个文件,将推送的指标保存在其中,这样当 Pushgateway 重新启动后指标仍然存在。
此外当然我们也可以直接使用 Docker 镜像来进行启动:
docker run -d -p 9091:9091 prom/pushgateway
同样我们这里还是将 Pushgateway 部署在 Kubernetes 集群中,对应的资源清单文件如下所示:
# pushgateway.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pushgateway-data
namespace: kube-mon
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
storageClassName: local-path
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: pushgateway
namespace: kube-mon
labels:
app: pushgateway
spec:
selector:
matchLabels:
app: pushgateway
template:
metadata:
labels:
app: pushgateway
spec:
volumes:
- name: data
persistentVolumeClaim:
claimName: pushgateway-data
containers:
- name: pushgateway
image: prom/pushgateway:v1.4.3
imagePullPolicy: IfNotPresent
args:
- "--persistence.file=/data"
ports:
- containerPort: 9091
name: http
volumeMounts:
- mountPath: "/data"
name: data
resources:
requests:
cpu: 100m
memory: 500Mi
limits:
cpu: 100m
memory: 500Mi
---
apiVersion: v1
kind: Service
metadata:
name: pushgateway
namespace: kube-mon
labels:
app: pushgateway
spec:
selector:
app: pushgateway
type: NodePort
ports:
- name: http
port: 9091
targetPort: http
这里我们 --persistence.file 指定了持久化的文件,然后通过一个 Service 来暴露了服务,直接应用上面的资源清单文件即可:
☸ ➜ kubectl apply -f https://p8s.io/docs/pushgateway/manifests/pushgateway.yaml
☸ ➜ kubectl get pods -n kube-mon -l app=pushgateway
NAME READY STATUS RESTARTS AGE
pushgateway-7684cbb67d-6mbjn 1/1 Running 0 99s
☸ ➜ kubectl get svc -n kube-mon -l app=pushgateway
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
pushgateway NodePort 10.106.136.207 <none> 9091:30893/TCP 107s
默认情况下 Pushgateway 会提供一个简单的 Web 页面,可以查看当前具有哪些指标。基本使用
Pushgateway 的数据推送支持两种方式,Prometheus Client SDK 推送和 API 推送。
Client SDK 推送
Prometheus 本身提供了支持多种语言的 SDK,可通过 SDK 的方式,生成相关的数据,并推送到 Pushgateway,当然这种方式需要客户端代码支持,这也是官方推荐的方案。目前的 SDK 覆盖语言有官方的:
- Go
- Java or Scala
- Python
- Ruby
也有许多第三方的库,详情可参见此链接:https://prometheus.io/docs/instrumenting/clientlibs/
这里我们以 Python 为例进行说明。
首先安装 Prometheus 的 Python SDK:
☸ ➜ pip install prometheus-client
然后创建一个名为 app.py 的文件,内容如下所示:
from prometheus_client import CollectorRegistry, Counter, Gauge, push_to_gateway
registry = CollectorRegistry()
g = Gauge('container_memory', 'Container memory data', ['node'], registry=registry)
g.labels(node='node1').inc() # +1
g.labels(node='node2').dec(10) # -10
g.labels(node='node3').set(4.2) # 4.2
c = Counter('my_requests_total', 'HTTP requests total', ['method', 'endpoint'], registry=registry)
c.labels(method='get', endpoint='/').inc()
c.labels(method='post', endpoint='/submit').inc()
push_to_gateway('192.168.0.106:30893', job='batchA', registry=registry)
首先引入了 Prometheus 的 Python SDK,然后创建了一个 CollectorRegistry 实例,分别创建了一个 Gauge 和 Counter 类型的指标,其中第一个参数为指标名称,第二个参数为指标的注释信息,第三个参数为相关的标签,然后为不同的标签值设置不同的指标值,最后通过 push_to_gateway 函数将指标数据发送到指定的 Pushgateway 服务上去。
直接执行上面的 Python 文件即可将数据推送到 Pushgateway:
☸ ➜ python app.py
API 推送
此外使用 Prometheus 文本协议,推送指标也是非常简单的,无需提供单独的 CLI。只需使用 curl 之类的命令行工具即可。
不过需要注意,在文本协议中,每一行都必须以换行符结尾('LF' 或 '\n'),以其他方式结束一行,例如使用 'CR'('\r')、'CRLF'('\r\n')或只是数据包的结尾,将导致协议错误。
推送的指标按组进行管理,由任意数量的标签组成的分组键识别,其中第一个必须是 job 标签。
比如我们现在将单个样本推送到由 {job="some_job"} 标识的组中:
☸ ➜ echo "some_metric 3.14" | curl --data-binary @- http://192.168.0.106:30893/metrics/job/some_job
需要注意由于没有提供类型信息, 所以这里的 some_metric 将是 UNTYPED 无类型的。
上面的命令执行完后我们可以重新前往 Pushgateway 的 Web 页面查看。可以看到页面中就出现了上面我们推送的 some_metric 这个指标,而且位于 job="some_job" 这个分组下面。
接下来我们再推送一些相对复杂的指标,推到 {job="some_job",instance="some_instance"} 标识的分组中去,继续之前记得将上面的分组删除,然后执行下面的命令:
☸ ➜ cat <<EOF | curl --data-binary @- http://192.168.0.106:30893/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
该命令会将指标推送到 {job="some_job",instance="some_instance"} 标识的分组中去,要注意指标内容中是如何提供类型信息和帮助信息的,这里我们的指标是都具有类型了。在 Web 界面中就可以看到上面推送的两个指标了,一个是 COUNTER 类型,一个是 GAUGE 类型。
如果你想删除某个分组下面的所有指标,我们也可以通过 curl 命令来实现。比如删除由 {job="some_job",instance="some_instance"} 标识的分组中的所有指标,可以通过下面的命令来实现:
☸ ➜ curl -X DELETE http://192.168.0.106:30893/metrics/job/some_job/instance/some_instance
这里需要注意的是删除是根据分组标识进行删除的,比如我们要删除由 {job="some_job"} 标识的分组中的所有指标,那么可以用下面的命令来实现:
☸ ➜ curl -X DELETE http://192.168.0.106:30893/metrics/job/some_job
但是需要注意这里是不包括上面示例 {job="some_job",instance="some_instance"} 分组中的指标的,即使这些指标具有相同的 job 标签,这点非常重要。
如果你想删除所有组中的所有指标,可以使用下面的命令来实现:
☸ ➜ curl -X PUT http://192.168.0.106:30893/api/v1/admin/wipe
但是需要注意需要通过 Pushgateway 的命令行标志 --web.enable-admin-api 来启用管理 API。
抓取指标
现在我们需要将 Pushgateway 的指标配置到 Prometheus 中去,让 Prometheus 去主动抓取 Pushgateway 的指标数据,我们当然也可以使用服务发现的方式,这里我们单独为 Pushgateway 创建一个抓取任务,在 Prometheus 中添加如下所示的抓取配置:
scrape_configs:
- job_name: "pushgateway"
kubernetes_sd_configs:
- role: endpoints
relabel_configs:
- source_labels:
[__meta_kubernetes_namespace, __meta_kubernetes_service_name]
action: keep
regex: kube-mon;pushgateway
# 省略其他配置......
我们这里同样采用基于 endpoints 的自动发现的方式来进行配置,去匹配 kube-mon 这个命名空间下名为 pushgateway 的服务即可。正常更新上面的配置后 Prometheus 就会自动去发现 Pushgateway 这个服务了。现在我们重新推送下面的指标:
☸ ➜ cat <<EOF | curl --data-binary @- http://192.168.0.106:30893/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
推送完成后我们就可以在 Prometheus 中去查询 some_metric 和 another_metric 这两个指标了。Prometheus 会给每个抓取的指标附加一个 job 和 instance 的标签,job 标签来自 scrape 配置,我们这里抓取 Pushgateway 的 job 标签为 job="pushgateway",instance 标签的值会自动设置为抓取目标的主机和端口,所以所有从 Pushgateway 抓取的指标都会有 Pushgateway 的主机和端口作为 instance 标签,但是这可能会和你附加推送到 Pushgateway 指标上的 job 和 instance 标签冲突,这个时候 Prometheus 会将这些标签重命名为 exported_job 和 exported_instance。
但是,在抓取 Pushgateway 时,通常不希望出现这种行为。更多的时候你可能更希望保留推送到 Pushgateway 的指标的 job 和 instance 标签,这个时候我们只需要在 Pushgateway 的抓取配置中设置 honor_labels: true 即可,我们重新更新 Prometheus 的配置:
scrape_configs:
- job_name: "pushgateway"
honor_labels: true
kubernetes_sd_configs:
- role: endpoints
relabel_configs:
- source_labels:
[__meta_kubernetes_namespace, __meta_kubernetes_service_name]
action: keep
regex: kube-mon;pushgateway
# 省略其他配置......
上面抓取 Pushgateway 的任务中我们新增了一个 honor_labels: true 的配置,更新后我们重新去查询推送到 Pushgateway 中的两个指标。可以看到 job 和 instance 这两个标签变成了我们推送到 Pushgateway 中的标签值了,这个可能更符合我们的预期。
另外需要注意的是 Pushgateway 不提供任何强一致性保证,没有高可用的方案,它可以做的最好的事情就是将每个指定时间段的指标保存到磁盘了,总之不到万不得已的情况下最好别用 Pushgateway。