用户您好!请先登录!

普罗米修斯的架构与挑战

普罗米修斯的架构与挑战

普罗米修斯(Prometheus)是现在重要的云原生监控平台之一,它允许企业从任何基础设施或应用组件收集和处理指标数据,用于监控容器化工作负载。它与Kubernetes和云原生生态系统中的其他组件集成,通过监控数据可以帮助企业收集和处理四种类型的指标:计数器(counter),量规(gauge),直方图(histogram)和摘要(summary)。Prometheus数据模型反映了Kubernetes基础架构元数据,使其成为Kubernetes监控的自然选择。

什么是普罗米修斯?

普罗米修斯是为大型环境设计的开源监控和警报解决方案,通常用于包含容器和容器化工作负载的环境中。它以较低的系统资源要求实现了丰富的自定义和灵活的查询。如果需要,它还可以通过一台服务器同时从数千台计算机中获取大量数据。

普罗米修斯最初于2012年在SoundCloud上创建,来克服当时使用的解决方案局限性。随后,进展到多个普罗米修斯服务器整合来支持任何环境的进一步发展。

用于Kubernetes监控的普罗米修斯

普罗米修斯的最初灵感来自Google Borg Monitor项目。众所周知,Google Borg是Kubernetes的前身,为创建现代容器编排打下了基础。现在普罗米修斯是云原生计算基金会CNCF的毕业项目之一(目前,CNCF已毕业的项目有11个),普罗米修斯打跟上就是为构建监控Kubernetes基础设施而生的。

特别是,普罗米修斯具有与Kubernetes非常匹配的几个特征。包括:

数据模型。普罗米修斯使用多维数据模型,其中指标作为时间序列数据存储在键值对中,这反映了如何使用标签将基础结构元数据存储在Kubernetes中。

可访问的数据格式和协议。指标满足我们阅读习惯的格式显示,无需在使用前转换数据。要访问指标,只需要通过HTTP连接即可,这意味着我们可以使用各种工具轻松查看指标。

服务发现。除了从明确指定的目标获取指标之外,普罗米修斯还内置了对使用多种方法自动发现新目标的支持。这在动态协调的环境中尤其重要,在动态环境中,可以动态生成和停用各种服务的Pod。

普罗米修斯监控的工作原理

普罗米修斯由保存在单个服务器上的三个主要组件构成:时间序列数据库,数据检索worker和Web服务器。数据检索worker用于发现Kubernetes中的目标,并从正在进行的作业或用于短期作业的推送网关中获取指标,然后将这些指标推送到数据库。从那里,可以通过HTTP访问指标以进行查询和警报。

普罗米修斯监控的4个指标

监控时,普罗米修斯可以处理四种类型的指标。分别是:

计数器。只能增加或重置为零的累积指标。对于完成任务,错误或请求数量之类的措施很有用。

量规。可以增加或减少的时间点指标。对于并发请求或当前内存使用情况等措施很有用。

直方图。一种指标,用于对数据进行采样并将观察结果分类为自定义组。对于诸如请求持续时间,或响应大小之类的聚合指标很有用。它还可以显示Apdex分数,用于评估应用程序的性能和用户满意度。

摘要。一种指标标准,可对数据进行采样并返回观测值的总数,值的总和以及观测值的四分位数。普罗米修斯摘要对于获得具有统计意义的四分位数的指标概述非常有用。

普罗米修斯架构

为了稳定运行,普罗米修斯必须将各种组件集成到其架构中。由于它的灵活性,这些组件会因我们的具体实现而异,但是应始终包含以下的元素。

详解开源监控系统普罗米修斯的架构与挑战

客户端库

客户端库可以将直接检测添加到服务代码中。然后,它会根据普罗米修斯的指标类型返回指标数据。

库已经可以用于大多数流行语言,包括Go,Java,Python和Ruby。还可以创建自己的客户端库或使用exposition格式,该格式以原始文本显示指标。

导出器(Exporter)

导出器能够从无法添加直接检测的服务和组件中收集数据,因为你没有代码访问权限。例如,数据库,操作系统内核,路由器或云资源。有众多官方支持的导出器以及第三方导出器。

导出器与服务同时运行,并充当普罗米修斯与服务之间的代理。这些工具接受普罗米修斯请求,从服务中收集数据,将数据转换为正确的格式,然后将其返回给数据检索worker。

服务发现

普罗米修斯既可以静态配置指标目标,也可以通过服务发现机制动态定位目标。这样可以确保在整个系统中收集指标,同时涵盖业务流程创建者动态创建,以及停用的所有组件和资源。

为了完成服务发现,普罗米修斯允许我们与许多现有方法集成,包括Kubernetes,HashiCorp Consul和所有主要云提供商所使用的方法。

抓取(Scraping)

在普罗米修斯中,抓取是从端点收集指标的实际过程。当普罗米修斯的数据检索worker通过HTTP发送抓取请求时,即可完成这项操作。当仪器库(instrumentation)或导出器收到这些请求时,将发送包含适当数据的响应。

通常,响应还附带特定的抓取数据。该数据可以包括请求花费了多长时间,以及抓取是否成功。

存储

普罗米修斯包括在本地磁盘时间序列数据库上的持久存储,还可以通过远程读/写API将其与远程存储集成。

在持久性存储中,数据被分为两个小时的块,最终进行压缩。收集数据时,会将其存储在内存中并通过预写日志(WAL)进行记录,以防止由于服务器故障而造成的丢失。

PromQL

PromQL是一种查询功能的查询语言,用于从普罗米修斯数据库中选择和汇总时间序列数据。

记录规则和警报规则

普罗米修斯支持以下两种类型的规则,每种规则基于针对两个不同用例的PromQL查询:

记录规则会定期评估PromQL表达式,并将结果存储为单独的时间序列。这有助于分发汇总指标所需的工作,并加快计算复杂查询的可视化呈现时间。

警报规则再次定义构成警报的条件,就像PromQL查询一样。通过与外部警报工具集成来发出实际警报。普罗米修斯发送规则中定义的PromQL查询的结果,并通过我们首选的通信路径分发这些结果,或者以任何其他方式“处理”警报。用于通知管理员特定情况发生的最常见的警报工具有Slack,PagerDuty,OpsGenie和VictorOps等。

仪表板

普罗米修斯能够以几种不同的方式访问所收集时间序列数据的可视化。如可以使用内置的表达式浏览器进行即时查询和调试。但是,对于更广泛的报告,应该使用Grafana,控制台模板或其他能够从普罗米修斯检索数据的可视化工具。

使用普罗米修斯面临哪些挑战?

普罗米修斯用于监控Kubernetes和其他环境的强大工具,但并非没有挑战。这里总结了一些,供大家参考。

存储。Prometheus所需的存储容量与要收集的指标标准和频率有直接关系。根据Kubernetes部署的大小,所需的存储量可能会迅速超过现有资源。解决这个问题没有绝对的办法。在预估资源时请注意这点。通过专用的普罗米修斯适配器使用第三方存储时,可以应用各种数据维护和生命周期策略。

冗余。普罗米修斯使用单节点数据库来确保数据完整性。但是,这不允许冗余,并且如果磁盘发生故障,则可能导致数据丢失。要解决此问题,可以通过异步方法在外部复制数据,也可以运行普罗米修斯服务器的镜像。虽然都不是最佳的解决方案,但是两者都可以提供冗余。此外,还存在更复杂的普罗米修斯服务器集成的技术。

没有事件驱动的指标。由于指标是被抓取(而不是推送)的,因此我们无法轻松实现事件驱动的指标。但是,可以使用普罗米修斯的Push Gateway收集由短期作业或批次推送的指标。为了模拟事件驱动的指标,可以频繁地scrape网关,尽管这可能会使服务器承压,但可以产生有用的数据。

分段网络访问。根据我们的服务,可能会遇到访问限制或缺少外部访问的情况。对于指标范围,这通常需要多个普罗米修斯实例。要查看这些指标,然后需要访问不同的Grafana仪表板以使用联邦(Federation)将指标从你的实例聚合到单个服务器。

长期存储。普罗米修斯提供本地存储,但不适用于长期存储。如果选择长期保留指标,则可能会严重降低查询性能。为避免这种情况,需要使用记录规则对指标数据进行细分,或者可以集成Thanos或Cortex等分布式数据库。

结论

无可争议,普罗米修斯现在是基于指标的开源监控解决方案的领导者。生态不断增长,并与不少强大的商业解决方案结合。普罗米修斯的成功实施是软件服务的运营,以及可靠性的基础。此外,可以以适合DevOps范例的方式完成与普罗米修斯的合作,同时满足了基础架构即代码(IaC)的管理指标和规则。

行走的code
行走的code

要发表评论,您必须先登录