prometheus Prometheus架构与实践分享

普罗米修斯已经广泛应用于数据中心监控，尤其是结合库伯内特的集装箱监控。本文主要介绍普罗米修斯从建筑分析到登陆实践的原理和应用。比较普罗米修斯和其他监控工具。然后介绍了普罗米修斯和库本内特斯的集成，主要从监控和自动缩放两个方面。最后，通过企业案例，分享实践经验和注意事项。

自2014年开源以来，Kubernetes迅速成为容器管理领域的领导者。是Google Borg系统的开源实现。除了Kubernetes之外，另一个开源项目普罗米修斯是Google BorgMon的开源实现。

2016年，谷歌发起的Linux基金会下的云原生计算基金会将普罗米修斯列为其第二大开源项目。普罗米修斯在开源社区也很活跃，GitHub上有两万多Star，每隔一两周就会更新一个小版本的系统。

普罗米修斯是SoundCloud开发的开源监控报警系统和时间序列数据库。从字面上看，普罗米修斯由两部分组成，一部分是监控和报警系统，另一部分是它自己的时间序列数据库。

上图是普罗米修斯的整体架构图，左侧是符合普罗米修斯数据格式的各种导出器。此外，为了支持代理推送数据类型，可以通过推送网关组件将推送转换为推送。普罗米修斯甚至可以从其他普罗米修斯那里获取数据，组成联邦集群。普罗米修斯的基本原理是通过HTTP周期性的抓取被监控组件的状态。任何组件只要提供相应的HTTP接口，符合普罗米修斯定义的数据格式，就可以访问普罗米修斯监控。

上层是服务发现，普罗米修斯支持监控对象的自动发现机制，可以动态获取监控对象。

图片中间是普罗米修斯服务器。检索模块定期提取数据，并通过存储模块保存数据。PromQL是普罗米修斯提供的查询语法。PromQL模块通过解析语法树调用Storage模块的查询接口获取监控数据。图片右侧是报警和页面显示。普罗米修斯将警报推给alertmanger，然后通过alertmanger处理警报并执行相应的动作。除了普罗米修斯的WebUI，还可以通过Grafana等组件查询普罗米修斯的监控数据。

在普罗米修斯出现之前，市场上已经出现了很多监控系统，比如Zabbix和Open-Falcon。那么普罗米修斯和这些监控系统有什么异同呢？让我们简要回顾一下这些监控系统。

Zabbix是分布式监控系统，由Alexei Vladishev开放。支持多种采集方式和客户端，还支持SNMP、IPMI、JMX、Telnet、SSH等协议。它将收集的数据存储在数据库中，然后对其进行分析和排序。如果符合报警规则，则触发相应的报警。

Zabbix的核心组件主要是Agent和Server，其中Agent主要负责收集数据，并通过主动或被动的方式发送给Server/Proxy。此外，为了扩展监控项目，代理还支持执行自定义脚本。服务器主要负责接收Agent发送的监控信息，汇总存储，触发报警等。

为了快速高效地配置Zabbix监控项目，Zabbix提供了一个模板机制来达到批量配置的目的。

Zabbix服务器将收集的监控数据存储在Zabbix数据库中。Zabbix数据库支持常用的关系数据库，如MySQL、PostgreSQL、Oracle等。，默认为MySQL。Zabbix网页负责数据查询。由于Zabbix使用关系数据存储时间序列数据，因此在监控大规模集群时往往会缺少数据存储。为此，Zabbix在4.2版以后也开始支持时序数据存储，但目前还不成熟。

Open-Falcon是小米的开源企业级监控工具，用Go语言开发。互联网公司包括小米、滴滴、美团等。正在使用它。这是一个灵活、可扩展和高性能的监控解决方案。主要组件包括:

Falcon-agent：用Go语言开发的Daemon程序，运行在每台Linux服务器上，用于采集主机上的各种指标数据，主要包括CPU、内存、磁盘、文件系统、内核参数、Socket连接等，目前已经支持200多项监控指标。并且，Agent支持用户自定义的监控脚本。Hearthbeat server：简称HBS心跳服务，每个Agent都会周期性地通过RPC方式将自己的状态上报给HBS，主要包括主机名、主机IP、Agent版本和插件版本，Agent还会从HBS获取自己需要执行的采集任务和自定义插件。Transfer：负责接收Agent发送的监控数据，并对数据进行整理，在过滤后通过一致性Hash算法发送到Judge或者Graph。Graph：RRD数据上报、归档、存储的组件。Graph在收到数据以后，会以RRDtool的数据归档方式来存储，同时提供RPC方式的监控查询接口。Judge：告警模块，Transfer转发到Judge的数据会触发用户设定的告警规则，如果满足，则会触发邮件、微信或者回调接口。这里为了避免重复告警引入了Redis暂存告警，从而完成告警的合并和抑制。Dashboard：面向用户的监控数据查询和告警配置界面。

下表从多个维度展示了它们各自的优缺点:

从开发语言的角度来看，为了满足高并发和快速迭代的要求，监控系统的开发语言已经慢慢从C语言转移到了Go。不得不说，Go以其简洁的语法和优雅的并发性，在Java占据业务开发、C占据底层开发时，准确定位中间件开发需求，在当前开源中间件产品中得到广泛应用。

从系统成熟度来看，Zabbix是一个老的监控系统:Zabbix出现于1998年，系统功能稳定，成熟度高。普罗米修斯和开路猎鹰是近几年才诞生的。虽然他们的功能还在迭代更新，但是他们站在巨人的肩膀上，学习了架构设计中很多老监控系统的经验。

在系统可扩展性方面，Zabbix和Open-Falcon都可以定制各种监控脚本，Zabbix既可以主动推送，也可以被动拉取，而普罗米修斯定义了一套监控数据规范，通过各种导出器扩展系统获取能力。

从数据存储方面来说，Zabbix使用关系数据库进行保存，极大地限制了Zabbix集合的性能。Open-Falcon使用RDD数据存储，可以连接OpenTSDB，而普罗米修斯开发了一套高性能的时间序列数据库，在V3版本中可以实现每秒数千万的数据存储，并通过连接第三方时间序列数据库扩展了历史数据的存储。

从配置和维护的复杂程度来看，普罗米修斯只有一个核心服务器组件，一个命令就可以启动。相比之下，其他系统配置起来相对麻烦，尤其是Open-Falcon。

社区活跃度方面，目前Zabbix社区活跃度比较低，虽然Open-Falcon也比较活跃，但基本都是国内公司参加。普罗米修斯在这方面有着绝对的优势，拥有最高的社区活跃度和CNCF的支持，其后期发展值得期待。

从容器支持的角度来说，因为Zabbix出现的比较早，当时容器还没有诞生，自然对容器的支持也比较差。open-猎鹰提供集装箱监控，但支持有限。普罗米修斯的动态发现机制不仅可以支持Swarm原生集群，还可以支持Kubernetes容器集群监控，是目前最好的容器监控解决方案。Zabbix在传统的监控系统中有着绝对的优势，尤其是在与服务器相关的监控方面。随着集装箱的发展，普罗米修斯已经成为集装箱监控的领先标准，并将在可预见的未来得到广泛应用。总的来说，通过比较各种监控系统的优缺点，普罗米修斯可以说是监控领域最犀利的“瑞士军刀”。

标准格式分为两部分:一部分是指标名称，另一部分是指标标签。标签可以反映指标的维度特征，用于过滤和聚合。它以键值对的形式形成各种维度，如标签名和标签值。例如，指标http_request_total可以有两个标记:{status="200 "，method="POST"}和{status="200 "，method="GET"}。当您需要获取GET和POST返回200的请求时，可以分别使用上述两个指标。当你需要得到所有返回200的请求时，可以通过http _ request _ total { status = " 200 " }完成数据聚合，非常方便和通用。

有四种类型的指示器:

Counter（计数器）：计数统计，累计多长或者累计多少次等。它的特点是只增不减，譬如HTTP访问总量。Gauge（仪表盘）：数据是一个瞬时值，如果当前内存用量，它随着时间变化忽高忽低。如果需要了解某个时间段内请求的响应时间，通常做法是使用平均响应时间，但这样做无法体现数据的长尾效应。例如，一个HTTP服务器的正常响应时间是30ms，但有很少几次请求耗时3s，通过平均响应时间很难甄别长尾效应。Histogram（直方图）：服务端分位，不同区间内样本的个数，譬如班级成绩，低于60分的9个，低于70分的10个，低于80分的50个。Summary（摘要）：客户端分位，直接在客户端通过分位情况，还是用班级成绩举例：0.8分位的是，80分，0.9分为85分，0.99分为的是98分。

普罗米修斯通过HTTP接口从各种客户端获取数据，这些客户端必须符合普罗米修斯监控数据格式。通常有两种方式，一种是侵入式的埋点监控，通过在客户端上的集成，如果kubernetes API直接引入普罗米修斯go客户端，提供/metrics接口来查询Kubernetes API的各种索引；另一种是通过导出器将各种中间件的监控支持对外转换成普罗米修斯的监控数据格式，例如redis导出器将Reids索引转换成普罗米修斯可以识别的HTTP请求。

HTTP返回头和体，如上图所示。指标的前两行#是注释，用于标识指标的含义和类型。指标及其值除以空。开发人员通常不需要自己拼接这些数据。普罗米修斯提供各种语言的SDK支持。

普罗米修斯不采用json数据格式，而是采用文本/纯文本，这是它的特色。

普罗米修斯提供了一个支持各种中间件和第三方监控的导出器，可以理解为一个监控适配器，将不同指标类型和格式的数据统一转换成普罗米修斯可以识别的指标类型。

比如Node exporter主要读取Linux的/proc和/sys目录中的系统文件，获取操作系统运行状态，reids exporter通过Reid命令行获取指标，mysql exporter通过读取数据库监控表获取mysql性能数据。他们将这些异构数据转换成标准的普罗米修斯格式，并提供HTTP查询接口。

普罗米修斯提供了两种数据持久化方式:一种是本地存储，通过普罗米修斯的TSDB将数据保存到本地磁盘。出于性能原因，建议使用SSD。但是本地存储的容量毕竟有限，建议保存数据不要超过一个月。普罗米修斯本地存储经过多年改进，TSDB从普罗米修斯2.0开始提供的V3版本性能非常高，可以支持单台机器每秒1000w指标的采集。

普罗米修斯的本地数据存储能力受到了大家的批评，但普罗米修斯的本地存储设计最初是为了监控数据查询而设计的，Facebook发现85%的查询是针对26小时内的数据。因此，普罗米修斯本地时间序列数据库设计更关注高性能，而不是分布式大容量。

另一种是远程存储，适合存储和查询大量历史监测数据。普罗米修斯通过中间层适配器的转换将数据保存到远程存储。该适配器实现了普罗米修斯存储的远程写和远程读接口，并将数据转换为远程存储支持的数据格式。目前远程存储主要有OpenTSDB、InfluxDB、Elasticsearch、M3DB等。M3DB是目前非常流行的后端存储。

除了自己的WebUI，普罗米修斯数据可以通过Grafana显示，本质上都是通过HTTP+PromQL查询普罗米修斯数据。类似于关系数据库中的SQL，普罗米修斯还内置了数据查询语言PromQL，为时序数据提供了丰富的查询、聚合和逻辑运算能力。

数据操作包括:

+（加法）-（减法）*（乘法）/（除法）%（求余）^（幂运算）

汇总包括:

sum（求和）min（最小值）max（最大值）avg（平均值）stddev（标准差）stdvar（标准差异）count（计数）count_values（对value进行计数）bottomk（后n条）topk（前n条）quantile（分布统计）

如果需要在某个时间获取数据，可以使用curl ' http://Prometheus address:9090/API/v1/query？query = up & ampTime=xx '查询监控数据，其中查询参数为PromQL表达式。此外，还支持query_range，需要增加以下参数:开始、结束、步长=。

PromQL引擎收到请求参数后，解析PromQL，确定查询的数据顺序和时间范围，通过tsdb接口获取相应的数据块，最后根据聚合函数处理监控数据并返回。

如果监控数据达到报警阈值，普罗米修斯服务器将通过HTTP向报警模块报警者发送报警。普罗米修斯报警配置也是通过yaml文件，核心是上面的expr表达式也是类似查询的PromQL表达式。代表持续时间。如果普罗米修斯在规定时间内被连续触发，就会发出警报。

报警组件的报警者地址在普罗米修斯配置文件中指定，报警者重复并抑制报警，最终执行报警动作。目前支持邮件、slack、微信、webhook。如果是屁股钉钉，可以通过webhook触发钉钉客户端发送报警。

为了扩大单个普罗米修斯的收集和存储能力，普罗米修斯引入了“联邦”的概念。多个普罗米修斯节点形成了一个两层的联邦结构。如图所示，上层是一个联邦节点，负责定期从下层普罗米修斯节点获取和汇总数据。部署多个联合节点以实现高可用性以及数据聚合和存储。较低的普罗米修斯节点负责不同区域的数据收集。在部署多个机房的情况下，每个较低的普罗米修斯节点可以部署到一个单独的机房作为代理。

不可思议的开源灭霸提供了普罗米修斯集群能力，感兴趣的朋友可以深入了解。

普罗米修斯的流行与库本内特密切相关。在这里我们将介绍如何通过普罗米修斯来监控库本内特斯集群。首先，介绍了普罗米修斯的自动发现机制。

普罗米修斯有两种方式配置监控对象，一种是通过静态文件配置，另一种是动态发现机制。

目前动态发现已经支持Kubernetes，etcd，Consul等服务。动态发现可以减少运维人员的手工配置，在集装箱运行环境中尤为重要。集装箱集群通常在几千甚至几万的规模。如果每个容器都需要独立配置监控项目，不仅需要大量的工作，而且容器会频繁更换，后续的维护会非常麻烦。普罗米修斯根据Kubernetes环境的动态发现，通过Watch Kubernetes API动态获取当前集群中所有主机、容器和服务的变化。

通过自动发现机制，普罗米修斯可以动态获取节点和Pod的变化，并将节点导出器和cAdvisor添加到监控中。集装箱的常见监控指标包括:

CPU利用率:

rate

内存使用:

container_memory_usage_bytes{container_name="xxx", pod_name="xxx"}-container_memory_cache{container_name="xxx", pod_name="xxx"}

网络发送速率:

rate

网络接收速率:

rate

普罗米修斯操作器和其他库伯内特操作器一样，定义了以下四种库伯内特的CRD资源，通过操作库伯内特资源来达到管理普罗米修斯的监控和报警的目的。

Prometheus：Prometheus Deployment定义ServiceMonitor：Prometheus监控对象的定义PrometheusRule：告警规则Alertmanager：Alertmanager Deployment定义

HPA是由Kubernetes提供的横向扩展服务，它本身支持基于CPU利用率的扩展。如果用户希望根据自定义指标扩展容量，可以使用库本内特的自定义指标应用编程接口。

Kubernetes资源通常有两种扩展方式，一种是上面运营商使用的CRD，另一种是聚合API Server。定制度量apiserver是一个定制度量接口，它通过聚合API扩展了Kubernetes。

HPA查询自定义监测数据的请求通过kube-apiserver发送到自定义-metrics-apiserver，并通过prometheus-adapter转化为Prometheus数据的查询，从而实现自定义指标的伸缩。

CreditEase容器云是CreditEase基于Kubernetes搭建的容器管理平台。用户只需在平台上点击一下，就可以部署自己的服务。平台的主要功能包括服务管理。)，图像管理，监控报警，CICD，Nginx管理，Ceph存储等多项功能。其中监控、报警、自动缩放都是基于普罗米修斯的。

普罗米修斯收集的数据包括主机性能监控、容器性能监控、Nginx访问流量、Kubernetes状态和平台各组件的性能指标。目前普罗米修斯本地数据保留一个月，历史数据保存在M3DB。

普罗米修斯为页面提供性能指标查询，如nginx qps和容器CPU利用率，并基于这些指标提供性能告警。警报被发送到alertmanger，ipaas被触发，通过alertmanger的网络钩子执行后续的警报处理。

为了支持多索引、多集群的容器自动缩放，平台开发了自动缩放模块，通过cluster-mgr定期获取普罗米修斯监控指标，模仿Kubernetes的HPA计算目标容器副本数，最后通过调用ipaas扩展多个集群的容器副本。

最后，我个人想表达的是，普罗米修斯不是银弹。

首先，普罗米修斯只专注于性能和可用性监控，没有日志监控等功能，无法通过普罗米修斯解决所有监控问题。

其次，普罗米修斯认为只需要查询最新的监测数据，所有的普罗米修斯本地存储都是为了保存短期的数据，而不是为了存储大量的历史数据。如果需要报表等历史数据，建议使用普罗米修斯的远程存储，比如OpenTSDB和M3DB。

普罗米修斯还有一个小缺陷，就是没有定义单位。在这里，用户需要预先区分或定义所有的监测数据单元，以避免数据缺少单元的问题。

问答。A

问:现在有高可用性解决方案吗？

答:普罗米修斯联盟或不可思议的开源灭霸是高度可用的解决方案。

问:普罗米修斯占用了大量内存。在我们的环境中，45w索引占用8G左右的内存，普罗米修斯容器OOM经常出现。有什么方法可以优化内存占用？

答:如果数据索引真的很大，可以考虑普罗米修斯的hash集合分担压力。在生产过程中，可以省略很多索引，比如Kubernetes中的Sandbox容器的索引。

问:相比于Q:普罗米修斯的推模式和拉正常模式的性能，哪个更好？

答:推送网关本身就是一个数据转发代理，性能损失很小。建议直接提供普罗米修斯拉支撑。

问:一些公司自己业务的过程数据监控依赖于自己开发的连续报告吗？还是什么三方客户？

答:如果可以二次开发，建议直接在代码中加入普罗米修斯收藏支持。除了Go，还有Java和Python的SDK支持。如果不可能二次开发，也可以由出口商对外完成。

问:如果CPU利用率有多个副本，那么container_name就有问题？另外，不同版本的Pod如何比较自己的CPU利用率？另外，直方图的度量有分析过吗？查询一个月的数据应该压力挺大的，还是需要优化？

答:多个副本需要一个组。普罗米修斯中存储了不同版本的数据，可以通过容器名称聚合进行查询，每月的数据步长可以调整得更大。目前一个月内查询基本控制在2s以内。发布之后，Pod的名字就不一样了。一种方法是保留容器名称，另一种方法是使用前缀和正则匹配。我用的是后者，但是会有很多空行，因为这个Pod名称标签的度量在之前的版本中是不存在的，这和多副本容器_name有些冲突。指标名称要固定，定期匹配不会有问题，历史会查出来。另外，我发现直方图的度量在7天以上就没有参考价值了，一个月的查询意义不大。比如普罗米修斯_ http _ request _ duration _ seconds，度量还是以实时为主。

问:时间序列数据库和传统数据库有什么优势？型号应该怎么选？

答:时间序列数据是随时间变化的量，查询也是时间维度，从而达到高压缩比。关系数据的优势在于数据管理。

问:比如统计每天用户登录次数，具体应该怎么做？需要哪些流程和步骤？

答:需要在程序中集成SDK，提供http接口查询累计登录用户，并在普罗米修斯中配置这个目标。