ToB企服应用市场:ToB评测及商务社交产业平台
标题:
教你如何进行Prometheus 分片主动缩放
[打印本页]
作者:
来自云龙湖轮廓分明的月亮
时间:
2024-5-18 05:52
标题:
教你如何进行Prometheus 分片主动缩放
本文分享自华为云社区《
利用 Prometheus-Operator 进行 Prometheus + Keda 分片主动缩放
》,作者: Kubeservice@董江。
垂直缩放与程度缩放
Prometheus已经成为云原生时代事实上的监控工具。从监控小型花圃的实例到企业中大规模的监控,Prometheus 都可以处理工作负载!但并非没有挑战…
在拥有数百个团队的大型组织中,每秒获取数百万个指标是很常见的。人们可以维护一个 Prometheus 实例,并通过投入资金来办理扩展问题:只需获得一个更大的节点即可。好吧,如果你愿意付钱,那就去吧!但是节点价格的增长速度通常高于其大小,并且管理大型和小型 Prometheus 实例之间还有另一个很大的区别:WAL 重播!
Prometheus 保存一个包含最新抓取数据的内存数据库。为了制止在可能的重新启动期间丢失数据,Prometheus 在磁盘上保存了预写日志 (WAL)。当 Prometheus 重启时,它会将 WAL 重新加载到内存中,如许最新抓取的数据就又可用了,这个操作就是我们所说的 WAL Replay。
在 WAL 重放期间,Prometheus 完全无法进行查询,也无法抓取任何目的,因此我们希望尽快完成此操作!这就是巨大的 Prometheus 实例成为问题的时候。当将数百 GiB 的数据重放到内存中时,此操作很轻易需要 20 到 30 分钟,在更极端的情况下乃至需要几个小时。如果您决定保存单个 Prometheus 实例,WAL Replay 操作可能会导致监控体系出现长时间停机。
制止大型 Prometheus 实例的一种常见策略是在多个 Prometheus 之间分片抓取目的。由于每个 Prometheus 都会抓取较少量的指标,因此它们会小得多,并且 WAL Replay 不会像从前那样成为问题。为了仍然能够拥有集中式查询体验,可以将指标转发到另一个工具,比方 Thanos、Cortex 或云提供商,这些工具也能够扩展 Prometheus 查询功能。
整个时间内负载不均匀
我们已经通过利用分片而不是垂直扩展 Prometheus 取得了一些重大进展,但是当暴露的指标数量全天增加和减少时会发生什么?对于每天从数百个节点扩展到数千个节点(反之亦然)的 Kubernetes 集群来说,这是一种非经常见的情况。在决定普罗米修斯碎片的数量时,我们如何找到成本/效益比的最佳点?
您可以每天手动微调集群中的分片数量,但有更智能的方法来完成此任务。在这篇博文中,我将重点介绍 Horizontal Pod Autoscaler 策略,该策略是最近通过 Prometheus-Operator v0.71.0 版本实现的。
利用 Keda 主动缩放 Prometheus 碎片
设置
利用 Kubernetes Scale API 的任何类型的 Horizontal Pod Autoscaler,但出于演示目的,将利用Keda,它支持多种扩展策略。
让我们从创建一个小型集群开始,我发起利用KinD或Minikube:
[code]$ kind create clusterCreating cluster "kind" ... ✓ Ensuring node image (kindest/node:v1.27.1)
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)
Powered by Discuz! X3.4