Prometheus扩展要考虑的6件事

越来越多的组织开始使用Prometheus监视其容器和微服务领域,但慢慢地都会遇到扩展挑战。

容器使监视复杂化

过去,有限的静态物理服务器和虚拟机,以及数量有限的指标使得监控很简单直接。今天,由于容器的使用以及组织向微服务架构的迁移,要跟踪的实体数量激增,使得监控越来越复杂。

现在,云环境中有很多容器,有时每台机器上有数百个容器,同时当与Kubernetes一起使用时,它们的寿命可能非常短。这使得跟踪它们变得更加困难。

随着环境的复杂性和分布的增加,你需要监视的实体数量也在增加。

此外,我们希望监视更多属性,能够对正在发生的事情有准确的了解,以便于进行故障排除。但这在短暂的环境(如:容器)中尤其困难,因为当你想了解问题的根本原因时,通常有问题的资源已经停用,这意味着监视解决方案必须提供一种方法:存储足够的历史记录以进行取证。

Prometheus

当需要进行云监视时,团队越来越多地转向Prometheus。Prometheus已成为开发人员用来在云原生环境中收集和处理指标的首选监视工具。它由一个大型社区支持,有来自700多家公司的6,300个贡献者,13,500个代码提交和7,200个拉取请求。

默认情况下,典型的云原生应用程序(例如Kubernetes,Ngnix,MongoDB,Kafka和golang)会公开Prometheus指标。

Prometheus扩展问题

随着环境的扩大和复杂化,跟踪飞速增长的时间序列数据,单个Prometheus实例将无法跟上。

最直接的选择是在整个企业中运行大量的Prometheus服务器,但这带来了一些挑战。例如,管理和收集整合数据,单点登录,基于角色的访问控制以及遵守SLA等。

为了解决这个问题,公司采用了一些方法。

一个简单的方法就是:为每个名称空间或每个集群部署一个单独的Prometheus服务器。显然,此方法具有创建大量数据孤岛的缺点。这使故障排除变得麻烦,因为大多数问题将涉及多个服务/团队/集群。在每个环境中不仅很难找到相同的指标,而且还必须将数据拼接在一起以试图了解故障发生的事情。

另一种常见的方法是使用诸如CortexThanos之类的开源工具来联合多个Prometheus服务器。它们是功能强大的工具,使你可以集中查询服务器,收集数据,然后在单个仪表板中共享它们。但是,作为任何数据密集型分布式系统,它们都需要大量的资源来进行操作。

Prometheus扩展要考虑的6件事

对于那些以使用Prometheus开始,然后寻求扩展解决方案以提供整体支持的公司,最重要的是—不要丢失Prometheus上标准化上的所有工作-仪表板,警报, exporters 等。除此之外,还有其他扩展也需要你考虑:

Prometheus扩展要考虑的6件事:

  1. 能够使用Prometheus任何指标的数据。你的解决方案,需要能够使用Prometheus任何指标的数据。消耗Prometheus度量标准相对来说是微不足道的,但不要忽略一些小事情:例如在将度量标准放到存储中或扩充数据时能够重新标记度量标准,这样对你的环境就更有意义了。
  2. 兼容PromQL。Prometheus查询语言是Prometheus发明的,用于提取Prometheus存储的信息。PromQL使你可以提供特定服务或特定用户的指标。它还使你可以汇总或分割数据。例如,你可以使用它来显示分布在多个容器中每个应用的CPU利用率。PromQL释放了Prometheus的真正价值。因此,将Prometheus指标集成到不完全支持PromQL的产品中,将无法实现使用Prometheus的全部目的。
  3. 可热插拔(Hot-swappable)。为了与Prometheus真正兼容,该解决方案必须能够与你现有的仪表板,警报和脚本一起进行热插拔。例如,许多使用Prometheus的公司都将Grafana用于仪表板。这个开源工具与Prometheus很好地集成在一起,包括在查询级别,并且可以生成一系列有用的图表和仪表板。因此,声称与Prometheus兼容的商业产品应该与Grafana这样的工具兼容。解决方案仅仅允许你在Grafana中查看数字是不够的。
  4. 访问控制访问控制是应考虑的一个安全问题。扩展时,需要考虑能够使用行业标准协议(包括LDAP,Google Oauth,SAML和OpenID)保护用户身份验证的能力,使公司能够通过基于服务的访问控制来隔离和保护资源。
  5. 故障排除。Kubernetes简化了容器化应用程序和微服务的部署,扩展和管理。这有助于保持服务的正常运行,但是要识别和解决–诸如性能降低,部署失败和连接错误之类的根本问题,你需要具有这个能力–从整个环境中收集来自基础架构,应用程序和性能数据,并可视化的能力。如果无法同时访问实时信息和上下文数据,那就几乎不可能关联环境中的指标,因此你也不能更快地解决问题。
  6. 与现有警报的兼容性。最后,如果你正在寻找商业解决方案来帮助解决Prometheus可扩展性问题,请确保它支持所有级别的警报。实现此目标的关键是对Alert Manager功能的全面支持。

如果你发现有符合这些条件的开源或商业工具,则应该能够以最小的代价将其集成到现有的Prometheus环境中,并解决公司遇到的可扩展性问题。

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

K8S中文社区微信公众号

评论 抢沙发

登录后评论

立即登录