|
本文将会涵盖使用Prometheus扩展中遇到的大部分问题。Prometheus是云原生环境的支柱之一，创建了名为Prometheus监控之后，成为了实际的K8S环境的可视化标准。Prometheus和K8S关联紧密，经历了各个开发阶段，一路走来，从理念到生产环境一路相辅相成。通常，在开发阶段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的系统可能会需要。大概率会需要集成身份验证系统来保持用户信息实时更新。
所有的这些问题都有解决方案，但是需要付出架构设计，开发，实施的努力。这一套架的维护也需要花费大量资源。 努力工作之后，你现在有一个很好的中心化的系统，一切都很美好。开发者认识到自定义监控参数的好处，编写代码来获得。你的组织开始扩张，K8S里的服务数量增加，参数用途扩大。集群开始扩容，服务有了更多的复制品。与此同时，你的Prometheus服务器开始死亡，troubleshooting之后，你发现问题在内存上。Prometheus上的内存使用和存储数据的时间段直接相关，随着存储数据时间段不断增加，内存开始溢出。提高资源配额不能永久解决问题，总会到达节点机器的内存顶点。百万参数的Prometheus可以占用超过100G的内存资源，可能会影响K8S集群。你必须要扩容来增加资源，但是Prometheus并不是设计来水平扩展地。一旦垂直扩展的上限达到，万事休矣。
对此问题，有一些解决方案，比如对不同地数据记录在几台Prometheus服务器上做分区，但是这比较复杂，实施和troubleshooting起来都很困难。
许多人都曾面对这个问题。Prometheus声称它并不是一个数据记录存储，那么有些人最终为Prometheus指标创建了长期存储方案。目前有一些开源社区地项目提供长期存储：Cortex, Thanos,M3 .架构复杂，需要大量精力部署，优化，维护监控自启动服务 操作成本高，你可以使用DynamoDB等数据库，但是依然需要扩展其他的监控服务，而且数据吞 吐量会很高。 这些项目还在早期地开发阶段，即使有专职小组来负责，生产环境中运行仍然有风险。
Prometheus是云原生地应用监控领域地变革者，一如K8S对于容器编排。然而，即使是大型科技公司在Prometheus扩展上大费脑筋。每一个全职维护Prometheus地开发者都是业务部门地损失。探索新的领域确实让人兴奋，但是有时候可以付费来直接购买好的服务。为了解决消费者遇到地问题，Sysdig公司一直在提升自己的服务，我们希望兼容所有的Prometheus同时提升我们地扩展能力来保持百万级别地时间段数据。使用Sysdig产品，你可以体验安全可扩展地Prometheus解决方案.原文链接：https:///blog/challenges-scale-prometheus/
|
