共计 2951 个字符，预计需要花费 8 分钟才能阅读完成。
这篇文章主要介绍搭建 Prometheus 平台需要考虑哪些因素，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
不断增长的容器使情况复杂化
相对来说，监控单体环境常常更简单，因为静态物理服务器和虚拟机数量是确定的，并且监控指标的数量也是有限的。但是，如今由于容器以及需要向微服务架构迁移，要跟踪监控的实例程序数量激增。
如果说位于数据中心的服务器是宠物，需要我们不断关注的话，那么云实例则更像牛（因为有很多，你不必关心单个实例），而容器则更像小蜜蜂。它们数量很多，有时每台机器有数百个容器，并且新的容器一直不断出现，当与诸如 Kubernetes 的容器编排引擎一起使用时，它们的寿命可能非常短。这使得跟踪监控它们变得更加困难，而且如果你不小心误操作的话，它们可能会造成很多损害。
随着复杂性和分布式环境的增加，你需要监控的实体数量也在增加。此外，你可能希望监控更多属性以确保你对正在发生的事情有准确的了解，或者在进行故障排除或事件响应的情况下，可以了解正在发生的事情。在短暂的环境中，后者尤其成问题，因为当你想了解问题的根本原因时，通常相关的资源已经停用，这意味着监控解决方案必须提供一种能够存储足够的历史记录以进行取证的方法。
流行的监控工具：Prometheus
越来越多需要云监控的团队正在转向 Prometheus，这是一个开源的 CNCF 项目。Prometheus 已成为开发人员用来在云原生环境中收集和理解指标的首选监控工具。它由一个大型社区支持，有来自 700 多家公司的 6300 个贡献者，有 13500 个代码提交和 7200 个拉取请求。
默认情况下，典型的云原生应用程序堆栈（如 Kubernetes、Ngnix、MongoDB、Kafka、golang 等）会暴露 Prometheus 指标。Prometheus 是一个可以垂直弹性伸缩的 Go 程序，为单个容器或单个主机部署它时十分容易。换言之，一开始使用 Prometheus 极为容易，你可以轻松监控你的第一个 Kubernetes 集群，但是这也意味着随着基础架构的增长，监控会越来越复杂。
应用程序增长带来的扩展问题
随着环境规模增长，你需要跟踪监控飞速增长的时间序列数据，并且在数据量达到某个点之后，单个 Prometheus 实例无法继续跟踪监控。这一情况下，最直接的选择是在整个企业中运行一组 Prometheus 服务器，但这带来了一些挑战。例如，跨数十甚至数百台 Prometheus 服务器管理和合并数据并不容易。同样，了解企业工作流程、单点登录、基于角色的访问控制以及遵守 SLA 或合规性也不是容易的问题。随着应用程序的增长，在不中断开发人员工作的情况下运行一个全方位的监控解决方案，这将成为一个可管理性和可靠性的问题。
为了解决这一问题，企业采用了许多方法。
简单的方法是为每个命名空间或每个集群都准备一个单独的 Prometheus 服务器。这种方法到一定规模就会难以为继，此外，它还有一个缺点，那就是会造成大量的断开的数据孤岛。这会使故障排查变得很麻烦，因为大多数问题会跨越多个服务 / 团队 / 集群。不但在每个环境中很难找到相同的指标，你还需要把数据拼接在一起，以试图了解发生了什么。
另一个常见方法是使用类似 Cortex 或 Thanos 的开源工具来集合多个 Prometheus 服务器。这些高效的工具可以让你集中查询服务器、收集数据然后在统一的 dashboard 中共享。然而，与任何数据密集型分布式系统一样，它们需要大量的技能和资源才能运行。
需要考虑的 6 个因素
对于那些以 Prometheus 为起点，然后寻求商业化解决方案以获得全局监控的公司来说，重要的是，不丢失 Prometheus 上完成的所有标准化开发工作——dashboard、告警、exporter 等。然而，这不是需要考虑的唯一事情，如果你继续使用 Prometheus，需要坚持以下标准：
1、兼容性，以支持所有 Prometheus 功能
你的供应商 / 所使用的工具 /SaaS 解决方案需要能够使用任何可产生 Prometheus 指标的实体程序中消耗数据，无论是本地 Kubernetes 还是云服务。相对来说，消耗 Prometheus 指标微不足道，但是也不要忽略一些小事情，例如将指标提取到存储中或增加数据时能够重新标注指标，这样对你的环境更有意义。这些小事加起来，能够收集到的数据将会堆积如山、大不相同。
2、PromQL 兼容性
Prometheus 查询语言由 Prometheus 创建者发明，用于提取存储在 Prometheus 中的信息。PromQL 能让你查询指定服务或指定用户的指标，它还能汇总或细分数据。例如，你可以使用它显示所有容器中每个应用的 CPU 使用率。或者仅显示 Cassandra 容器的数据，并将其显示为每个集群的单个值。可以说，PromQL 释放了 Prometheus 的真正价值，因此如果将 Prometheus 的指标集成到一个不完全支持 PromQL 的产品中，就完全违背了使用 Prometheus 的初衷。
3、支持热插拔
要真正与 Prometheus 兼容，该解决方案必须能够支持热插拔，以便能够与你现有的 dashboard、告警和脚本一起使用。例如，许多使用 Prometheus 的企业都将 Grafana 用于 dashboard。这个开源工具能够与 Prometheus 很好地集成在一起，包括在查询级别，并且可以用于生成一系列有用的图表和 dashboard。因此，声称与 Prometheus 兼容的商业产品应与 Grafana 等工具兼容。仅仅说解决方案可以让你在 Grafana 中查看数字是远远不够的，你需要能够按照原样提取现有的 Grafana dashboard，并将它们重新应用于商业解决方案中已安装的数据。
4、访问控制
在评估工具时，访问控制是另一个你需要考虑的安全问题。能够使用行业标准协议（包括 LDAP、Google Oauth、SAML 和 OpenID）保护用户身份验证，使公司能够通过基于服务的访问控制来隔离和保护资源。
5、故障排查
Kubernetes 简化了部署、弹性伸缩和管理容器化应用程序和微服务。这有助于保持服务的正常运行，但是要识别和解决诸如性能降低、部署失败和连接错误之类的根本问题，你需要能够从整个环境中收集和可视化基础架构、应用程序和性能数据。由于无法同时访问实时信息和上下文数据，因此几乎不可能关联环境中的指标，所以你可以更快地解决问题。
6、与现有告警兼容
最后，如果你正在寻找商业解决方案来帮助解决 Prometheus 可扩展性问题，请确保它支持所有级别的告警。能够实现这一目标的关键是全面支持 Alert Manager 功能，而 Alert Manager 还要求 100% 的集成和 PromQL 兼容性。
如果你找到一个能够满足以上标准的商业化工具，你应该能够轻松将其集成到现有的 Prometheus 中，并且能够避免公司遇到的可扩展性问题。开发人员有充分的理由喜爱 Prometheus，因此在采用商业化方案之前进行全面、尽职的调查将确保他们仍然可以使用自己喜欢的指标。
以上是“搭建 Prometheus 平台需要考虑哪些因素”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注丸趣 TV 行业资讯频道！
