DockOne微信分享(二二六):Prometheus架构与实践分享


【编者的话】Prometheus已经被广泛应用于数据中心监控,尤其是和Kubernetes结合的容器监控。本文主要从架构分析到落地实践,详细介绍Prometheus原理和使用。对比Prometheus与其他监控工具(Zabbix、Open-Falcon)的特点与使用场景。然后介绍Prometheus与Kubernetes集成,主要从监控和自动伸缩两个方面。最后通过企业案例,分享实践经验和注意事项。

Kubernetes从2014年开源以来,迅速成为容器管理的领头羊,它是Google Borg系统的开源实现。和Kubernetes一起火起来的还有另一个开源项目Prometheus,它是Google BorgMon的开源实现。

2016年,由Google发起的Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation)将Prometheus纳入其第二大开源项目。Prometheus在开源社区也十分活跃,在GitHub上拥有两万多Star,并且系统每隔一两周就会有一个小版本的更新。

Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库。从字面上理解,Prometheus由两个部分组成,一个是监控报警系统,另一个是自带的时序数据库(TSDB)。
1.png

上图是Prometheus整体架构图,左侧是各种符合Prometheus数据格式的exporter,除此之外为了支持推动数据类型的Agent,可以通过Pushgateway组件,将Push转化为Pull。Prometheus甚至可以从其它的Prometheus获取数据,组建联邦集群。Prometheus的基本原理是通过HTTP周期性抓取被监控组件的状态,任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式,就可以接入Prometheus监控。

上侧是服务发现,Prometheus支持监控对象的自动发现机制,从而可以动态获取监控对象。

图片中间是Prometheus Server,Retrieval模块定时拉取数据,并通过Storage模块保存数据。PromQL为Prometheus提供的查询语法,PromQL模块通过解析语法树,调用Storage模块查询接口获取监控数据。图片右侧是告警和页面展现,Prometheus将告警推送到alertmanger,然后通过alertmanger对告警进行处理并执行相应动作。数据展现除了Prometheus自带的WebUI,还可以通过Grafana等组件查询Prometheus监控数据。

在Prometheus之前市面已经出现了很多的监控系统,如Zabbix、Open-Falcon等。那么Prometheus和这些监控系统有啥异同呢?我们先简单回顾一下这些监控系统。
2.png

Zabbix是由Alexei Vladishev开源的分布式监控系统,支持多种采集方式和采集客户端,同时支持SNMP、IPMI、JMX、Telnet、SSH等多种协议,它将采集到的数据存放到数据库中,然后对其进行分析整理,如果符合告警规则,则触发相应的告警。

Zabbix核心组件主要是Agent和Server,其中Agent主要负责采集数据并通过主动或者被动的方式采集数据发送到Server/Proxy,除此之外,为了扩展监控项,Agent还支持执行自定义脚本。Server主要负责接收Agent发送的监控信息,并进行汇总存储,触发告警等。

为了便于快速高效的配置Zabbix监控项,Zabbix提供了模板机制,从而实现批量配置的目的。

Zabbix Server将收集的监控数据存储到Zabbix Database中。Zabbix Database支持常用的关系型数据库,例如MySQL、PostgreSQL、Oracle等,默认MySQL。Zabbix Web页面(PHP编写)负责数据查询。Zabbix由于使用了关系型数据存储时序数据,所以在监控大规模集群时常常在数据存储方面捉襟见肘。为此Zabbix 4.2版本后也开始支持时序数据存储,不过目前还不成熟。
3.png

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:面向用户的监控数据查询和告警配置界面。


下表通过多维度展现了他们的各自的优缺点:
b.jpg

从开发语言上看,为了应对高并发和快速迭代的需求,监控系统的开发语言已经慢慢从C语言转移到Go。不得不说,Go凭借简洁的语法和优雅的并发,在Java占据业务开发,C占领底层开发的情况下,准确定位中间件开发需求,在当前开源中间件产品中被广泛应用。

从系统成熟度上看,Zabbix是老牌的监控系统:Zabbix是在1998年出现的,系统功能比较稳定,成熟度较高。而Prometheus和Open-Falcon都是最近几年才诞生的,虽然功能还在不断迭代更新,但站在巨人的肩膀之上,在架构设计上借鉴了很多老牌监控系统的经验。

从系统扩展性方面看,Zabbix和Open-Falcon都可以自定义各种监控脚本,并且Zabbix不仅可以做到主动推送,还可以做到被动拉取,Prometheus则定义了一套监控数据规范,并通过各种exporter扩展系统采集能力。

从数据存储方面来看,Zabbix采用关系数据库保存,这极大限制了Zabbix采集的性能,Open-Falcon采用RDD数据存储,并且可以对接到OpenTSDB,而Prometheus自研一套高性能的时序数据库,在V3版本可以达到每秒千万级别的数据存储,通过对接第三方时序数据库扩展历史数据的存储。

从配置和维护的复杂度上看,Prometheus只有一个核心server组件,一条命令便可以启动,相比而言,其他系统配置相对麻烦,尤其是Open-Falcon。

从社区活跃度上看,目前Zabbix社区活跃度比较低,Open-Falcon虽然也比较活跃,但基本都是国内的公司参与,Prometheus在这方面占据绝对优势,社区活跃度最高,并且受到CNCF的支持,后期的发展值得期待。

从容器支持角度看,由于Zabbix出现得比较早,当时容器还没有诞生,自然对容器的支持也比较差。Open-Falcon虽然提供了容器的监控,但支持力度有限。Prometheus的动态发现机制,不仅可以支持Swarm原生集群,还支持Kubernetes容器集群的监控,是目前容器监控最好解决方案。Zabbix在传统监控系统中,尤其是在服务器相关监控方面,占据绝对优势。伴随着容器的发展,Prometheus开始成为主导及容器监控方面的标配,并且在未来可见的时间内被广泛应用。总体来说,对比各种监控系统的优劣,Prometheus可以说是目前监控领域最锋利的“瑞士军刀”了。
4.png

标格式分为两个部分:一份是指标名称,另一个是指标标签。标签可体现指标的维度特征,用于过滤和聚合。它通过标签名(label name)和标签值(label value)这种键值对的形式,形成多种维度。例如,对于指标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分。


5.png

Prometheus通过HTTP接口的方式从各种客户端获取数据,这些客户端必须符合Prometheus监控数据格式,通常有两种方式,一种是侵入式埋点监控,通过在客户端集成,如果Kubernetes API直接通过引入Prometheus go client,提供/metrics接口查询kubernetes API各种指标;另一种是通过exporter方式,在外部将原来各种中间件的监控支持转化为Prometheus的监控数据格式,如redis exporter将Reids指标转化为Prometheus能够识别的HTTP请求。

HTTP返回Header和Body如上图所示,指标前面两行#是注释,标识指标的含义和类型。指标和指标的值通过空格分割,开发者通常不需要自己拼接这种个数的数据, Prometheus提供了各种语言的SDK支持。

Prometheus并没有采用json的数据格式,而是采用text/plain纯文本的方式 ,这是它的特殊之处。
6.png

Prometheus为了支持各种中间件以及第三方的监控提供了exporter,大家可以把它理解成监控适配器,将不同指标类型和格式的数据统一转化为Prometheus能够识别的指标类型。

譬如Node exporter主要通过读取Linux的/proc以及/sys目录下的系统文件获取操作系统运行状态,reids exporter通过Reids命令行获取指标,mysql exporter通过读取数据库监控表获取MySQL的性能数据。他们将这些异构的数据转化为标准的Prometheus格式,并提供HTTP查询接口。
7.png

Prometheus提供了两种数据持久化方式:一种是本地存储,通过Prometheus自带的TSDB(时序数据库),将数据保存到本地磁盘,为了性能考虑,建议使用SSD。但本地存储的容量毕竟有限,建议不要保存超过一个月的数据。Prometheus本地存储经过多年改进,自Prometheus 2.0后提供的V3版本TSDB性能已经非常高,可以支持单机每秒1000w个指标的收集。

Prometheus本地数据存储能力一直为大家诟病,但Prometheus本地存储设计的初衷就是为了监控数据的查询,Facebook发现85%的查询是针对26小时内的数据。所以Prometheus本地时序数据库的设计更多考虑的是高性能而非分布式大容量。

另一种是远端存储,适用于大量历史监控数据的存储和查询。通过中间层的适配器的转化,Prometheus将数据保存到远端存储。适配器实现Prometheus存储的remote write和remote read接口,并把数据转化为远端存储支持的数据格式。目前,远端存储主要包括OpenTSDB、InfluxDB、Elasticsearch、M3DB等,其中M3DB是目前非常受欢迎的后端存储。
8.png

Prometheus数据展现除了自带的WebUI还可以通过Grafana,他们本质上都是通过HTTP + PromQL的方式查询Prometheus数据。和关系型数据库的SQL类似,Prometheus也内置了数据查询语言PromQL,它提供对时间序列数据丰富的查询,聚合以及逻辑运算的能力。

数据运算包括了:
  • +(加法)
  • -(减法)
  • *(乘法)
  • /(除法)
  • %(求余)
  • ^(幂运算)


聚合包括了:
  • sum(求和)
  • min(最小值)
  • max(最大值)
  • avg(平均值)
  • stddev(标准差)
  • stdvar(标准差异)
  • count(计数)
  • count_values(对value进行计数)
  • bottomk(后n条)
  • topk(前n条)
  • quantile(分布统计)


如果需要获取某个时刻的数据可以通过curl 'http://Prometheus地址:9090/api/v1/query?query=up&time=xx'查询监控数据,其中query参数就是一个PromQL表达式。除此之外,还支持范围查询query_range,需要额外添加下面的参数:start(起始时间)、end(结束时间)、step=(查询步长)。
9.png

当接收到请求参数后,通过PromQL引擎解析PromQL,确定查询的数据序列和时间范围,通过tsdb接口获取对应数据块(chunks),最后根据聚合函数处理监控数据并返回。
10.png

如果监控数据达到告警阈值Prometheus Server会通过HTTP将告警发送到告警模块alertmanger。Prometheus告警配置也是通过yaml文件,核心是上面的expr表达式(告警规则)和查询一样也是一个PromQL表达式。 for代表持续时间,如果在for时间内持续触发Prometheus才发出告警
告警组件alertmanger地址是在Prometheus的配置文件中指定,告警经过alertmanger去重、抑制等操作,最后执行告警动作,目前支持邮件、slack、微信和webhook,如果是对接钉钉,便可以通过webhook方式触发钉钉的客户端发送告警。
11.png

为了扩展单个Prometheus的采集能力和存储能力,Prometheus引入了“联邦”的概念。多个Prometheus节点组成两层联邦结构,如图所示,上面一层是联邦节点,负责定时从下面的Prometheus节点获取数据并汇总,部署多个联邦节点是为了实现高可用以及数据汇聚存储。下层的Prometheus节点又分别负责不同区域的数据采集,在多机房的事件部署中,下层的每个Prometheus节点可以被部署到单独的一个机房,充当代理。

Improbable开源的Thanos提供了Prometheus集群化能力,感兴趣的朋友可以深入了解一下。

Prometheus的流行和Kubernetes密不可分,下面将介绍如何通过Prometheus监控Kubernetes集群。首先介绍Prometheus的自动发现机制。
12.png

Prometheus有两种方式配置监控对象,一种是通过静态文件配置,另一种是动态发现机制。

目前动态发现目前已经支持Kubernetes、etcd、Consul等多种服务,动态发现可以减少运维人员手动配置,在容器运行环境中尤为重要,容器集群通常在几千甚至几万的规模,如果每个容器都需要单独配置监控项不仅需要大量工作量,而且容器经常变动,后续维护更是异常麻烦。针对Kubernetes环境的动态发现,Prometheus通过Watch Kubernetes API动态获取当前集群所有主机、容器以及服务的变化情况。
13.png

通过自动发现机制,Prometheus可以动态获取Node和Pod的变化,将Node exporter和cAdvisor加入监控。针对容器常用的监控指标包括:

CPU利用率:
rate(container_cpu_usage_seconds_total{
  container_name="xxx", pod_name="xxx"
    }[5m]
)

内存用量(使用内存减去缓存):
container_memory_usage_bytes{
     container_name="xxx", pod_name="xxx"


container_memory_cache{
  container_name="xxx", pod_name="xxx"


网络发送速率:
rate(container_network_transmit_bytes_total{
  pod_name="xxxx"
    }[5m]
)

网络接收速率:
rate(container_network_receive_bytes_total{
  pod_name="xxxx"
    }[5m]
)

14.png

和其他的Kubernetes的Operator类似,Prometheus Operator通过定义下面四种Kubernetes的CRD资源,从而实现通过操作Kubernetes资源去管理Prometheus的监控和告警的目标。
  • Prometheus:Prometheus Deployment定义
  • ServiceMonitor:Prometheus监控对象的定义
  • PrometheusRule:告警规则
  • Alertmanager:Alertmanager Deployment定义


15.png

HPA是Kubernetes提供的水平伸缩服务,原生支持基于CPU利用率的扩缩容。如果用户希望根据自定义指标(如QPS)扩容,可以借助Kubernetes的custom metrics API。

Kubernetes资源扩展通常由两种方式,一种是通过上面Operator使用的CRD,另一种是通过Aggregated API Server(未来可能会被Kubebuilder代替)。custom-metrics-apiserver便是通过Aggregated API扩展Kubernetes的custom metric接口。

HPA查询自定义监控数据的请求通过kube-apiserver代理到custom-metrics-apiserver,并通过prometheus-adapter转化为对Prometheus数据查询,从而实现自定义指标的扩缩容。
16.png

宜信容器云是宜信内部基于Kubernetes搭建的容器管理平台,用户可以通过平台一键部署自己的服务。平台主要功能包括了服务管理(灰度发布、自动伸缩、多集群部署等)、镜像管理、监控告警、CICD、Nginx管理、Ceph存储等多个功能。其中监控和告警和自动伸缩都是基于Prometheus构建。
17.png

Prometheus采集的数据包括了主机性能监控、容器性能监控、Nginx访问流量、Kubernetes状态以及平台各个组件的性能指标。目前Prometheus本地数据指保留一个月,历史数据保存到M3DB中。

Prometheus一方面为页面提供性能指标查询,如nginx qps、容器CPU利用率,另一方便提供基于这些指标的性能告警,告警发送至alertmanger中,并通过alertmanger的webhook触发ipaas执行后续的告警处理(短信和邮件)。
18.png

为了支持容器的多指标、多集群自动伸缩,平台开发一套自动伸缩模块,通过cluster-mgr定时获取Prometheus监控指标,并模仿Kubernetes的HPA计算出目标的容器副本数,最后通过调用ipaas扩容多个集群的容器副本。

最后我个人想表达,Prometheus也并非银弹。

首先,Prometheus只针对性能和可用性监控,并不具备日志监控等功能,并不能通过Prometheus解决所有监控问题。

其次,Prometheus认为只有最近的监控数据才有查询的需要,所有Prometheus本地存储的设计初衷只是保持短期(一个月)的数据,并非针对大量的历史数据的存储。如果需要报表之类的历史数据,则建议使用Prometheus的远端存储如OpenTSDB、M3DB等。

Prometheus还有一个小瑕疵是没有定义单位,这里需要使用者自己去区分或者事先定义好所有监控数据单位,避免数据缺少单位问题。

Q&A

Q:我们Prometheus监控系统需要持久化监控数据,目前约存储了1.8T数据,严重影响了查询速度,Gafana基本无法刷新数据了,请问有优雅的解决办法吗?
A:1.8T都是保存在本地吗?SSD有一定的加速作用。如果数据量比较大建议使用M3DB、ClickHouse、OpenTSDB等。

Q:如何登录Prometheus数据库?
A:Prometheus本地TSDB没有登录入口,只有Go的API。

Q:企业级的Promtheus监控的数据存储是基于什么呢?ES吗,还是其他的存储?
A:我们使用M3DB,集群版本的InfluxDB、OpenTSDB等都支持。

Q:现在有高可用方案吗?
A:Prometheus的联邦或者Improbable开源的Thanos都是高可用方案。

Q:Promethues占用内存很好,我们的环境下45w指标大概要占用8G左右的内存,经常出现Prometheus容器OOM,请问有什么办法可以优化内存占用吗?
A:数据指标如果确实比较大,可以考虑Prometheus的hash采集,分摊压力。在生产过程中很多指标都是可以省去的,譬如Kubernetes中的Sandbox容器的指标。

Q:选择普通远程存储,面对持久化数据相对Prometheus本地数据几十倍放大的问题如何解决,如何处理日TB级海量存储,后期如何取出数据进行分析?
A:Prometheus设计的初衷并非解决大容量存储。如果是TB数据建议保存到远端的OpenTSDB中。

Q:目前Prometheus能否支持对网络设备的监控,如何支持采用SNMP SSH等协议方式的监控;能否实现与Zabbix的对接?
A:Prometheus有SNMP的exporter可以实现网络监控。目前还没听说可以对接Zabbix。

Q:目前Prometheus的报警rules规则是怎么管理的?报警阀值是否可动态调整?
A:rules也是通过yaml文件配置,可以动态调整,但需要reload配置。

Q:Prometheus的push方式(push推送给pushgateway)和pull正常的方式方式的性能比较,谁更好呢?
A:pushgateway本身作为数据转发的代理,本身性能损耗很少。建议直接提供prometheus的pull支持。

Q:联邦配置时,实测抓取多个job的metrics存在延迟现像极其严重,不知道有没有好的解决办法?目前我是通过Grafana直接获取两个Prometheus集群作为后端数据库。2次汇聚本地Prometheus与线上Prometheus,本地配置联邦,本地汇聚线上job的metrics,当job数量多了就会出现"federation failed" err="write tcp 192.168.243.145:9090->10.0.0.12:33508: write: broken pipe"。
A:这个主要看延迟的原因,是下层的Prometheus采集慢还是联邦节点二次汇聚的慢。针对federation failed通常是联邦节点性能不足,没法承担下层汇聚数据报错。目前联邦节点的并发能力不建议超过10000个时序。

Q:针对于一些公司自有业务的进程数据监控是依赖于自研的go-clent上报吗?还是说一些三方的client?
A:如果可以二次开发建议直接在代码里面加入Prometheus采集的支持,处理Go以外还有Java、Python的SDK支持。如果不能二次开发也可以在外部通过exporter方式。

Q:如果有多个副本CPU利用率,还是用container_name来算就有问题了吧?另外问一下,不同版本的Pod(比如发版之后)怎么比较其CPU利用率?另外Histogram的metrics有分析过吗?查询一个月的数据应该蛮有压力的吧还是做了优化,是否有必要?
A:多副本需要group。不同版本数据都在Prometheus存储,可以通过容器名称汇聚查询出来,一个月数据step可以调整的大一些。目前看一个月内的查询基本控制在2s以内。发版之后Pod name名字是不一样的,一种方式是通过保持container name,另外一种方式是通过前缀,正则匹配,我用的后者,不过会出现很多空线条,因为前面版本不存在这个Pod name标签的metrics,这个和多副本的container_name也算是有点冲突。metric名称应该是固定的,用正则匹配,不会有问题的,历史都会查出来,另外我发现histogram的metrics超过7天之后就没有什么参考价值了 所以对于查询一个月感觉意义不大,比如prometheus_http_request_duration_seconds,metrics还是重在实时性。

Q:请问针对Prometheus不能监控日志的瑕疵,有什么好的方案可以和Prometheus形成互补呢?
A:公司自研了watchdog日志采集。社区常用Filebeat + ES + Kibana方案。

Q:宜信目前用Prometheus监控了多少个服务target了?Prometheus使用的资源大概是多少?
A:宜信正在从Zabbix迁移到Prometheus,目前是三台物理机。

Q:时序数据库跟传统数据库的优势在哪?应该如何进行选型?
A:时序数据是保存随时间变化的量,查询也是时间维度,从而实现高压缩比。关系型数据优势在于数据管理。

Q:比如要做每日用户登录数统计,具体应该怎么做?需要哪些流程和步骤?
A:需要程序里面集成SDK,并提供查询累计登录用户的http接口,并在Prometheus配置这个target。

以上内容根据2019年9月17日晚微信群分享内容整理。 分享人陈晓宇,宜信容器云架构师,负责宜信PaaS平台的设计和推广,推进企业从传统应用迁移至云原生。参与多个社区开源项目(OpenStack、Kubernetes、Harbor等),参与编写《深入浅出Prometheus》。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiese,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

0 个评论

要回复文章请先登录注册