本次分享的内容看起来非常高大上，但其实原理却非常简单。本次主要将分享两个部分，一部分将会分享Docker相关的监控原理，另外一部分就是介绍一下阿里云容器服务。在国内而言，阿里云的Docker产品是比较先进的，因为我们进行了大量的用户调研，所以很多用户想将业务迁移到Docker时往往也会选择阿里云。
本次分享将主要谈到四个方面，第一部分将为大家讲解一下监控的重要性。因为如果你想要做一件事情必须明白这件事情到底是不是你需要做的，只有了解了监控的重要性才会明白，监控是必要的。第二部分则会讲解一下监控系统，这一部分主要会分享监控技术的相关概念以及Docker监控技术的相关原理。第三部分将则会偏重于讲解阿里云的容器监控服务，为大家分享阿里云的容器监控服务具有哪些能力，我们的关注点在哪里以及架构是什么样子的，最后还会谈一谈容器监控实践，分享一些关于第三方监控集成以及弹性伸缩的内容。
监控的重要性
接下来首先为大家展示这样的一组网站系统架构演进图。一个网站上线以后，随着业务的不断发展壮大，系统的架构也需要与不断发展演进来适应业务的需求。网站的架构演进可能看上去与今天的主题没有什么关系，其实不然，随着分享的深入，大家就会明白这其中的关系。
在网站系统架构的原始阶段，应用程序、文件和数据库这些东西都位于同一台应用服务器上面，这可能是最初设计小型网站时通常会采取的架构方式。
但是随着网站业务的不断增长，就需要将不同的技术服务拆分到不同的服务器中去。这个时候就会出现下图的架构：将应用服务器、文件服务器和数据库服务器都拆分到不同的服务器上去，这时候就实现了应用与数据分离。
接下来的阶段，架构上往往就需要加上缓存了。因为在用户访问量大的时候，很多高频访问的数据就会成为系统瓶颈甚至会拖垮数据库服务器，所以就需要添加缓存服务。
在增加了缓存之后，此时往往会发现系统瓶颈就出现在了应用上。因为会存在单点的风险，服务往往会部署在一台机器上，如果这台机器宕机，整个的服务就不可用了。所以原来的这种架构并不是高可用架构。解决的方案就是在服务之前加一个负载均衡，把原来的单机服务器做成集群。
随着架构继续演进就又会发现数据库部分又成为了瓶颈。其实对于系统而言，在不同的阶段各个部分将会分别成为瓶颈，有时前端顶不住，有时候后端顶不住。数据库成为瓶颈的时候就需要将数据库进行读写分离，保证读应用不会被写应用阻塞掉。
当整个系统演进到下一阶段时就会发现，前端对系统的影响会变大，所以就需要加上CDN服务器，加上反向代理服务器做缓存。
当存储的业务数据足够多、足够大的时候往往主存服务器已经无法搞定了，这时候就需要分布式数据库进行存储。
技术架构继续向后演进，就会发现很多应用逐渐被拆开，形成下图这样A应用和B应用相互调用的关系。
网站的技术架构再往后发展演进就需要将多应用共用的基础服务拆分成分布式服务或者微服务的形式统一对外提供的系统服务。
当然很多网站在最初时就已经确定好了自己的业务，比如微博或者电商等。所以在最初设计时就会采用这样的架构方式，然而在最开始就采用这种架构方式就意味着系统将会非常复杂，系统周边的设施比如运维系统都需要能够与之配套。
当系统演进到最终的这个阶段，拥有成千上万台机器的时候，出现问题后往往需要定位很长时间，甚至很多问题没有办法去复现，这些往往将会导致很严重的后果。所以当看完了网站架构从单台机器一直演进到面向服务的大型系统后，就会发现整个过程中，很多关键点是无法通过人工去发现问题的，只能依靠于自动化的监控系统。
其实刚才看到的都是表象，这个系统背后需要强大的运维系统支撑，没有监控服务，就没办法对系统“望闻问切”，找不到系统的问题，就没办法做针对性的改进，没有针对性的改进，就无法进行继续演进，这样线上服务就会处于随时崩溃的边缘，这些问题往往会成为悬在运维与开发人员头上的达摩克利斯之剑，大家会非常担心半夜有人给你打电话或者发短信通知你系统挂了，需要马上进行手动运维。
阿里巴巴在每年双十一的时候能支撑如洪水般流量洪峰，不单单是因为阿里巴巴的业务系统很强大，其实业务系统背后的运维支撑能力也非常强大，能对于故障及时处理，所以监控系统是非常重要的一部分，它发挥着不可或缺的作用。
监控系统
下图是整个监控的体系概览。
从最左边的数据采集端，图中为什么要写Self-control呢？其实很多监控业务指标是需要开发人员自己写代码上报的，是需要根据自己的业务特征，比如电商类的平台需要监控自己的交易量和成交量等进行控制。这部分数据采集的方式有很多，大家可以自己做也可以使用开源的解决方案。
接下来监控系统采集端采集到的数据需要上传给存储端，一般都会将数据存储到时序数据库中，时序数据库往往会支持流式处理，对数据进行处理之后再经过聚合运算和分析，能够实现实时报表的生成以及进行一些动态展示和实时监控等。同时这些实时监控的数据可以触发预定义的监控规则或者报警规则去实现报警功能。
一方面可能出现的问题就是发现在集群里面，所有机器的CPU都在飙高，应用已经快要被压爆了，就需要进行一些扩容操作。当然这个前提是集群需要位于云上，如果集群不是位于云上，那么一种做法是就提前买一批机器，另一种方式就是采用混合云的方式，将一些往往会出现访问量高峰的无状态应用部署在云上面，进行动态扩容，当访问量变小时，只需要将资源缩小就可以了。所以在报警这部分，弹性伸缩也是比较重要的功能。
另外一部分问题就是当发现业务网的某个子系统出问题的时候，可能并不需要去扩容机器，而是需要将链路切走，所以运维系统管控系统需要对接业务的管控系统。上图中为大家展示了整个监控系统的体系结构，后面将讲到的阿里云容器监控系统将更多的集中在前半部分，也就是数据采集部分和存储部分，而数据展示和处理现在是依赖于阿里云的云监控产品，开发者可以将其与云监控设置对接起来。目前的容器服务也可以做到报警和自动伸缩，可能大家用过阿里云的ESS，也就是阿里云的弹性伸缩产品，在使用时大家会发现有时需要人工去处理并且手动去触发报警，但是在很多的时候就会来不及，所以需要提前做好容量规划。对虚拟机做弹性伸缩的有ESS产品，但是对容器做弹性伸缩的却没有相应的产品，所以阿里云的容器服务会针对于容器本身提供弹性伸缩的服务。
再谈另外一个话题就是大家在工作中涉及到的监控指标大概就分为两部分：基础的性能指标和业务运营指标。在基础性能指标包括底层物理设备、操作系统和容器的监控指标。如果大家都在上云的话，底层的物理设备就是阿里云的虚拟机，虚拟机的可用性就是非常重要的，如果虚拟机挂掉了，纵使我们的应用做再好的容错也是没有用的。在操作系统方面，负载情况如何，是否需要扩容等等也是一部分指标，另外比如使用的是Node.js的话，就需要使用Node.js的客户端，我们使用不同的语言就需要使用不同的平台去运行应用。
基础技术性能指标其实是很基础的部分，能产生更多的商业价值的是实际的运营业务指标，比如说网站的业务访问量、电商的库存交易量等等，这是与自己所负责的业务场景相关的。其实只要是业务系统，这些监控指标都会有，但是这些指标的数据采集方式和上报方式就可能是千变万化的了。我们在提供容器监控服务时可以分别针对这两种指标进行不同的支撑，也建议开发人员和运维人员聊一下，尽可能主动上报一些业务上的运营指标。
监控系统其实有各种各样的好处，它可以发现硬件设备的异常，也可以发现业务系统异常，有时在压测或者容灾演练时往往会发现，突然有一天业务的监控数据指标下降得很快，此时一定是某个业务系统出现了问题，但是还是不确定是业务网络出问题了还是应用服务器出问题了，还是出现了其他特殊情况，除此之外，监控系统还能对硬件系统进行扩容和业务系统调度。
上医治未病，中医治欲病，下医治已病。大家可以思考一下在自己在运维系统时是不是处于这样的状态：系统生病了，也就是出问题了，大家疲于去头痛医头，脚痛医脚，所以有了监控系统就能帮助大家去医治系统于未病，能够帮助开发者将问题在萌芽状态就解决掉。
接下来就是分享一下在Linux操作系统里面，我们所关心的那些指标都存在哪里。在Linux操作系统之中，容器的监控指标在哪里和下图的内容是相关的。
接下来继续分享Docker的监控系统。首先谈一谈Docker是什么，简单地回答这个问题就是Docker是一个虚拟化方案，就像是大家在自己机器上运行的虚拟机。虚拟机需要下载镜像，然后使用VMware或者Virtual Box将这些镜像跑起来，Docker也是一样的。
既然Docker是一个虚拟化方案，那么就需要解决虚拟化需要面对的很多问题，比如如何对于CPU以及内存这样的硬件资源进行虚拟化等，以及对于网络这些资源如何实现虚拟化等等问题都是需要解决的。容器可以利用Linux已有的能力，比如namespace等内核已有的能力去搭建一套虚拟化的方案出来，使得运行在虚拟化的程序感觉自己是在运行在实际完整的操作系统里面，但其实它只是Linux操作系统里面的一个进程，所以非常轻量。对于一个进程而言，如何做到合理的内存管理和资源调度都是需要解决的问题。
Docker对于镜像有很多的优化，比如将镜像拆分成为若干层，进行增量提交或者差异化更新。当我们明白虚拟化所面临的问题之后，就能理解Docker是如何使用什么办法去解决的虚拟化所面对的问题了，因而对于Docker的原理的理解也就更加清楚了。
在Docker监控系统中，Docker-registry是必须的。对于开源的技术而言，想要提供给所有开发者应用的话，一定是需要提供易用的产品，而Docker-registry则是用于制作镜像的，在系统中也会起到不可或缺的作用。当我们了解了Docker的技术本质以及其面临的问题以后，就会对整个图中的各个环节都有清晰的认识。
监控时，在控制台中输入docker stats 这个命令的时候就会发现这个ID的容器有哪些东西，用了多少资源。然后就去可以根据sys/fs/cgroup/memory/docker/容器ID，可以在这个目录下看到你自己的Docker容器运行时的监控数据。
对于传统的监控系统而言，其监控对象可能是持久的和静态的，也就是说只要这个系统在线上运行，监控的对象就不会发生太大的变化，比如说Java服务器Jetty永远在那里运行，除非手动去停止或者重启。而对于传统监控而言，系统指标统计的维度也是单一的，系统指标具体指的是哪些东西呢？其实指的是宿主机器的内存等，不管是物理机还是虚拟机，所以传统监控的统计指标是非常单一的。
而容器的监控则是不一样的，容器的监控对象是“动静结合”的，也就是说容器监控的一部分对象是持久存在的，而其这部分持久存在的对象下面的一些子项或者二级内容往往是动态的。
大家使用容器的时候往往是由多个容器组合成一个服务的，在生产系统中提供的服务肯定会需要使用Docker的集群，而因为容器自身的特性，导致服务在更新时，容器的生成、销毁变得快捷时间成本很低，所以监控指标针对的容器对象可能在上一秒还存在，下一秒就因为应用的更新被销毁了，但是因为应用本身还是存在的，所以应用的访问量以及各项监控指标还是存在的。此时如果监控数据是以容器的ID作为维度的话，监控的历史数据一定会丢失，这正是与容器的技术特性相关的，容器就是启动非常快，不用时销毁的也快。
另外，对于容器而言，其系统指标的统计维度也是多维度的，需要统计宿主机的结点也需要统计宿主机的集群，并且需要统计应用层以及应用层下面的容器的数据，所以监控指标是多维度的，多角度的，并且需要对这些数据进行聚合。
这就是传统监控和容器监控不同的地方。
接下来谈一下Docker的关键监控指标。
关键指标的一部分是宿主机的CPU、内存磁盘等资源的用量。这里讲一个比较特别的例子，就是磁盘利用率，大家使用自己搭建的或者阿里云的服务的话，会发现磁盘利用率非常关键，当部署了很多应用之后，往往会发现磁盘已经满了，镜像拉取不下来，服务就无法启动起来，所以这个指标需要监控起来，避免这个问题的发生，进而影响线上服务应用。
而容器相关的监控指标则包括容器状态，比如容器集群里面对于某个应用而言，有多少个容器在活着，多少挂掉了，由此可以判断需不需要再启动一个容器，所以这样的指标也需要进行监控。
阿里云容器监控服务
刚才分享了与监控相关的内容，接下来为大家分享阿里云的容器监控服务，在这一部分，主要为大家分享关注点、架构和能力。
关注点
首先分享一下阿里云容器监控服务的关注点，在这些关注点上，我们将会为大家持久性地提供一些便利的功能。
第一个关注点就是为中小型客户提供易用的容器监控服务，对于很多个人开发者或者中小型企业的客户公司，其前期的技术储备并不是很强，甚至其公司内部都没有一个像样的监控系统，所以针对这样的用户，我们会为他们提供基于基础指标的监控服务，可以做到让用户基本不需要配置就可以获得监控的能力。
另外一部分就是为大型客户提供已有监控方案的集成，因为很多需要上云的公司需要将原本在虚拟机里面的应用迁移到容器里面，而这样的大型客户往往在公司内部是存在完整的监控系统的，所以我们也会为这样的客户提供完整的监控方案的集成。具体而言就是多多重维度的监控、数据聚合等等。对于双维度资源弹性伸缩方面，阿里云容器服务的资源组成其实有集群的概念，多个ECS会组成集群对外提供服务，这相当于是ECS维度的；除此之外，每个应用下面往往存在多个服务，每个服务下面又存在多个容器，这就相当于容器的维度。所以在进行伸缩时，需要考虑ECS和容器这两个维度的伸缩。这些就是我们的关注点。
架构
阿里云容器监控服务的架构如下图，比较大的蓝色方框代表大家在阿里云上购买的虚拟机，如果大家使用的是混合云方案，则也会代表自己的机房。位于虚拟机上面存在着Monitoring Agent，其实除此之外还有很多的代理共同完成了集群管理和任务调度的工作，Monitoring Agent会和Docker Engine进行通信，获取机器上面的需要的所有容器的监控信息，在对信息进行处理之后，上报给Monitor Server，进而上报给云监控。云监控就会进行实时的计算和处理，同时如果用户定义了报警规则，那么云监控就会将任务下并且回调Cluster Master，Cluster Master是若干台机器的管理者，它会将任务继续下发给每台机器，并且根据调度算法判断能不能在该结点上分配新的容器，如果不能则会继续寻找结点。整个监控部分就是这两条线，一部分就是数据采集和上报，另一部分就是弹性收缩。
能力
能力部分，粗略来讲，包含基础数据采集、自定义监控指标、第三方监控集成和弹性伸缩。
我们之前谈到监控指标可以分为两类，一类就是基础的数据指标，另外一部分就是自定义的监控指标。自定义的监控指标更适合去上报自己的业务指标。如果大家目前正在使用开源的监控系统的话也可以尝试去看一下自己所选择的开源监控系统有没有这四种能力，后退一步也需要分析一下除了第三方监控集成外，大家所选用的监控系统能不能提供其他的三种能力。
下图是阿里云容器监控服务基础数据采集的大致流程和简单架构。某一台虚拟机上面会有多个容器，某一个容器上面会运行多种应用。不同的被采集对象都有不同的插件存在于Agent里面，不同的Docker Engine的数据也会用不同的Docker Plugin进行采集。图中左边其实是输入的插件系统，当我们将所有的数据采集出来以后需要进行元数据处理，元数据处理是什么意思呢？其实在容器服务里面存在集群、节点、服务和应用的概念，当将一个容器的数据拿上来时，需要知道这些数据是来自于哪台机器，属于哪个应用、服务和集群。这些原数据都是加载容器的标签里面的，需要进行处理和解析。
另外一部分就是进行敏感数据加密，由于我们的管控节点是针对于阿里云容器服务的所有用户的，所以需要知道上报上来的数据来源是哪一个用户，针对这部分也进行了加密处理。用户是无法通过任何技术方式伪造出其他人的监控数据的，而令牌也是定时失效和更新的。这样的话就可以避免一些问题，比如当用户所做的产品也会向其他的用户提供服务的话，就需要考虑用户数据的隔离性和安全性。当数据处理完成之后，就需要将Monitor Server丢给数据输出插件，然后发送到数据处理端，最后进行聚合展示，另外也会输出给第三方的集成插件。
接下来为大家简单地介绍一下第三方监控集成，当你是一个系统管理员或者运维人员时，需要在阿里云监控服务上面创建一个influxdb应用，这个的意思是写一个模板然后点击一个按钮就完成了。当这个应用创建完成之后，就可以去将数据存储的URL上报给系统进行更新。
而Monitor Agent会动态监控检测Docker的事件变更，比方在发现服务更新时需要检查是否更新了相应的监控的配置。如果发现更新了监控相关的配置就需要激活相应的插件，将数据通过插件写入第三方插件里面。对于数据的消费者无论是开发人员、运维人员需要配置自己感兴趣的指标对接第三方的应用。
自定义监控指标上报是如何完成的呢？其实每个应用都有自己的业务数据，进行自定义监控指标有两种方式，要么就是暴露容器应用的HTTP接口，通过监控Agent定期去调用接口来获取监控数据，要么就是通过容器镜像存放数据采集的脚本，比如一个应用会写日志，将日志记录下来，而日志中的数据并不一定都是有用的，所以需要使用脚本定期处理这些日志文件分析出有用的数据上报给监控端。而监控端会根据自己的数据采集周期去容器中动态调用这些脚本，对于脚本输出的数据进行处理并且发送到第三方集成。
接下来再为大家简单介绍一下阿里云容器监控服务提供的在两个层次上的自动伸缩功能。一个层面是应用层面。一个应用下面是有多个容器的，这个层面的容器伸缩响应速度非常快，而且能够节约硬件或者虚拟机的资源。而对于集群层面的节点伸缩而言，真的可以缓解集群负载，比如说应用开始时在一些容器里面运行，某一天这个应用的各种指标都飙高了，需要进行容器的扩容，当进行完容器扩容之后节点和集群都撑不住的时候就需要进行集群层面的节点扩容，当然前提是要对于容量进行合理的规划，特别是对于一些热点事件进行营销时，一定要对容量进行合理规划。
在阿里云容器监控服务上创建应用有两种方式，一种是使用自己的镜像，另外一种就是使用模板。阿里云容器服务允许开发者自己维护自己的模板，只需要点击几个按钮就可以部署完成。只需要在应用上添加一些标签就可以与监控Agent相关联。大家在查看容器服务的监控数据时，数据也会自动按照自有维度进行聚合。
以上这些就是本次关于Docker监控技术原理和阿里云容器监控服务的分享，谢谢大家。
