PushGateway与Flink实战之坑：漫谈监控模型中的拉与推

泊浮目

发布于 2024-01-09 13:30:48

3090

发布于 2024-01-09 13:30:48

版本	日期	备注
1.0	2021.8.14	文章首发

0.背景

最近在为流处理组件接入监控，用了PushGateway（下文称为PGW），结果踩了不少坑，上来分享一下。

1.为什么是Push（PGW）

之前的实现pull，即在一个进程中暴露服务端口遵循Prometheous（下文简称Prom）的协议，让Prom来拉取数据。

但这有一个问题，需要分配端口。之前我们团队用了很多麻烦的实现：分布式锁、多份状态存储等...但仍然避免不了端口泄漏、浪费的问题（拓扑高可用机制会导致它在不同的机器间偏移，那么之前分配的某机器端口就无用了）。尽管我们也可以去监控拓扑的生命周期，但这绝非易事——在较大的场景中，k级的拓扑是很正常的，然而要有效监控k级别的拓扑生命周期，似乎又是个大的话题。

我的同事告诉我k8s可能可以解决我的问题，在之后我也会尝试跟进这个技术栈的引入。

我们仅仅想实现一个监控，并不想管其他有的没的事。

那么又到了老生常谈的话题了，到底是push好还是pull好。我的观点是脱开场景讲道理就是耍流氓，到这个场景中，push更合适。

说到底，push要求被监控服务知道监控系统的地址，因此该信息需要设置在被监控服务中。因此被监控服务一定程度上会依赖监控服务；而pull则要求监控系统知道所有被监控服务的地址，那么每增加一个被监控的服务，监控服务需要通过一些手段去感知到它——比如prom支持从服务发现系统中动态获取目标服务，而flink支持通过port range来确认被监控服务所在的位置。

而关于其他的push和poll模型的对比，我们可以查看下面的表格，根据自己的场景做出对比：

维度	推模型	拉模型
服务发现	较快。在启动时，agent能够自动发送数据。因此发现服务的速度与agent数量无关	较慢。需要通过定期扫描地址空间来发现新的服务，发现服务的速度与agent数量有关
可扩展性	较好。只需要部署agent，而agent一般也是无状态的	较差。监控系统的工作量会随着agent数量线性上升
安全性	较好。不用侦挺网络连接，可以抵御远程攻击	较差。可能面临远程访问和拒绝服务攻击
操作复杂性	较好。只需感知轮询间隔和监控系统地址。防火墙需要配置为从代理到收集器的单向测量通信。	较差。监控系统需要配置要轮询agent列表、访问agent的安全凭据以及要检索的度量集。防火墙需要配置为允许轮询器和代理之间的双向通信。
延迟	较好。推送的及时性较好。也有许多推送协议（如sFlow）都是在UDP之上实现的，提供了无阻塞、低延迟的测量传输。	较差，实时性较低

而关于Prom官网中也介绍了绝大多数情况下PGW是不适用的，除了：

Usually, the only valid use case for the Pushgateway is for capturing the outcome of a service-level batch job. A "service-level" batch job is one which is not semantically related to a specific machine or job instance (for example, a batch job that deletes a number of users for an entire service). Such a job's metrics should not include a machine or instance label to decouple the lifecycle of specific machines or instances from the pushed metrics. This decreases the burden for managing stale metrics in the Pushgateway. See also the best practices for monitoring batch jobs.

在best practicse for monitoring batch jobs中，也有提到：

There is a fuzzy line between offline-processing and batch jobs, as offline processing may be done in batch jobs. Batch jobs are distinguished by the fact that they do not run continuously, which makes scraping them difficult.

包括在它的github仓库上是这样介绍：

The Prometheus Pushgateway exists to allow ephemeral and batch jobs to expose their metrics to Prometheus. Since these kinds of jobs may not exist long enough to be scraped, they can instead push their metrics to a Pushgateway. The Pushgateway then exposes these metrics to Prometheus.

我的业务系统的确存在ephemeral job(mean the jobs may not exist long enough)这也是我选择PGW的重要原因。

2.踩了什么样的坑

本来接入PGW后，该有的数据都有了。结果测试同学在测试时发现突然监控数据不见了，我一看，创建了大量拓扑做流式任务，PGW直接退出了，日志里有着out of memory的字样。

再测了两把，发现PGW随着拓扑的增加，消耗的内存和CPU也越来越厉害。

于是我想起官网里提到的：

The Pushgateway never forgets series pushed to it and will expose them to Prometheus forever unless those series are manually deleted via the Pushgateway's API.

但是我明明配置了了deleteOnShutdown 这个配置啊，官网里的解释是：Specifies whether to delete metrics from the PushGateway on shutdown.，但我重新运行PGW时，发现相关的mertics并没有删掉！

我们团队经过了一番搜索，发现了一个Issue：issues.apache.org/jira/browse…

部分人觉得PGW应该做TTL的事，而PGW觉得这不是一个好的方法。而我觉得这是Flink自己应该fix的事，不知道为什么没有修复，并且官网的文档中也没有提示这个坑。

我往Flink文档里提了一个patch，希望能够尽早合入吧——github.com/apache/flin…

3. 小结

本文和大家分享了我们团队在PushGateway与Flink结合时踩的坑，并讨论了我们选择PGW的初衷。之后我打算关注一下InfluxDB，以它来作为推入端代替PGW，我还注意到InfluxDB 新版的生态也挺不错，提供了面板、数据可视化以及告警，不再是单纯的时序数据库，结合自己的生态，会和prom+grafana越来越像。