江苏龙网

  1. 首页 > 资讯 > 科技 > >

|搭建Prometheus平台，你必须考虑的6个因素


作者简介
Loris Degioanni ， Sysdig的创始人和CTO ， 同时还是容器安全工具Falco的创建者 。
当前 ， Prometheus被许多企业和组织广泛使用 ， 以监控其容器和微服务 。 但是在这一过程中 ， 大型公司通常会陷入困境：当应用程序数量越来越多的时候 ， 扩展监控指标则是一个十分重大的挑战 。
不断增长的容器使情况复杂化
相对来说 ， 监控单体环境常常更简单 ， 因为静态物理服务器和虚拟机数量是确定的 ， 并且监控指标的数量也是有限的 。 但是 ， 如今由于容器以及需要向微服务架构迁移 ， 要跟踪监控的实例程序数量激增 。
如果说位于数据中心的服务器是宠物 ， 需要我们不断关注的话 ， 那么云实例则更像牛（因为有很多 ， 你不必关心单个实例） ， 而容器则更像小蜜蜂 。 它们数量很多 ， 有时每台机器有数百个容器 ， 并且新的容器一直不断出现 ， 当与诸如Kubernetes的容器编排引擎一起使用时 ， 它们的寿命可能非常短 。 这使得跟踪监控它们变得更加困难 ， 而且如果你不小心误操作的话 ， 它们可能会造成很多损害 。
随着复杂性和分布式环境的增加 ， 你需要监控的实体数量也在增加 。 此外 ， 你可能希望监控更多属性以确保你对正在发生的事情有准确的了解 ， 或者在进行故障排除或事件响应的情况下 ， 可以了解正在发生的事情 。 在短暂的环境中 ， 后者尤其成问题 ， 因为当你想了解问题的根本原因时 ， 通常相关的资源已经停用 ， 这意味着监控解决方案必须提供一种能够存储足够的历史记录以进行取证的方法 。
流行的监控工具：Prometheus
越来越多需要云监控的团队正在转向Prometheus ， 这是一个开源的CNCF项目 。 Prometheus已成为开发人员用来在云原生环境中收集和理解指标的首选监控工具 。 它由一个大型社区支持 ， 有来自700多家公司的6300个贡献者 ， 有13500个代码提交和7200个拉取请求 。
默认情况下 ， 典型的云原生应用程序堆栈（如Kubernetes、Ngnix、MongoDB、Kafka、golang等）会暴露Prometheus指标 。 Prometheus是一个可以垂直弹性伸缩的Go程序 ， 为单个容器或单个主机部署它时十分容易 。 换言之 ， 一开始使用Prometheus极为容易 ， 你可以轻松监控你的第一个Kubernetes集群 ， 但是这也意味着随着基础架构的增长 ， 监控会越来越复杂 。

|搭建Prometheus平台，你必须考虑的6个因素
本文插图

应用程序增长带来的扩展问题
随着环境规模增长 ， 你需要跟踪监控飞速增长的时间序列数据 ， 并且在数据量达到某个点之后 ， 单个Prometheus实例无法继续跟踪监控 。 这一情况下 ， 最直接的选择是在整个企业中运行一组Prometheus服务器 ， 但这带来了一些挑战 。 例如 ， 跨数十甚至数百台Prometheus服务器管理和合并数据并不容易 。 同样 ， 了解企业工作流程、单点登录、基于角色的访问控制以及遵守SLA或合规性也不是容易的问题 。 随着应用程序的增长 ， 在不中断开发人员工作的情况下运行一个全方位的监控解决方案 ， 这将成为一个可管理性和可靠性的问题 。
为了解决这一问题 ， 企业采用了许多方法 。
简单的方法是为每个命名空间或每个集群都准备一个单独的Prometheus服务器 。 这种方法到一定规模就会难以为继 ， 此外 ， 它还有一个缺点 ， 那就是会造成大量的断开的数据孤岛 。 这会使故障排查变得很麻烦 ， 因为大多数问题会跨越多个服务/团队/集群 。 不但在每个环境中很难找到相同的指标 ， 你还需要把数据拼接在一起 ， 以试图了解发生了什么 。
另一个常见方法是使用类似Cortex或Thanos的开源工具来集合多个Prometheus服务器 。 这些高效的工具可以让你集中查询服务器、收集数据然后在统一的dashboard中共享 。 然而 ， 与任何数据密集型分布式系统一样 ， 它们需要大量的技能和资源才能运行 。


推荐阅读


上一篇：科技小树|舒适度比较高的蓝牙耳机品牌都有什么？蓝牙耳机品牌排行！

下一篇：DIGITIMES|全球最大、分辨率最高8K全息投影显示器开始出货