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

做者简介

Loris Degioanni，Sysdig的创始人和CTO，同时仍是容器安全工具Falco的建立者。

原文连接
https://thenewstack.io/6-things-to-consider-in-a-prometheus-monitoring-platform/

本文转自Rancher Labs

当前，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，须要坚持如下标准：

一、 兼容性，以支持全部Prometheus功能

你的供应商/所使用的工具/SaaS解决方案须要可以使用任何可产生Prometheus指标的实体程序中消耗数据，不管是本地Kubernetes仍是云服务。相对来讲，消耗Prometheus指标微不足道，可是也不要忽略一些小事情，例如将指标提取到存储中或增长数据时可以从新标注指标，这样对你的环境更有意义。这些小事加起来，可以收集到的数据将会堆积如山、大不相同。

二、 PromQL兼容性

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，所以在采用商业化方案以前进行全面、尽职的调查将确保他们仍然可使用本身喜欢的指标。