Prometheus 搭配 Elastic Stack,助力实现大规模监测

工具。身为工程师,我们都喜欢优秀的工具,因为它们能帮助我们的团队高效工作,更快速地解决问题,并变得越来越好。但工具的数量越来越多,工具还需要进行额外维护,最重要的一点,工具会造成孤岛。每个团队都有特定责任并且也一直在不断地搜索相关工具,以求通过最佳方法满足具体要求。因此,虽然每个团队单独来看都提高了效率,但这种仅关注性能的自主性却会造成一个不良后果,即对公司/组织的其他领域缺乏了解。将此不良后果乘以团队数量,您很快就发现这样会造成集群相互隔离,让您无法整体查看公司的运行状况。 

Prometheus 堪称良好工具的典范。它很快就成了人们在容器系统监测和告警领域的热门工具。它的主要优势在于能够高效地监测和存储服务器端指标。Prometheus 是一款完全开源的工具,拥有十分活跃的社区,并且以导出工具的形式将其使用范围扩展至很多第三方系统。和大部分专业工具一样,Prometheus 的宗旨是让用户轻松简单地完成操作。这一简单性也有一些弊端,针对大型部署和跨团队协作这一弊端尤其明显。在此篇博文中,我们将会研究其中的某些弊端,并了解如何借助 Elastic Stack 来克服这些难题。

长期数据保留

Prometheus 将数据存储在本地(即实例内)。将计算和数据存储整合到一个节点上固然能简化操作,但也会加大扩展难度,还会导致难以确保高可用性。因此,Prometheus 即使优化后也并非长期指标存储工具。在 Prometheus 中,时序型数据的最佳保留率可能会短至几天甚至几小时,具体取决于您环境的规模。

如要以可扩展的持久方式保留 Prometheus 数据来进行长期分析(例如时序型数据的季节性),您将需要一套长期存储解决方案来配合 Prometheus 一起使用。有很多解决方案可供选择,例如其他的专业时序数据库 (TSDB) 或已针对时序数据进行优化的列式数据库。这些解决方案尽管能够高效存储指标,但却有一个共同缺点,即它们只专门针对一种数据类型——指标。对于帮助理解系统运行状况,指标当然发挥着极其重要的作用,但要想系统实现可观测性,指标也只是一部分内容而已。

考虑可观测性时,用户通常会尝试将其他类型的运行数据(例如日志和跟踪数据)与指标一同囊括进来。在我们关于 Elastic Stack 中的可观测性的博文中,我们提到过用户在采用 Elastic Stack 处理日志之后,对于越来越多的用例也开始将指标、跟踪数据和运行状态数据添加到 Elasticsearch 中。毫无疑问——对于所有这些数据类型,Elasticsearch 只是将它们看做另一个索引,并允许您以任意方式对全部运行数据进行汇总、关联、分析和可视化。Elastic 中的诸如数据汇总等功能可让您以极低成本(仅为存储原始数据的成本的几分之一)存储之前的时序型数据。

Elastic 可观测性:日志 + 指标 + APM 跟踪数据 + 运行状态数据

那么,对于为 Prometheus 选择长期存储方案而言,这意味着什么呢?您可以选择专门的指标存储工具来保存更长时间内的 Prometheus 指标,但这可能会创建另一个孤岛。或者,您可以选择 Elastic Stack 来同时实现两个目标:飞速运行 Prometheus,还能在可扩展的集中型 Elasticsearch 部署中存储指标以及您的其他运行数据,想存多久存多久。这意味着既可以长期存储数据,能够增强可观测性。

针对 Prometheus 数据的集中式全局视图

在生产环境中,您可能管理着多个 Kubernetes 集群。每个集群会运行一个或多个 Prometheus 实例,通过这些实例便可以查看节点、Pod、服务和端点的运行状况。缺了点什么吗?

一个 Prometheus 实例可以覆盖您环境中的一个资源子集。但如果您问的问题需要从多个集群查询指标,则 Prometheus 无法直接实现此目的。 

使用 Elasticsearch 进行长期监测和保留

将 Elastic 作为集中存储工具后,您能够整合数百个 Prometheus 实例中的数据,并对来自所有资源的数据实现全局查看。Metricbeat 中的 Prometheus 模块能够自动从 Prometheus 实例、Push Gateway、导出工具以及支持 Prometheus 阐释格式的几乎所有其他服务中采集指标。最棒的一点是,您无需在生产环境中进行任何变更——纯粹的即插即用型体验。

高基数维度

为什么“高基数”如此重要?高基数能够让您以标签或标记的形式为指标添加任意上下文。大部分情况下,您都想保留这一元数据,因为在对服务进行故障排查时这些元数据能够发挥巨大的帮助作用。所有这些跟踪 ID、请求 ID、容器 ID、版本号等信息始终可以帮助您详细了解系统中发生的事情。


单纯的时序数据库 (TSDB) 在处理低基数维度时,效果非常好。专业 TSDB 宣称其在存储效率方面要优于 Elasticsearch,但这有一个前提:需为低基数维度。Prometheus 文档强烈建议避免处理高基数数据:

注意:请记住,每个唯一的键值标记对组合都表示一个新的时序型数据,其会大幅增加所存储的数据量。不要使用标记来存储高基数维度(很多不同的标记值),例如用户 ID、电子邮箱地址,或者其他不受限制的数值集合。

这条建议真的好用吗?在分布式环境中,故障排场是一项异常复杂的任务。之前,使用大型整体模块时,故障排查过程很简单,一步步检查应用程序代码就可以了。只需查看几个仪表板,用户便能很轻松地确定哪个大型整体模块是导致问题的元凶。但现在已时过境迁。基础设施软件正在经历一次范例转移。容器、编排工具、微服务、Service Mesh(服务网格)、无服务器、Lambda——所有这些都是前景十分看好的技术,能够改变我们构建和运行软件的方式。相应地,它的分布性越来越强,所以故障排查过程就有点像侦探工作,需要在系统中找出存在问题的代码。

高基数对 Elastic 而言则全然不是问题。用户向数据添加相关上下文时,根本没有任何限制。由于 Elasticsearch 有强大的索引功能,其能让用户以任意方式、使用任何元数据为指标添加注释;通过这些元数据,用户便能尽快找到导致问题的因素并确定根本原因。

安全无虞,不分地点

我们对良好工具的期望之一就是它至少不要向我们的环境中引入安全风险。对于任何分布式部署而言,安全的两大基石都是加密通信和访问控制。

在撰写本文时,Prometheus 服务器、Alertmanager 以及官方导出工具均不支持对 HTTP 端点进行 TLS 加密。如要通过安全方式部署这些组件,您必须使用诸如 nginx反向代理,并在代理层上应用 TLS 加密。任何针对指标的基于角色的访问控制 (RBAC) 也应该在外部完成,而不能通过 Prometheus 服务器自行完成。令人欣慰的是,如果您在 Kubernetes 集群内运行 Prometheus,TLS 和 RBAC 根本不是问题,因为 Kubernetes 集群同时提供这两项功能。在所有其他用例(例如在地理分布式或混合式部署中运行数百个 Prometheus 服务器)中,使用第三方工具解决这些安全顾虑可不是一项轻松工作。

在 Elastic,我们非常重视这些风险,将安全性作为我们堆栈中不可或缺的一部分。我们在默认分发版本中免费提供基本安全选项,同时 Elasticsearch 还能让您通过多种方式确保您集群中数据的访问权限的安全性,并对集群和数据采集器之间的流量进行加密。除了 RBAC,Elasticsearch 还支持细粒度的基于属性的访问控制 (ABAC) 机制,通过这一机制您能够限制搜索查询和聚合中的文档的访问权限。通过 Metricbeat 中的 SSL 配置设置,您可以确保无论您的环境规模多大,分布多么广泛,自己的数据都能安全地进行传输。 

将 Prometheus 指标流式发送到 Elasticsearch

使用 Metricbeat,您现在便能开始将指标从 Prometheus 传输到 Elasticsearch。通过 Prometheus 模块,您能够通过多种方式从 Prometheus 服务器、导出工具或者 Push Gateway 中采集指标:

  1. 如果已在运行 Prometheus 服务器并希望直接对这些指标进行查询,您连接至 Prometheus 服务器并通过 /metrics 端点或者 Prometheus 联合 API 提取业已采集的指标,即可开始。

    使用 Prometheus 服务器时的监测架构
  1. 如果没有 Prometheus 服务器,或者不介意同时使用多个工具从导出工具和 Push Gateway 中采集数据,则您可以直接连至它们。

    未使用 Prometheus 服务器时的监测架构

运行 Metricbeat 时尽量精简其与 Prometheus 服务器之间的步骤。欢迎阅读我们的 Prometheus 和开放标准博文,并从中选择最契合您的需求的配置。

随时了解 Prometheus 服务器的运行状况

Elastic Stack 还能让您随时了解所有 Prometheus 实例的运行状况。您可以使用 Metricbeat 从环境中的每个 Prometheus 服务器上采集性能指标并加以存储。借助我们提供的开箱即用型预定义仪表板,您可以轻松查看很多内容,例如单个端点的 HTTP 请求数量、查询持续时间、所发现目标的数量,等等。

Kibana 中的 Prometheus 监测仪表板

总结

说到我们的最终目的,就是您、您的团队以及您的整个公司/组织能够取得成功。大家应该将所有工具都视为达成目标的一种方式。每个团队都应该可以自由选择有助于发挥自身全部潜力的任何工具。至于如何打破运营孤岛,我们坚信 Elastic 能够帮您构建一个终极可观测性平台,在这个平台上,贵公司/组织的每个人都能够安全地访问运行数据,与之进行交互,并重新成为一个团队。

如果希望了解我们如何处理时序型数据,请查看我们的 Elastic Metrics 网页。试试将您的指标流式传输到 Elasticsearch 服务——Elasticsearch 服务能让您无比轻松快捷地上手使用。如有任何问题,请在论坛上给我们留言。