共计 3087 个字符，预计需要花费 8 分钟才能阅读完成。
本文首发于泊浮目标简书:https://www.jianshu.com/u/204…
| 版本 | 日期 | 备注 |
|---|---|---|
| 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：https://issues.apache.org/jir…
局部人感觉 PGW 应该做 TTL 的事，而 PGW 感觉这不是一个好的办法。而我感觉这是 Flink 本人应该 fix 的事，不晓得为什么没有修复，并且官网的文档中也没有提醒这个坑。
我往 Flink 文档里提了一个 patch，心愿可能尽早合入吧——https://github.com/apache/fli…。
3. 小结
本文和大家分享了咱们团队在 PushGateway 与 Flink 联合时踩的坑，并探讨了咱们抉择 PGW 的初衷。之后我打算关注一下 InfluxDB，以它来作为推入端代替 PGW，我还留神到 InfluxDB 新版的生态也挺不错，提供了面板、数据可视化以及告警，不再是单纯的时序数据库，联合本人的生态，会和 prom+grafana 越来越像。
3.1 参考资料
- https://blog.sflow.com/2012/0…
- https://prometheus.io/docs/pr…
- https://prometheus.io/docs/pr…
- https://ci.apache.org/project…
