容器云平台监控分层详解

本文是2020容器云职业技能大赛优秀课程《容器云平台的监控》的试读。通过本课程学习，可以了解容器云平台的监控在设计、实施和后期管理方面会存在哪些“坑”，该怎么“玩”，以及它和传统的监控侧重点有什么不同。

本次大赛学习平台由上百位来自用户社区及共创厂商的技术专家联手打造，是一场集学习、认证与比赛一体化的产业级学习运动。共发布5个岗位免费课程75个，其中运维管理岗课程共14个，完成课程学习+自测，获取岗位结业证书，还可以参加正在进行的“精英比赛”。具体请戳>>>运维管理岗位专属的容器云技能认证，你可以拥有→

2020 容器云职业技能大赛运维管理岗课程系列之——《容器云平台的监控》
课程出品人王洋，招商基金公司信息技术部，信息技术部架构师，硕士研究生学历，曾就职于蚂蚁金服金融云团队、商业银行、政府机关信息技术部等。擅长领域：云计算IAAS和PAAS平台规划与建设、系统架构设计、一体化运维平台建设、devops以及分布式存储，在分布式存储领域有多年实战经验，擅长根据业务特性建设分布式存储平台。持有DevOps Master认证、ITIL认证，并在IEEE Computer发表论文“on-demand securityarchitecture”，撰写专利“一种数据保护方法、装置及数据保护系统”（专利号：201010538235.8）。twt社区平台特邀作者、2020容器云职业技能大赛百位专家委员会成员。课程简介随着云计算的兴起与发展，目前比较火热的基于容器的云平台，由于底层基础架构发生了变化，支撑的应用类型和部署上线模式发生了变化，所以在监控方面也面临许多挑战，那么对容器云平台的监控在设计、实施和后期管理方面会存在哪些“坑”，该怎么“玩”，以及它和传统的监控侧重点有什么不同呢？本章节将给你逐一分析、讲解并提供一些建议。课程目录1 前言2 监控的目的3 监控的设计思路4 监控系统的通用实现架构5 容器云平台监控分层详解5.1 容器云平台监控之承载层5.2 容器云平台监控之通讯、调度与管理层5.3 容器云平台监控之容器层5.4 容器云平台监控之应用层5.5 容器云平台监控之日志处理5.6 容器云平台监控之动态扩（缩）容5.7 容器云平台监控之容量管理5.8 容器云平台监控之链路跟踪6 容器云平台之Prometheus简介7 容器云平台监控与现有监控平台的整合

8 监控未来发展方向杂谈

 试读章节 

*因课程内容体量大，此处提供部分试读，全文内容可参考上面的目录，感兴趣可以直接下载全文，该系列15个课程系列全部开放免费学习

1 前言

在信息系统建设过程中，无论是基础架构层面的集中式架构和基于X86的分布式架构，还是应用层面的传统的烟囱式架构和现在流行的微服务架构，监控都是一个绕不开的话题。随着云计算的兴起与发展，目前比较火热的基于容器的云平台，由于底层基础架构发生了变化，支撑的应用类型和部署上线模式发生了变化，所以在监控方面也面临许多挑战，那么对容器云平台的监控在设计、实施和后期管理方面会存在哪些“坑”，该怎么“玩”，以及它和传统的监控侧重点有什么不同呢？本章节将给你逐一分析、讲解并提供一些建议。

本文和你在市面上看到的关于容器监控仅仅讲解几个监控工具，以及如何部署就了事的方式完全不同，授人以鱼，不如授人以渔，本章会讲解监控的一整套思维体系，不仅仅适用于容器云平台的监控，也适用于所有用到监控需求的其他方面。

目前容器云在实际落地中，无论是商用产品还是使用开源版本，主要是指基于K8S搭建的容器云平台，所以本章节对容器云平台监控的建议也主要是针对基于K8S的容器云平台。

2 监控的目的

监控的目的是什么？我想大多数人都会说“监控是为了发现系统已经出现的问题，从而及时处理，将问题对业务系统的影响降到最低”。这个说法并没有什么问题，但是在笔者看来这样的答案对监控的理解还不够深刻。在笔者看来，除了及时发现问题，及时处理降低对业务影响这个用途之外，监控还有一个什么重要的用途就是每次发现问题时，能够引导或者督促我们去思考目前的架构、设计以及能力是否存在问题？例如，发现磁盘空间不足触发的报警，是不是该让我们思考磁盘空间的自动化清理工作不到位？思考是不是应用日志打印不合理？是不是被攻击了，导致日志量异常？而不是简简单单的把磁盘空间清理出来就算完成任务了。再比如，机器重启，导致挂载盘没有挂上，从而影响业务系统，那么我们是不是要思考为什么机器重启不能自动挂载？自动挂载失败了该怎么办？挂载的技术方案是否是合理的？等这一系列的问题。只有这样，每次报警的信息才能发挥最大的价值，而不仅仅是只做表面应对每次报警的事情。

3 监控的设计思路

监控到底要怎么设计？首先要确认一点的是，这个监控系统是为谁服务的，即他面向的对象是谁。如果是面向架构师，架构师可能关注的是目前架构下，整体的应用运行状态，是否有因为架构设计不合理而存在的瓶颈；如果是业务人员，他可能关注的是当前业务的状态是否正常，是否有失败的交易；如果是开发人员，他可能关注的是他自己负责的应用的运行情况；如果是运维人员，他可能关注的是整个底层平台、网络设备、存储等的运行情况。所以监控的设计思路也就呈现了出来，那就是“分层”，只有“分层”设计的监控平台才是能够满足各种角色人员关注的“好的”监控平台。一般来说，监控的分层会分为以下几层：

按照上面这个表格设计监控系统的层次，一般就可以应对90%以上的监控需求了，另外10%可能要根据具体的场景来准备针对性的监控思路，做到共性与差异性共存。

4 监控系统的通用实现架构

监控系统在实际落地建设过程中没有一个通用的架构建设思路呢？其实是有的，一般设计一个监控系统的架构，都会包含“数据采集”、“数据传输”、“数据存储”、“数据分析”、“数据展示”这几个维度，用一张图来表示如下：

结合上图，我们来逐一进行说明：

◎ 数据采集

数据采集一般是通过将代理部署在需要采集监控数据的节点上，采集预先设定好的内容，同时也可以在数据采集节点做数据的预处理，是否要做数据预处理是取决于所采集的数据量，监控规模以及后面数据分析引擎的能力来决定的，数据量越大，架构越复杂，数据采集节点越有必要做预处理。当然，目前还有一种是无代理的方案，无代理方案有三个问题：

一是无代理方案采集的数据全面性会低于有代理模式；

二是无代理模式通过拉的方式获取数据，数据获取不够实时；

三是无代理模式无法在终端上做数据的预处理，因此不太适合大规模的场景。

◎ 数据传输通道

这个组件的用途就是将数据采集节点采集到的数据通过其发往数据存储节点。好的数据传输通道应该具备以下几个特征：

一是适配不同的接入方式，因为数据采集节点可能是不同的实现方式来实现的，因此数据传输通道要提供多种适配的接入接口；

二是数据传输通道需要具备加解密能力，监控数据是非常重要且敏感的数据，在传输时需要被加密处理来保障安全性；

三是数据重传机制，传输过程中如果因为网络问题产生了数据传输失败，数据传输通道应该能够处理该异常；

◎ 数据存储

数据存储这个组件可以是集中式的存储方式，也可以是使用分布式的存储方式，这取决于数据量的大小，对于中小企业可以开始先使用集中的方式，后面再根据实际情况进行调整；同时数据存储节点由于IO比较高，建议使用高性能的IO设备。

◎ 数据分析

数据分析组件定义为整个监控架构的核心大脑也不为过，数据分析组件里面定义了各种监控指标的规则和算法，通过抽取数据存储中的数据，利用计算能力配以预制规则和算法，将各种数据进行加工，最终得到满足需求的监控数据。现在所谓的AI监控，有很大量的工作都是在这部分开展，例如动态阈值、异常预警等，这部分能力也成为监控厂商的核心竞争力。

◎ 数据展示

数据展示组件本质就是一个“显示器”，通过它将数据分析后的监控数据展示出来，给人可视化的效果。这部分目前比较重要的能力主要是可定制化，也就是可以按照用户的需求，高度自由的调整展示的数据布局和样式，实现所谓的“千人千面”。数据展示模块是一个监控系统的“脸面”，因此从直观感受的角度来讲，这个组件的效果，很可能会让人产生不一样的感受，毕竟这是一个看“脸”的时代。

5 容器云平台监控分层详解

5.1 容器云平台监控之承载层

目前的容器云平台主要是部署在裸金属上或者是部署在虚拟机上，并且通过底层的网络和存储来提供支持，我们将维持容器云部署的运行的底层平台统称为“承载层”。对于承载层而言，其监控本质上是对基础设施的监控，裸金属需要监控其物理层面的特征，例如风扇转速、磁盘是否损坏、部件温度是否过高、电压是否稳定等；虚拟机更多是关注其操作系统层面的问题；网络设备和存储都是按照传统的健康指标进行监控即可。

但是与传统的基础设施监控不同的是，由于容器云一个很重要的特性就是弹性扩容和需求和频率会远远大于虚拟机时代，因此对于整个承载层的容量监控就显得尤为重要，需要充分考虑自动弹性扩容以及故障转移时给承载层带来的压力，一般而言，建议生产环境的承载层水位不能超过50%，这样可以保证扩容一倍（无承载层故障的前提下）时，生产环境任然能够正常提供基础服务，当然这个值只是一个理论值，还需要结合每个公司的具体情况进行判断和选择。需要强调的是这里的水位是指承载层所有的会被服务依赖的“项目”，而不仅仅是计算资源或者存储资源，这就需要对整个容器云的部署和资源使用非常清晰的进行梳理和总结，总结起来就是凡是可以量化的部分都建议评估和检测其容量指标。

5.2 容器云平台监控之通讯、调度与管理层

基于K8S实现的容器云平台在笔者看来有三大核心组件来负责K8S平台的通讯、管理和调度功能，这三大组件分别是：“API server”、“Controller Manager”以及“Scheduler”。

API server的核心功能是提供K8S中各类资源对象的增、删、改、查及Http接口，成为集群内各个功能模块之间数据交互和通信的中心枢纽。默认情况下，API server通过名为kube-apiserver的进程提供服务，运行端口为8080（该端口可以通过参数 insecure-port进行指定），并且该进程运行在K8S的Master节点上。因此首先需要在进程和端口的维度上对此进行监控，注意如果使用了https的方式来访问api server需要对参数secure-port指定的端口监控；其次我们需要知道K8S中的很多数据结构都是以json字符串的形式存储的，因此很多我们需要的监控数据也就藏在这些json字符串中。我们可以通过访问api接口例如：curllocalhost:8080/api来查看api接口的目前状态，也就是说如果这个命令返回了我们需要的信息，那么就可以认为该接口是正常的，我们可以类似的方式去监控我们关注的api接口，例如：常用的监控接口信息主要有pods（列出指定节点内所有pod信息），stats（列出节点内物理资源信息），spec（节点概要信息）等，然后再从这些信息中抽取关注的信息进行监控；再次api server与kubelet进程、kube-controller-manager进程以及kube-scheduler进程都是有“重度”的交互的，因此一旦api server进程出现出题，那么应该关联报警管理服务和调度服务，使另外这两个服务组件能提前感知。

Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、命名空间、服务账号、资源定额的管理。当某个node故障时，Controller Manager会及时发现该故障，并且执行自动化恢复流程，确保集群始终处于预期的工作状态。Controller Manager实际包含以下一些 Manager：

这些controller都是有一个非常重要的能力，那就是可以让系统从“现有状态”修正到“期望状态”，这些controller是维持K8S集群达到声明状态的重要功臣。因此我们需要通过api server分别调用以上图中的manager来监控各个manager的运行状态，并且从返回的json字符串中抽取我们关心的指标进行单独监控或者聚合分析监控，例如获取副本控制器中的pod目前状态是否正常、获取node节点的状态是否正常以及健康程度、获取租户配额信息是否有异常以及细化到关注的pod的cpu和内存使用情况等。Scheduler是K8S中负责Pod调度的重要功能模块，这个组件在K8S的体系中起到了很好的“承上启下”的功能。承上是指它负责收到Controller Manager的创建Pod请求后，通过调度复杂的算法为Pod寻找一个Node，启下是指通知Node上的kubelet来接管Pod的后续运行。因此对于Scheduler的监控其实和controller是类似的，都是通过api server调用相应的接口来获取其状态信息；同时由于其承上启下的特殊性，我们也可以通过监控调度结果是否符合预期来判断Scheduler的工作状态是否正常，做法思路大概如下：打印出每次模拟调度时，Scheduler根据调度策略算出的调度分数，然后对比实际的调度节点是否为调度分数中得分最高的那个节点，如果不是则报警或者使用自动化策略，定时创建一些监控pod目的就是为了验证调度器是否正常工作，如果异常则报警通知。5.3 容器云平台监控之容器层在K8S的体系中，多个容器组成一个Pod，Pod也是K8S中最小的调度体，如果把K8S平台比作一个操作系统的话，Pod就是这个操作系统的进程。Pod通过两类探针LivenessProbe和ReadinessProbe来检查容器的健康状态。◎ LivenessProbe探针如果LivenessProbe探针探测到容器不健康，kubelet会将该容器删除，并根据重启策略做接下来的处理。如果一个容器没有配置LivenessProbe探针，那么它的返回值会被认为永远是“Success”，则认为容器是一直健康的。Kubelt会定期的调用LivenessProbe探针来诊断容器的健康状态，LivenessProbe包含以下三种实现方式：一是ExecAction：在容器内执行一个命令，如果该命令的返回码是0，则表明该容器是健康的；二是TCPSocketAction：这种方式是类似4层检查的方式，使用IP地址和端口号来进行TCP的检查，如果端口能被访问，则表明容器健康；三是HttpGetAction：这种方式类似7层的健康检查，使用IP地址、端口和HTTP Get方法，如果返回值大于等于200且小于400，则认为容器健康；笔者比较推荐大多数情况下使用HttpGetAction模式，这样监控效果最直观。对于一些特殊的需求，可以使用ExecAction模式来定制化对于容器的监控。◎ ReadinessProbe探针该探针主要用于探测容器是否启动完成，且可以接受请求，如果ReadinessProbe探针检测到失败，则Endpoint Controller将从Service的Endpoint 中删除包含该容器所在Pod的IP地址的相关Endpoint 条目。该探针一般不需要用户关注，是平台自动启动并维护的。

5.4 容器云平台监控之应用层

容器云平台中所提到的应用层，就是一个可以独立提供应用服务的组件，这个在K8S平台中，就是对应Service。在K8S中一般都是用Service作为一个应用的代表（一个Service可以包含一个或者多个Pod），用来代表我们部署在K8S集群上计划对外提供服务的应用程序。K8S集群中的应用之间可以通过调用Service来访问一个应用，如果是K8S外部应用要访问K8S集群中的Service就需要通过proxy的方式来进行，既然Service在K8S中被定义为一个提供服务的应用程序，那么我们就可以将对应用层监控的思路应用在对Service的监控上。

我们可以使用基于Http的健康检查机制来对Service的服务能力进行健康检查，我们会要求部署在K8S上的应用程序提供标准的Http健康检查接口（目前主流的开发框架都有标准的健康检查接口可以提供），并且根据不同的场景和要求提供单步或者多步的健康检查方式，最直观的获取的应用层的健康状态。另外一个需要注意的点就是发起监控点的设置，一般需要在两个位置上进行设置，如果service是提供对K8S以外的应用服务的，那么健康检查的发起位置需要在K8S集群内部和K8S集群外部都设置，这样才能在第一时间确认是service的问题还是代理proxy层的问题；对于只服务K8S集群内部的service，只需要设置一个集群内部的监控发起点就够了。

（试读章节完。篇幅所限，如需系统学习可以直接免费下载全文，学习中有疑问，可以参加在线辅导答疑。）

学习方式点击文末阅读原文或识别以下二维码下载完整课程文档：识别以下二维码可以进行本课程的自测练习：
说明：每个课程都对应着专家设计的一套自测练习题，来帮助大家检验每一个课程的知识点是否掌握。学员们学习完全部课程并通过全部课程的测试（每个考试有三次机会），即可以获得本岗位课程的结业证书。
加入学习辅导群：
学习过程中如有疑问，就扫描添加社区管理员为好友，加入到我们为您精心准备的学习班吧！有专家在线及时解答您在学习中的各种疑惑。

2020 容器云职业技能大赛

运维管理岗课程系列

课程1：容器云平台标准规范流程设计容器云平台的应急安全思路和处理方法容器云平台对外服务接口标准容器云平台安全合规标准
课程2：容器云平台关键问题解决和运维容器云平台性能分析容器核心技术问题的攻关容器云平台重大问题的分析、定位及排除容器云平台的集群高可用的运维容器云平台的监控容器云平台突发情况的排查和处理
课程3：容器云平台运维架构设计容器云平台的运维架构设计容器云平台规划部署架构设计容器云平台监控产品的选型容器云平台所涉及自动化引擎技术选型容器云平台用户角色定义学习更课程

识别以下二维码

了解更多”2020年容器云职业技能大赛“信息：

长按二维码关注公众号

*本公众号所发布内容仅代表作者观点，不代表社区立场