搭建Prometheus平台，你必须考虑的6个因素
当前，Prometheus被许多企业和组织广泛使用，以监控其容器和微服务。但是在这一过程中，大型公司通常会陷入困境：当应用程序数量越来越多的时候，扩展监控指标则是一个十分重大的挑战。
相对来说，监控单体环境常常更简单，因为静态物理服务器和虚拟机数量是确定的，并且监控指标的数量也是有限的。但是，如今由于容器以及需要向微服务架构迁移，要跟踪监控的实例程序数量激增。
如果说位于数据中心的服务器是宠物，需要我们不断关注的话，那么云实例则更像牛（因为有很多，你不必关心单个实例），而容器则更像小蜜蜂。它们数量很多，有时每台机器有数百个容器，并且新的容器一直不断出现，当与诸如Kubernetes的容器编排引擎一起使用时，它们的寿命可能非常短。这使得跟踪监控它们变得更加困难，而且如果你不小心误操作的话，它们可能会造成很多损害。
随着复杂性和分布式环境的增加，你需要监控的实体数量也在增加。此外，你可能希望监控更多属性以确保你对正在发生的事情有准确的了解，或者在进行故障排除或事件响应的情况下，可以了解正在发生的事情。在短暂的环境中，后者尤其成问题，因为当你想了解问题的根本原因时，通常相关的资源已经停用，这意味着监控解决方案必须提供一种能够存储足够的历史记录以进行取证的方法。
越来越多需要云监控的团队正在转向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中共享。然而，与任何数据密集型分布式系统一样，它们需要大量的技能和资源才能运行。
对于那些以Prometheus为起点，然后寻求商业化解决方案以获得全局监控的公司来说，重要的是，不丢失Prometheus上完成的所有标准化开发工作——dashboard、告警、exporter等。然而，这不是需要考虑的唯一事情，如果你继续使用Prometheus，需要坚持以下标准：
你的供应商/所使用的工具/SaaS解决方案需要能够使用任何可产生Prometheus指标的实体程序中消耗数据，无论是本地Kubernetes还是云服务。相对来说，消耗Prometheus指标微不足道，但是也不要忽略一些小事情，例如将指标提取到存储中或增加数据时能够重新标注指标，这样对你的环境更有意义。这些小事加起来，能够收集到的数据将会堆积如山、大不相同。
Prometheus查询语言由Prometheus创建者发明，用于提取存储在Prometheus中的信息。PromQL能让你查询指定服务或指定用户的指标，它还能汇总或细分数据。例如，你可以使用它显示所有容器中每个应用的CPU使用率。或者仅显示Cassandra容器的数据，并将其显示为每个集群的单个值。可以说，PromQL释放了Prometheus的真正价值，因此如果将Prometheus的指标集成到一个不完全支持PromQL的产品中，就完全违背了使用Prometheus的初衷。
要真正与Prometheus兼容，该解决方案必须能够支持热插拔，以便能够与你现有的dashboard、告警和脚本一起使用。例如，许多使用Prometheus的企业都将Grafana用于dashboard。这个开源工具能够与Prometheus很好地集成在一起，包括在查询级别，并且可以用于生成一系列有用的图表和dashboard。因此，声称与Prometheus兼容的商业产品应与Grafana等工具兼容。仅仅说解决方案可以让你在Grafana中查看数字是远远不够的，你需要能够按照原样提取现有的Grafana dashboard，并将它们重新应用于商业解决方案中已安装的数据。
在评估工具时，访问控制是另一个你需要考虑的安全问题。能够使用行业标准协议（包括LDAP、Google Oauth、SAML和OpenID）保护用户身份验证，使公司能够通过基于服务的访问控制来隔离和保护资源。
Kubernetes简化了部署、弹性伸缩和管理容器化应用程序和微服务。这有助于保持服务的正常运行，但是要识别和解决诸如性能降低、部署失败和连接错误之类的根本问题，你需要能够从整个环境中收集和可视化基础架构、应用程序和性能数据。由于无法同时访问实时信息和上下文数据，因此几乎不可能关联环境中的指标，所以你可以更快地解决问题。
最后，如果你正在寻找商业解决方案来帮助解决Prometheus可扩展性问题，请确保它支持所有级别的告警。能够实现这一目标的关键是全面支持Alert Manager功能，而Alert Manager还要求100%的集成和 PromQL兼容性。
如果你找到一个能够满足以上标准的商业化工具，你应该能够轻松将其集成到现有的Prometheus中，并且能够避免公司遇到的可扩展性问题。开发人员有充分的理由喜爱Prometheus，因此在采用商业化方案之前进行全面、尽职的调查将确保他们仍然可以使用自己喜欢的指标。
基于Kubernetes的DevOps实战培训将于2020年6月19日在上海开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：容器特性、镜像、网络；Kubernetes架构、核心组件、基本功能；Kubernetes设计理念、架构设计、基本功能、常用对象、设计原则；Kubernetes的数据库、运行时、网络、插件已经落地经验；微服务架构、组件、监控方案等，点击下方图片或者阅读原文链接查看详情。
标签:
