【Prometheus的Pushgateways】一切需要了解的内容尽在此处!

首先
MetricFire的Prometheus实例会在所有scrape_interval周期内对目标进行刮取。但是,如果一些应用程序不能持续时间足够长以被Prometheus检测和刮取怎么办呢?例如,使用Kubernetes服务发现,并且Pod的生存时间不足以使其被捕获怎么办?在这种情况下,由于无法检测或删除Prometheus的所有目标,Prometheus的常规拉取模型将不再适用,因此需要某种解决方案。
这是Prometheus Pushgateway发挥作用的时候了。当把短暂的脚本所生成的度量数据发送到Pushgateway上后,最终这些度量数据将被Prometheus接收。本文将全面解释你需要了解的一切,以便能够立即开始使用Pushgateway。(以下说明是基于Prometheus Pushgateway的1.2.0版本进行测试的。)
请尝试设置MetricFire提供的托管Prometheus来单独跟踪博客。您可以通过免费演示咨询,注册免费试用并享受Prometheus和Grafana的所有优点,无需繁琐的安装、设置和维护。
基本用法
执行Pushgateway
首先最重要的是确定运行Prometheus Pushgateway所需要的条件。由于该软件是使用Go编写的,它将成为一个可在任何由Go支持的操作系统和架构上运行的自包含二进制文件。最方便的做法是访问Prometheus Pushgateway发布的Github页面,并从那里下载这些二进制文件。以下是一个方便的bash脚本,用于下载、提取和运行指定版本的Prometheus Pushgateway。
#!/bin/bash
VERSION="1.2.0"
wget "https://github.com/prometheus/pushgateway/releases/download/v${VERSION}/pushgateway-${VERSION}.linux-amd64.tar.gz"
tar xvzf "pushgateway-${VERSION}.linux-amd64.tar.gz" "pushgateway-${VERSION}.linux-amd64/pushgateway"
rm -f "pushgateway-${VERSION}.linux-amd64.tar.gz"
mv "pushgateway-${VERSION}.linux-amd64/pushgateway" ./
rmdir "pushgateway-${VERSION}.linux-amd64"
明显地,如果在机器上不同,就需要修改此片段的操作系统和架构。这将为当前的工作目录提供二进制推送网关。您可以使用这个来启动自己的推送网关。
如果使用容器,请在Docker Hub上准备好已创建的Docker镜像。
docker run -it -p 9091:9091 --rm prom/pushgateway
本地主机:提供在关闭时自动删除的Pushgateway容器(localhost:9091)。

最后,让我们谈谈Kubernetes。Helm是用于Kubernetes的通用软件包管理器。您可以使用以下命令安装Pushgateway的精美图表。
helm install stable/prometheus-pushgateway
默认情况下,图表会创建在9091端口上监听的服务。所有选项的参考列表可以在这里找到。此外,图表还可以与Prometheus Operator集成。集成意味着在该图表中添加serviceMonitor.enabled选项后,Pushgateway将自动被Prometheus进行抓取。这本身是一个大的主题,并且更与Kubernetes相关,因此在本文中我们会跳过此内容。如果您想了解更多详细信息,请随意浏览上述链接。
在大多数情况下,通过Pushgateway提供的默认选项能够很好地发挥作用。以下是对这些选项的解释:
-
- –web.listen-address =:9091、リクエストをリッスンするIP(オプション)とポートのペア。
-
- –web.telemetry-path = / metrics、Pushgatewayのメトリック(ユーザー送信と内部の両方)が公開されるパス。
-
- –web.external-url =、このPushgatewayが外部から利用できるURL。ドメイン名で公開する場合に便利です。
-
- –web.route-prefix =が指定されている場合、これをすべてのルートの接頭辞として使用します。デフォルトは–web.external-urlの接頭辞です。
-
- –web.enable-lifecycleを指定すると、APIを介してPushgatewayをシャットダウンできます。
-
- –web.enable-admin-apiを指定すると、Admin APIが有効になります。特定の破壊的なアクションを実行できます。次のセクションで詳しく説明します。
-
- –persistence.file =、指定されている場合、Pushgatewayはその状態を–persistence.interval期間ごとにこのファイルに書き込みます。
-
- –persistence.interval = 5m、状態を以前に指定したファイルに書き込む頻度。
-
- –push.disable-consistency-check(指定されている場合)は、取り込み時にメトリックが正しいかどうかがチェックされません。ほとんどの場合は指定しないでください。
-
- –log.level = info、debug、info、warn、errorのいずれか。それより高いレベルのメッセージのみを出力します。
- –log.format = logfmt、可能な値:logfmt、json。 Elasticsearchなどで使用できる構造化ログが必要な場合は、jsonを指定します。
传送度量值
到目前为止,Pushgateway应该已经在运行。接下来,我将介绍两种从短期批处理作业中发送自定义指标的方法。
-
- 使用能够执行Web请求的程序
- 使用客户端库
如果批处理任务是用Powershell或Bash等语言编写的,第一个选项适合使用。
在PowerShell中,您可以使用正確的Invoke-WebRequest命令发送Web请求到特定的URL和特定的数据。要将度量数据发送到Windows PowerShell的Pushgateway,请使用以下代码片段。
$metrics = "
# TYPE some_metric
gaugesome_metric 42
# TYPE awesomeness_total counter
# HELP awesomeness_total How awesome is this article.
awesomeness_total 99999999
"Invoke-WebRequest-Uri "http://localhost:9091/metrics/job/metricfire/instance/article" -Body $metrics -Method Post
运行上述代码段后,将在本地主机的9091端口的用户界面上显示以下结果。

因此,/ metrics端点包含了以下数据。

请注意,有两个标签:job和instance。如果Prometheus找不到它们,并且配置中的honor_labels为true,那么Prometheus将自动附加它们。在上面的代码片段中,用于创建请求的URL已添加到指标数据中。
在类似于Linux和其他Unix操作系统的情况下,您可以使用广泛使用的cURL来执行这个请求。下面的代码片段也可以得到与前面相同的结果。
cat <<EOF | curl --data-binary @- http://localhost:9091/metrics/job/metricfire/instance/article
# TYPE some_metric gauge
some_metric 42
# TYPE awesomeness_total counter
# HELP awesomeness_total How awesome is this article.
awesomeness_total
99999999
EOF
指定的URL标签用于对指标进行分组。这样可以将小组的指标一起引用,以便稍后容易地删除。
如果工作或其他标签中包含斜线(/),则需要进行额外的操作。有关详细信息,请查看此处。
只需一种选择,尽可能的以中国特色的方式表达:
通过URL传递指标时,唯一需要的标签是作业的标签。另外,请注意通过URL传递的标签会覆盖指标本身附带的标签。如果有疑问,您可以随时推送一些示例指标,并检查/metrics(或通过–web.telemetry-path更改的其他路径),以查看Prometheus公开的指标:http://localhost:9091/metrics。
当一切顺利时,应该返回包含200 HTTP状态码的响应。如果禁用了一致性检查,则可能显示202 HTTP状态码。这意味着指标已进入队列以包含在下一次抓取中,但尚未进行检查。即使将完全相同的名称写入,如果以不同类型进行推送等,推送无效的指标,实际的抓取也可能失败。
最后,400 HTTP状态码表示推送了一些无效的指标,但这些指标被拒绝了。在这种情况下,HTTP响应会告诉我们出了什么问题。
例:已推送的指标无效或与现有指标不匹配:以前已使用相同名称和标签值收集的指标 “some_metric” {label:标签:标签:仪表盘:}。
换言之,同一请求中有两个重复的度量定义。如果在同一请求或抓取中重新定义了度量的值,那么它将变为无效。
使用爬虫程序来收集指标数据。
可以使用的配置因各种可用的服务检测机制而大为不同。请查阅此处资料中可用的不同配置选项。最简单的选项是静态地定义获取指标的 Pushgateway 目标。
scrape_configs:
- job_name: pushgateway
honor_labels: false
static_configs:
- targets: ['localhost:9091']
labels:
pushgateway_instance: metricfire
当使用本地的Pushgateway运行时,Prometheus将在localhost:9091上抓取Pushgateway的实例。还需要考虑的是启用honor_labels参数。启用后,当Prometheus尝试添加特定的预留标签或在抓取配置中指定的标签时,它将选择Pushgateway提供的标签,而不是Prometheus自己尝试连接的标签。例如,如果有一个指标在Pushgateway上定义为Pushgateway awesomeness {pushgateway_instance=”notmetricfire”},则在上述代码片段中可见的抓取配置中,将使用值为notmetricfire的该标签,而不是metricfire,它是在标签中定义的。如果找不到该标签,则原始标签将被更名为exported_pushgateway_instance,并带有值为notmetricfire。
启用honor_label选项将有助于保留Pushgateway公开的所有标签,如必需的作业标签等。使用相同的作业标签查询Pushgateway中的指标将使得查询更加明确。
删除度量标准
要删除指标有三种方法。
-
- 如果在UI上点击指标组附近。
-
- – 如果已经通过web.enable-admin-api启用,通过管理API的清除端点来操作。
- – 使用DELETE方法创建HTTP请求。
从UI上删除很简单。如果在本地运行Pushgateway,则访问http://localhost:9091/。然后,找到要删除的指标组并展开。在删除之前,展开指标是一个很好的方法来确保清楚地了解它是什么。这样,就确保不会误删除所需的内容。最后,点击[删除组],然后再次点击[删除]以确认动作。界面上的显示如下:


这样度量就消失了。

一种方法是,管理API仅提供删除所有度量标准的选项。只需使用动词PUT向/api/v1/admin/wipe发送调用即可。使用cURL的-X参数,可以更改要使用的动词。以下是在cURL中的示例。
curl -X PUT http://localhost:9091/api/v1/admin/wipe
当成功时,将返回包含2xx HTTP状态码的响应。
启用此功能后,您将在UI上看到一个漂亮的按钮,并且可以进行相同的操作。

因此,您可以选择调用API或点击此按钮。
最后,您可以使用先前使用的分组标签来删除指标。这与发送N个指标完全相同,但需要使用DELETE代替POST动词。这可以通过cURL的-X或Powershell的-Method来指定。例如,如果有一些由job=”metricfire”和instance=”article”标识的指标,您可以通过发送请求来使用cURL删除它们。
curl -X DELETE http://localhost:9091/metrics/job/metricfire/instance/article
用以下方法删除组。

在这个调用中,将只删除特定的度量组。也就是说,如果将实例标签设置为ebook,并且在作业标签中有另一个度量组作为metricfire组,那么将进行下一个调用。
curl -X DELETE http://localhost:9091/metrics/job/metricfire
与metricfire相等的所有度量组不会被删除。只会删除由与metricfire相等的单个标签作为标识的度量组。在此示例中,不涉及上述度量组或标签实例与article或ebook相等的其他度量组。
警报
建议在所有准备工作完成之后,添加一个警报,并确认问题何时发生。 Pushgateway会提前生成一些有用的度量标准供使用。通常应该在以下情况下接收通知。
-
- 誰かが一貫性のないメトリックをプッシュしようとした
-
- Pushgatewayは、予想よりも長い時間メトリックをプッシュしていない
- プッシュゲートウェイがダウンしている
groups:
- name: PushgatewayAlerts
rules:
- alert: PushgatewayDown
expr: up{job="pushgateway"} != 0
for: 10m
labels:
severity: page
annotations:
summary: A Pushgateway is down
- alert: PushesDelayed
expr: time() - push_time_seconds{job="pushgateway"} > 300
for: 5m
labels:
severity: critical
annotations:
summary: Pushgateway pushers are delayed
- alert: InconsistentMetrics
expr: rate(pushgateway_http_requests_total{code="400",handler="push",job="pushgateway"}[2m]) > 0
for: 5m
labels:
severity: critical
annotations:
summary: Someone is continuously trying to push inconsistent metrics to the Pushgateway
当然,需要根据设置来调整阈值等。特别是第二个警报,因为假设所有推送器都始终将新的指标推送到推送网关上。如果不符合这一假设,就需要添加额外的指标选择器,以便只在真正需要时应用。
进行统计
Pushgateway被有意设计为不聚合收到的指标,即一旦收到后,将永久地暴露给Prometheus。然而,这并不适用于所有的用例。举个例子,假设有一些处理小批量作业的作业单元,那么可能会显示一个从初始值不断增加的计数器。
因此,在普通的推送网关中,为了能够在同一作业的重新启动和多个实例之间进行跟踪,需要将该值存储在某处。然而,这可能导致复杂度显著增加,因为需要维护额外的基础架构来处理对同一计数器的并发访问等。为了解决这个问题,聚合型推送网关被创建出来。
集約Pushgateway会在其持续期间中汇总接收到的各种值。例如,具有相同标签名称和值的计数器将被一起添加。您可以在这里找到相关软件。有关与常规Pushgateway的区别,请参见这里。因此,如果出现此问题,则可以使用代替解决方案来替代它。这也意味着所有给出的建议都适用于它。
高度可靠性
很遗憾,Pushgateway不能保证强大的一致性。如前所述,它只能将指定时间段的指标保存在磁盘上。这些操作受到参数–persistence.file和–persistence.interval的控制。
换句话说,建议为一个节点(处理流量的节点)准备可写入的挂载存储,其他节点将挂载为只读的持久化存储。在Kubernetes的世界中,可以通过ReadWriteOnce模式的持久化卷声明来实现这一点。可以通过此处探索所有可用的不同选项。
推动网关Helm图表已经通过persistentVolume.enabled:true支持它。可以如下指定此参数。
helm install --name metricfire-pushgateway --set
persistentVolume.enabled=true stable/prometheus-pushgateway
请您从这里查看所有其他可用选项。
最终中
通过这一系列内容,你已经了解了启动和运行Pushgateway所需知道的所有信息。我们已经了解了如何发送指标、抓取指标、删除指标以及与指标相关的警报方法。如果你想了解更多关于Prometheus高可用性监控的信息,请查看有关使用Prometheus + Thanos进行HA Kubernetes监控的文章。同样地,如果你想了解更多关于使用Prometheus进行监控的详细信息,请查阅其他的Qiita文章或MetricFire博客。
MetricFire的免费演示是考虑使用Prometheus的最佳方法。当用户开始扩展Prometheus监控,并需要配置长期存储和数据冗余性时,MetricFire的优势将得到充分发挥。为什么不试试使用MetricFire提供的Hosted Prometheus来解决Prometheus的问题呢?
那么,在下一篇文章再见!