Prometheus扩展遇到的挑战

本文将会涵盖使用Prometheus扩展中遇到的大部分问题。

Prometheus是云原生环境的支柱之一,创建了名为Prometheus监控之后,成为了实际的K8S环境的可视化标准。Prometheus和K8S关联紧密,经历了各个开发阶段,一路走来,从理念到生产环境一路相辅相成。

Prometheus第一阶段

通常,在开发阶段Prometheus就和第一个K8S集群一起合作了。部署了一些app之后,你可能发现你需要监控集群内部的信息,但是老的基于宿主机的工具不能工作。精疲力尽地调查之后,你发现了Prometheus。

部署了K8S集群之后,Prometheus和Grafana,再加上一些基础的导出工具,你需要的数据就到手了,可以开始构建仪表盘和告警了。

随着你对Prometheus的了解深入之后,它出色的特性也随之出现:

 

Service discovery机制让配置工作更简单

开源社区提供的数以百计的数据导出工具

仪表盘相关的library可以自定义应用的监控指标

背靠云原生基金会的大树,继K8S之后,第二个毕业的项目,而且是OSS

K8S已经仪表盘化了而且把Prometheus的参数暴漏给它的服务了

 

目前的阶段,一切顺利。K8S是你最好的朋友,你的应用顺利扩展,在fashion的仪表盘上,你可以查看大量信息。让我们开启下一步的工作吧!

让我们转移到生产环境

你的第二个K8S集群构建好了,你遵循相同的流程,部署Prometheus,导出工具,grafana。Staging阶段的集群通常比开发环境的要更大,但是Prometheus可以轻松应对。现在K8S集群上的应用并不多,仪表盘和用户的数量也不多,迁移工作相对简单。

第一个问题出现了,现在部署了两套不同的Grafana,观察开发环境和staging环境的参数需要在两套grafana中切换。目前的阶段,只是小问题,开发者并不会太担心。所有的东西都检查完毕,准备投放到生产环境了。

 

 

 

现在,遵循相同的流程,部署Prometheus,导出工具,Grafana,迁移dashboard和用户,你的第三套集群创建完毕。用户虽然并不很满意同时有三套监控网站,但是这并不能阻止你前进的步伐。

 

迁移应用到K8S的反馈很好,公司决定前期更多的应用到K8S。新的用户,配置,dashboard和告警需要一个一个地添加到每个集群中。管理配置文件开始需要更多地精力和时间。

应用快速增长带来了新的需求,不同应用需要更多地集群来服务不同区域增加可用性。每个集群使用不同的Prometheus和Grafana实例,环境太复杂,DevOps和开发小组开始抱怨。

保持全局的可见性

分布式的模型带来了不同的挑战:

 

并不支持全局的可视性,一些生产集群会把它当成新的需求

操作会很笨重而且花费大量时间

模型会复杂化管理和监督工作

 

为了访问不同的K8S集群,中心化的可视化工具可以在一个dashboard里观看并且关联跨越多个集群的服务信息。

乍一看,这可能很简单,我部署一个中心化的Grafana,添加不同集群上的Prometheus作为数据源。

 

但是,这里有隐藏的挑战

Prometheus并不提供安全的特性。如果Prometheus和Grafana通信在集群内部还好说,如果Grafana在集群之外,你需要在Prometheus上限制连接和访问数据。应对此问题有很多解决方案,但是管理证书,创建ingress controller,Grafana配置安全信息等等工作,需要花费更多的时间和精力。

如果集群是动态变化的,那么在部署Prometheus到集群的时候,最好实现自动化添加数

据源到Grafana的功能。

一个dashboard可以提供不同的数据源用于展示,但是我们还是不能跨越不同集群来检索服务。

数据访问的控制更重要了,RBAC的系统可能会需要。大概率会需要集成身份验证系统来

保持用户信息实时更新。

所有的这些问题都有解决方案,但是需要付出架构设计,开发,实施的努力。这一套架的维护也需要花费大量资源。

 

Prometheus水平扩展

努力工作之后,你现在有一个很好的中心化的系统,一切都很美好。开发者认识到自定义监控参数的好处,编写代码来获得。你的组织开始扩张,K8S里的服务数量增加,参数用途扩大。集群开始扩容,服务有了更多的复制品。

与此同时,你的Prometheus服务器开始死亡,troubleshooting之后,你发现问题在内存上。Prometheus上的内存使用和存储数据的时间段直接相关,随着存储数据时间段不断增加,内存开始溢出。提高资源配额不能永久解决问题,总会到达节点机器的内存顶点。百万参数的Prometheus可以占用超过100G的内存资源,可能会影响K8S集群。你必须要扩容来增加资源,但是Prometheus并不是设计来水平扩展地。一旦垂直扩展的上限达到,万事休矣。

 

对此问题,有一些解决方案,比如对不同地数据记录在几台Prometheus服务器上做分区,但是这比较复杂,实施和troubleshooting起来都很困难。

 

让我们尝试长期存储解决方案

许多人都曾面对这个问题。Prometheus声称它并不是一个数据记录存储,那么有些人最终为Prometheus指标创建了长期存储方案。

目前有一些开源社区地项目提供长期存储:Cortex, Thanos,M3 .

这些服务也很复杂,而且:

 

架构复杂,需要大量精力部署,优化,维护监控自启动服务

操作成本高,你可以使用DynamoDB等数据库,但是依然需要扩展其他的监控服务,而且数据吞 吐量会很高。

这些项目还在早期地开发阶段,即使有专职小组来负责,生产环境中运行仍然有风险。

 

What’s  Next?

Prometheus是云原生地应用监控领域地变革者,一如K8S对于容器编排。然而,即使是大型科技公司在Prometheus扩展上大费脑筋。每一个全职维护Prometheus地开发者都是业务部门地损失。

探索新的领域确实让人兴奋,但是有时候可以付费来直接购买好的服务。

为了解决消费者遇到地问题,Sysdig公司一直在提升自己的服务,我们希望兼容所有的Prometheus同时提升我们地扩展能力来保持百万级别地时间段数据。使用Sysdig产品,你可以体验安全可扩展地Prometheus解决方案.

K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址