特稿 >

行业洞察 >

【K8S Meetup回顾】才云唐鹏程:用 Prometheus 来监控你的 Kubernetes 集群

【K8S Meetup回顾】才云唐鹏程:用 Prometheus 来监控你的 Kubernetes 集群

才云Caicloud 丨 行业洞察

7634
29

2017-05-11

赵逸禅

Xtecher特稿作者

关注

5月6日,“Kubernetes Meetup 中国 2017”——成都站圆满结束。来自IBM、诺基亚、才云的各路嘉宾进行了技术交流。


自2016年4月,美国 CNCF 基金会正式授权才云科技(Caicloud)为中国地区官方 Kubernetes Meetup 独家组织机构。在过去一年中,才云团队携手来自 eBay、腾讯、VMware、Google、中国移动、浙大 SEL 实验室的架构师在北、上、杭、深四城举办了 5 场 Kubernetes 技术分享交流会,参与人数近千人。


这次为大家带来的是才云的首席架构师唐鹏程的《Monitoring Kubernetes cluster with prometheus》演讲实录。


640 (1).jpg


大家下午好,我是才云科技的唐鹏程,今天演讲的题目是《Monitoring Kubernetes cluster with prometheus》,我知道在坐很多人已经在实际应用K8S 了,并且在各个业务部门的应用容器化之后,已经可以在K8S 里面正常运行。在正常运行之后,公司内部就需要一些运维团队对整个系统的应用进行相关维护。一旦出现问题可以进行相应的操作,而这时候我们就需要一个监控系统。


640 (2).jpg


我们来思考一下为什么需要这样一款监控系统,首先运维人员不可能一直盯着机器,你需要监控面板告诉你系统的运行状态,比如说我这个K8 集群里面每个节点CPU 的利用率,或者我的应用上API 调用的延迟是多少?这些都可以从监控图很轻松得到。


当机器或者应用出问题的时候,监控系统会为我们提供方向。比如我们突然从监控图上看到Web 服务的API 调用响应延迟变高了,又或者我们看到这个应用运行的这个节点CPU 占用率很高,那就可以有一个大胆的猜测,是不是CPU 数量不够,这样我们就能有大方向的指导,虽然不一定完全正确。


当然,监控系统虽然给我们提供了监控图,运维人员在实际应用过程中也不可能每天盯着这个图。那我们就需要监控系统会提供一些报警的功能,比如机器CPU 过高,可以给我们的运维人员发送提示信息。


640 (3).jpg


那这样的监控系统需要提供什么东西呢?他首先需要定义一个数据结构,我们知道这些机器或者应用的监控数据没有统一的格式,比如应用直接会打出来一些日志,又或者有一些输出监控数据的接口,那监控系统就需要提供一些统一的数据模型,这也是数据监控的基础。


我们既然有这么多的监控数据,那监控系统就需要定位一个统一的收集方式,怎么来收集这些监控数据。然后要考虑怎么存这些数据是最高效的,最后当我拿到了这些数据之后,我们需要用这些数据绘制监控图,那这个时候监控系统还是要提供一个查询的接口。这是我认为监控系统需要定义的一些东西。


640 (4).jpg


回到我们今天的主题,我们知道目前市面上有很多监控组件,但今天我们将重点介绍Prometheus 。它最早是借鉴了Google 的Borgmon 系统,完全是开源的,也是CNCF 下继K8S 之后第二个项目。它们的开发人员都是原Google 的SRE,通过HTTP 的方式来做数据收集,对其最深远的应该是其被设计成一个self sustained 的系统,也就是说它是完全独立的系统,不需要外部依赖。


640 (5).jpg


介绍完Prometheus 的背景,我们可以看到这里有两点Prometheus 的概述:首先,Prometheus 是一个监控系统,它可以监控你的基础设施。如果你想把它作为一个后期大数据分析或者BI 报告的backend,Prometheus 不是你的第一选择。我刚才也说到了,它是独立的一个系统,它自己的存储都是存在本地,没有考虑用一些外部存储来持久化这些数据,所以它不是持久的数据库。它只可以保存一周或者几周的数据,方便你去做一个监控。


640 (6).jpg


那我们在讨论一个系统的时候,不可避免要看它的架构图,Prometheus 的架构图非常简单,这里面有三块东西,首先是Retrieval,这个里面定义的是什么?我这个Prometheus 的服务器在哪里拉取数据,也可以从其他的Prometheus 的服务器拉取数据。


我们可能有很多会跑一些运行,然后就退出了,在这个short lived jobs 里面,他就是在这个拉完之后运行到下面,这里面都是一些静态定义的拉取目标,Prometheus 还可以支持动态的,比如说DNS 等,这一块是Retrieval,然后第二块是Storage,当然也有一些外挂存储的方式,这都是我们在做监控的环节下不需要的。最后就是promQL,通过这个可以直接查询。


右上角就是做报警的,它跟Prometheus 是分开的两个项目,比如说我这个机器的CPU 超过两个核之后要报警,Prometheus 就周期检验这些规则,这个就对Prometheus 发过来的东西进行聚合押禁,这也是一个架构图,比较简单。


640 (7).jpg


我们可以看一下这个Prometheus 的数据格式是什么样的,也非常简单,非常容易理解。你这个metric,后面是label,然后你可以用这种label 选到你想要的持续数据。底下是Prometheus 做的一些查询,这个是他的一个数据的结构。


然后这个里面,它里面的counter,有error count,还有CPU time,对于这些又会增又会减的,有一个叫Gauge 的类型,下面两种是比较复杂的一些指标,histogram 就是柱状图,还有summary,这两个不做介绍了。我们可能平时要算这个,可能要通过这两个指标来做。


640 (9).jpg

640 (10).jpg


Prometheus 怎么样来配置,由于时间关系,我简单列了一些常见的。然后这个surape interval 10 秒,可以根据某个规则发出来,还有recording rule,你这个程序每在CPU运行一段时间,就把这次运行在CPU 的时间加在CPU time 上面。这个东西怎么算?他需要对CPU suage 上面进行计算,需要做一个运算,这个查询比较慢,我们可以写这样一个表达式,把这个指标复制给另外一个指标,查询的时候,就可以直接查这个指标得到CPU 的使用量。这个也是每隔一段时间做一些检验的,下面有一些例子。


640 (12).jpg


再下面就是告诉Prometheus 要去哪里拉数据,然后他定义的Targets 是local host 9100 和local host 9101,那么我们可以想像一下在这个K8S 环节中,我们K8S 是非常动态的环节,我们不可能把所有的东西都写在静态的配置文件里面,那下面讲一下Prometheus 怎么跟K8S 做一个结合的。


640 (13).jpg


这里举了一个例子,我们知道K8S 每个节点都有进行整合。然后他会通过一个路径把容器的指标暴露出去,这个时候我们在Prometheus 里面怎么配呢?这是一个名词,我现在告诉Prometheus 我的Jobmame,用的Kubernetes nodes,Prometheus 知道它要去K8S 里面去知道nodes,然后暴露地址去拉取数据。


下面这个relabel config 呢,对这些标签进行操作,这个操作是因为我们K8S 里面可以打上很多标签,我们可以知道查询的时候,知道其他的一些指标,它是在哪台机器。


640 (16).jpg

640 (17).jpg

640 (18).jpg

640 (19).jpg


我们刚才通过一个例子给大家讲了一下怎么拉取容器的指标,那这个K8S 系统里面运行了其他的数据怎么办?这些东西的指标怎么办呢?这个Prometheus 有一个概念叫Databases,通过第三方系统服务暴露了一些指标,Prometheus 它不懂,把这些指标转换成Prometheus 可以理解的数据格式,然后从路径去暴露出来。这底下有一个链接,这个链接有已经实现的东西。


640 (20).jpg


我们这里再去举一个Mongo exporter 的例子,我们首先知道Mongo exporter 的db.server Status,部署一个Mongo,我可以配置我的Mongo 在哪里,然后就知道在哪里取这个数据,然后从什么地方把数据暴露给Prometheus,让Prometheus 来采。最后把这样一个Mongo 取到的数据转换为Prometheus 能够理解的格式。


640 (21).jpg


在整个的数据中,我们Prometheus 不属于pod 的,现在Prometheus 的pod,他先去另一个地方有多少个pod,找到之后然后找Mongo exporter的pod,这个pod 里面跑了两个容器,一个是Mongo,一个是exparter,把这些监控数据暴露出来,然后这个Prometheus 直接去两个地方取了,这样就可以得到两个监控数据了,我们去查询页面也可以查到。


640 (1).jpg

640 (2).jpg

640 (3).jpg

640 (4).jpg

640 (5).jpg


然后我们把这些东西部署出来之后,可能有人又要问了,我们这个服务,即使我们内部监控数据量特别大,这里有一个从Brian Brazil 他在博客写的一个数据,单个的Prometheus 数据可以轻松出来几百万的时间序列。单个的Prometheus 还是比较轻松出来的。当我们超过了这个数据,我们需要考虑一些其他的方案了。


640 (6).jpg

640 (7).jpg


这里顺便提一个冷知识,就是Prometheus 是古希腊里面的人物。第一种是splitting by use,然后这个单独去建这个集群,单个的Prometheus 去查询,这是最简单的方案。比如你分担一部分数据也没有办法做怎么办呢?就是Horizontal Shardding,这里分了三个Prom,每个Prom 分一个Prometheus 去采,这样去做一个汇总。


640 (8).jpg

640 (9).jpg


如果这样去配置的话,这个Prometheus 的集群怎么写呢?这里也举了一个例子,首先这三个Prometheus 的配置,他们的配置都基本差不多。比如说这个slave,他这个输出的数据我都给打一个slave:1,我告诉这个Prometheus 他要采哪些数据,这里是怎么写的?他这里是按照source labels 做了一个操作。然后再对这个进行操作,如果匹配了1,那我的action 就是keep。


640 (11).jpg

640 (12).jpg


那他这个Top level configuration 怎么去配置呢?他要在federate 去采,然后他去采所有的slave level 地址的持续数据,这个我们的树状结构的Prometheus 就配置完了。


我们知道对于一个监控系统来说,系统挂了,还是希望在监控系统看到一些东西,那Prometheus 的HA 系统非常简单,你用同样的数据跑两个Prometheus。这里又有人会有问题了,当我们去讨论一个分布式的存储的时候,我们没办法讨论他的理论。


我们在Consistenc 和Availability 和Partition Tolerance当中选两个,监控数据是海量的,如果你丢几个数据点是没有关系的。说到这一块,我今天分享的内容已经基本结束了,最后给大家总结一下。


640 (13).jpg


我们在选取一个监控系统的时候,还是更多要根据我们内部的实际情况,比如说我们对这个监控数据、大数据处理完全没有需求的时候,我们完全没有必要给Prometheus 外挂一些数据。


一旦你分布式的数据库出了问题,你的监控系统也用不了,我们在选的时候还是要根据实际情况。如果我们内部的需求就是要做这样一个数据分析,监控数据对我们来说都是非常有价值的,我们要把这些数据存一年、两年,我们就要付出一些代价。


我今天的分享就到此结束,谢谢大家!

打开微信“扫一扫”,打开网页后点击屏幕右上角分享按钮

账号登录

重置密码

还没有账号?立即注册>

账号注册

已有账号?立即登录>注册企业会员

重置密码

返回

绑定手机