开发者学堂课程【阿里云可观测峰会：行业实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1060/detail/16102
行业实践
二、万节点规模云服务的 SRE 能力建设
接下来演讲会有一个我们内部实际应用的这样一个系统作为一个切入点，去分享我们是如何基于整套arms提供的这样一些强大的功能，去做我们我们自身的稳定性，包括一些应急响应相关的一些工作。
首先，是先简单介绍一下我们今天所关注系统的这样一个架构。我们系统的用途，是一个实时数据流的计算和存储的这样一个系统，我们整套系统的底座，是基于阿里云容器服务ACK，做整个的包括容器化的部署，发布，管控等，整个都是基于K8S整套这套标准，包括像阿里云提供的一些容器平台相关的一些服务。我们系统流量入口，是我们自身开发的一个gateway service，这个service实际部署的时候，是基于load balance类型的这样一个service去部署的。这也是大家也用K8S做一些系统是一个比较常见的这样一个做法，是我们通过ACK提供CCM，也是云资源管理的这样一个组建，自动的去把我们的service和底层的一个SLB实例进行一个绑定，之后通过这个实力，去承接我们外部的这样一个流量。之后它们收到了外部的这个数据上报的这样一个数据流之后，我们把数据放入Kafka的某个topic中，进行一些数据的缓冲，并且当consumer 实际感知到这个数据流的上报之后，它会从Kafka的相应topic中去把这个数据进行一些进一步的计算处理。并且将最终的处理结果写入存储介质，我们在这里用的存储介质，是有两种存储介质，第一种是相对来比较快但是价格比较高的这个挂存储essd，也即云盘，还有一些比较相对来要求没有高的数据，我们将它放到文件存储那NAS上做一个存储。是我们向系统整个链路中还有一些原数据，我们将这个原数据放到acm中进行管理。当我们系统还有一些资源的组件，像刚才的这位consumer，还有还有center ，center 也是我们一个资源组建，它负责的是把我们计算的结果从存储介质中查询出来，并且反馈给最终的用户。这个是我们整套系统的一个简要的介绍。
目前的现状是整个这套系统是因为我们是全球开服，要部署在全球将近20个region当中，我们可以从这个图中也可以间接的感受到，是我们整个数据读写电路相对来比较长的，数据它会依次经过多个组件的处理。首先是一些我们资源组建，还有包括一些像paas层，云托管组件，比如Kafka。还有一些底层存储，NAS等。这个整个这道读写链路是比较长的，并且我们监控的对象相对来还是比较复杂的，包括像一些基础设施，比如像ACK,K8S,ECS这一层，比如像调度存储网络等，这些首先需要监控起来，还有一些云托管的paas层的组件，比如像Kafka，ACM等，是pass的云托管组件，这个也是需要我们也是强依赖，也需要做一些监控，包括像我们自研的一些组件，像GATEWAY，3条consumer等，这些都是我们自研组件。这些组件，我们也是需要自己去负责把它维护起来，然后暴露一些指标，包括一些日志等这些东西也是都需要自己去做的，这个也是我们目前做稳定性相关的工作的这样一个现状。
为了展开整整个这套工作，我在这里总结是大概分为三个步骤，首先我们需要收集数据，也即可观测性数据的这样一个收集的工作。可观测这个术语中，大家比较熟悉，是它分为了metrics tracing logging这三类数据。首先是metrics，它回答的是一个系统出问题了吗？这样一个疑问，它问题的范围或者针对性是这三类数据中最大的。我们一般来都是用metrics作为整套我们系统的自监控体系的这样一个入口，针对metrics，做一些异常的告警或者一些问题的排查，那我们可以快速的找到，是到底系统究竟是不是出问题了？需不需要人为介入去处理？为了回答系统到底是自身什么位置出了问题？我们需要用到的数据，这个数据相对于metrics它会更详细，是我们可以回答是组件之间的这个调用关系，包括每一次请求它究竟是在哪两个组件之间的调用的过程中出了问题？我们找到了具体出问题组建后，我们需要用到最详细的这个问题日志，比如Java开发者比较熟悉的，比如像JVM，或者一些异常的站或者等，这些都是需要通过日志去反应我们系统到底是哪里出的问题，哪行代码出了问题，或者这边本身它可能有一些资源上的使用不合理，或者有一些本身程序写的不好等。这些都需要通过日志去回答，这三类数据都是各司其职的。大家之间并不互相冲突，并不矛盾，它是相辅相成的。我们把这三类数据收集上来之后，下一步肯定是需要如何将这些数据完整的去展现出，然后让我们问题排查更为高效。并且我们能一眼看到是系统到底是出问题，哪里出问题，大家肯定也非常熟悉，我们需要配一些大盘，把这个数据可视化展现出来。最终是我们肯定是找到问题之后，我们肯定是需要一整套的这个流程和工具，把我们整个这个告警和应急处理流程完善。我总结我们所整个应急处理至少对于我们目前是有这几个关注点，首先第一点是我们需要一个分级的告警通知和升级的一个策略，能让我们快速的去找到我们相应的同学去处理，处理这个告警，并且如它因为某些个人原因可能无法及时处理的话，我们还需要将这个告警升级到其它同学，并且让它们去及时的处理。还有是我们对于每一个系统当中出现的问题，我们需要一些认领和标准化的处理的动作，这些也是需要一整套完整的流程去保证这件事情。当我们系统出现故障并且顺利解决之后，我们需要事后的统计以及复盘的一些工作，能让我们系统通过这样一次故障和实际的教训，让它之后不再出现相同的问题，我们系统更加稳定。最后是我们遇到问题之后，肯定是想把我们整套运维的动作去工具化，大屏化，那我们是尽量少去做一些SSH登录机械去手动敲命令的这样一个工作，我们把整套标准的数据动作用工具给它固化下来。这也是我们这我们后面所讲到的工作比较关注的点。这里我是从我们家医院比较，可能会经常看到一些比如像狂犬病或者这样一些比较紧急的疾病需要处理，它是有一个比较完整的这样一个急诊分级处理，包括最后疫苗接种等这样一个标准化的流程，这个流程也需要很多专业的工具去支撑，这个也跟我们今天所讲到的整个一个思想比较接近。
第二部分主要给大家介绍一下来自我们真实SRE工作中的一些经验，尽量希望能给大家一些帮助。首先是刚才我们到是我们要监控或者做好一个系统稳定性第一步，是要收集可观测的数据，这些数据在我们这个系统的视角里分为三个层面，第一个是最上层应用层，应用层我们关心的主要是第一，我们一些核心的业务接口的健康度怎么样，这个健康度我们主要是用red这三个黄金的指标去去衡量，是rate error duration，这个是我们比较关心的。rate主要是指这个接口的GPS或者GPS是多少，error是它的错误率或者错误数怎么样？是每个接口它多长时间能够返回。通过这三个指标，我们来定义一些sl，针对这个sl，我们会有一些error budget，这些错误的预算，比如我们定义多少个九，可以允许这个服务在多长时间内恢复正常，如果我们的error budget在很快耗尽，我们会及时去调整刚才所定义的这个sl，把sl调低，知道我们的系统优化到足够完善之后，我们再去把它调回来，比如像一些衡量一些对客户系统的体验，我们可以用apdex去衡量，这个公式今天我们不详细展开，它是去衡量的一个服务，它有多少的请求可以让用户满意的去完成，有多少请求是可以让用户在稍不满意但是也可以接受的情况全满足。这个是去衡量这个服务，它的健康度或者它的体验的分数怎么样，这也是一个比较重要的指标。还有一些跟业务强相关的指标，比如用户数等，这些属于应用层主要去关心的这些。我们系统也需要一些中间件和一些底层存储的，我们主要关心的是我们系统里大量用的卡，卡不卡向clerk端，它关键是低消费点提交状况怎么样。第二个是生产者，生产者producer，它一般会有这个八分，即生产的缓冲区，这个缓冲区的占用率怎么样，会不会提前把缓冲区占满导致新的消息无法进入，比如像consumer端，它会有一些消费延迟，平均收到的消息大小，这些也都是比较关心的一些相关的指标。在broker端，主要是看broker的水位怎么样，看读写流量，还包括磁盘使用率等，这些都是我们比较关心的。比如像我们使用的这个云盘，这个云盘首先我们用的是整个这套开发S系统，它需要依赖CS插件去做这个整个云盘的挂载卸载等这些操作，我们需要衡量整个这个云盘，它是不是能及时的挂载，挂载到我们的服务上。这个LPS等挂载上之后，我们还需要关心它的lPS如何，磁盘是否写满，写满之后肯定需要及时地扩容，LPS也是我们这个云盘的性能是不是达到我们的要求，如果不行，我们及时对它进行分配或者优化，我们优化我们本身程序本身使用磁盘的方式，这都是比较关心的。基础设施层，这个指标比较复杂，我主要讲解比较典型的，比如ecs，是K8S底层的note，它主要是cpu内存的水位，这个大家都非常关心，还有像ECS可能会有一些定时的运维事件，这些还有包括像它本身机器的重启次数。这些都是我们需要关心底层note上这些关键的信息，K8S核心组件还有包括一些调度相关的这些指标，这些都是整个K8S这套体系里比较相关的。比如我们的pod是不是一直处于分裂状态，没有资源，没有资源可以足够的去调动它，或者像我们的pod本身，它可能会因为内存使用不合理，会有些MQ的这种事件出现，甚至于可能会像Java应用它可能本身或者够用，本身因为panic或者exception它会异常退出，这种它会有这个L事件产生，这些都是我比较关心的。然后是我们整个系统的流量入口，Slb相关的，比如出口带宽，入口带宽等，然后像丢弃连接数，因为丢弃连接数也是比较重要的指标，比如我们系统在某些时刻，它丢弃了非常多的连接，相当于这个整个新用户进来是一个不可用状态，这个也是我们需要及时的去人工介入去处理，这也是我介绍这些关键的一些指标。我只是简单介绍一些，在我们真实运维的场景中，还有很多。很多非常复杂的指标，这个也是因人而异的，希望各位大家可以通过我这些介绍相当于抛砖引玉，让大家能够减少自己系统中的一些监控的盲区，能提升我们整个系统的这个稳定性。
这个是我的一个更详细的一个总结，首先是我们比如我们想监控ecs节点，我们需要用node-exporter，它实际上在开发区里是一个守护系升级，是Daemonset方式部署。还有包括像一些K8S云原生的核心组件，它本身都是可以通过open metrics的格式去把这个指标报出，让Prometheus去抓取的，比如一些组件，或者这些功能相关的指标，都可以通过metrics节口暴露出来给Prometheus去抓取。包括像Kafka或者存储组件因为我们用的是阿里云的云产品，产品本身，它提供了一些基础的监控指标，这些都是我们可以直接去接入的。然后包括ECS存储插件，这个也是我们需要使用的。eck本身对于ECS存储插件，也提供了一些非常核心非常关键的比如挂载，挂载率，ios充电占用率等这些指标。这个也是需要接入。应用层在我们系统里主要用Java应用，Java员写的应用，包括购物应用，Java如果是部分基于spring boot框架，我们直接用spring activate 去做这样一个监控，像足够使用，我们直接使用这个Prometheus官方的SDK去做一些埋点，接下来详细的对这些方面进行展开。
首先刚才我们讲到的因为我们底层基于ecs整个这套体系，像metrics协议的选型，我们也基本上没有什么比Prometheus这整个这套标准，这套体系更完善的一个选择，我们当然用Prometheus。我们当然也可以Prometheus本身自己在集群里搭一套，我认为本身如果只想把它搭起，门槛并不是非常高，并且社区里也有很多像Prometheus等这些比较成熟的这种一键接入的这种方案，但虽然接入难度上讲开源自建的比托管可能相对来差距不大，但是像可靠性，运维成本等，我们如果用托管的Prometheus比我们自己搭建一个开源要更优。我们使用整个这套体系，我们直接在集训安装一个非常轻量级的这种探针，我们将数据中心化的存储在全托管的一个存储组件，并且围绕它做一些监控、告警、可视化等，都非常方便，我们不需要自建很多开源组件。应用线上来讲，因为后面涉及ACK本身它提供了一个组件中心的这样一个功能，我们可以配选择arms Prometheus，也是接入了这个组件中心，我们可以通过这个组件中心非常快速的像安装一个手机APP，可以把我们整套监控系统给它搭起。在采集能力存储能力，相信大家可能之前也调研是想托管，当然本身它开源来讲肯定是有，但是它自己的优化，这从性上来讲也是不需要去担心。刚才我所ecs节点开发的核心组件，包括像Kafka等是arms本身，它给我们提供了一些非常方便这种一键接入的功能。比如K8S技术监控，包括状态监控，我们直接通过ack这个组件中心去完成，把它安装。也可以给大家简单的去看一下是我们在自己的这个业务集群里，我们装上eck arms Prometheus的这样一个组件，像应用一样，可以直接给它安装，安装之后，我们可以看到在几十米启动了这样一个非常轻量级的这样一个探针。然后在我们的这个守护进程级里可以看到向node-exporter这样一个组件，我们每个节点上都启动了一个node-exporter，去抓取我们这些节点上的关键信息。像Kafka接入我们主要走的是像Prometheus云服务实力。云服务实力它目前也接入了像阿里云的一些非常完整的一些云产品，因为我们主要也是卡这个产品，我们直接选择接入它可以，也可以看到是我们接入的这些指标，也是我们平时用的比较多的，并不是一些很冷漠的指标，都是一些我们经常使用的。比如我们可以看到像topic本身，它的message的input output，Kafka本身实力及实例级别的是这个磁盘的使用率，包括像instance本身的这个实力的流量，因为我们是买这个Kafka实力时，我们都需要制定一个规则，如果我们这个规格拿到之后，我们需要给它做一些生配，不然会导致整个消息的生产和消费都会受一些影响。所以这些指标都是我们经常会使用到。包括像云盘ESSD，是ECS存储插件的这个监控。在ack里面，有一个组件，这个组件相当于开源来讲，本身它提供了一些可观测性的一些对我有用的，我们可以是通过这个组件提供的信息，去及时的看到我们哪块盘没有卦上，或者哪块儿盘挂上了之后，FPS未达到要求，甚至于它写满之后，我们也可以针对于它相对来一些告警，能够及时的去发现这些云盘的。异常状况怎么去及时处理？
像我们走arms Prometheus接入，它本身会预置这样一些采集的照比如像K8S sf class级别，包括像note级别，这个PV的状态都可以分方便监控的。
在应用层没有什么一键接入的好的手段，需要去通过应用的埋点。并且把整个这个应用的这个metrics接口暴露出来，给我们这个arms Prometheus探针去抓取。像Java应用。我们使用这个micro meter，或者three wood activator，先去进行埋点。
这里我简单举一个实际代码中的例子，像micro meter，本身如果我们使用micro meter，可能大家也了解，它本身会有一些JVM本身相关的，比如像class loader，是我们加载了多少类，包括像JVM，Jvm的分区Memory，还有包括像线程数，线程运行状况，包括像JVM本身的版本信息等这些都非常简单，直接这几行代码可以实现把它的信息暴露出来。然后还有比如像一些更有帮助的信息，比如像进程级别的单位，或者进程级别的这些也是我们比较关心的，我们也通过很简单的方式把它接入进来，达到system的一些信息。然后我们把这些埋点进来之后，我们最后一步是需要启动一个在内部的server，然后我们把整个它的这个metrics信息，通过一个HTTP端口的方案，HTTP接口的方式给它暴露出，然后绑定这个九幺这个端口，这个我们自己指定的这个端口。整个这个埋点的整个流程都完成了，如果有一些业务指标，我们也很方便，我们把这个Prometheus registry，把我们自己的指标注册到这个全局的Prometheus registration，就完成了。
下一步，是我们如何让arms的探针能去抓取到刚才我们暴露的端点，也是通过添加一个surface water的方式，这个surface water直接通过控制台白屏化的方式，简单的写几行这个压模的定义，可以完整的去把整个这个监控、采集、存储，包括甚至后面的可视化跑通。是比较简单但够用大同小异的，只是埋点的方式有些区别。我们这里使用了这个arms官方的这个SDK去埋点，这里我举一个例子，比如我们刚才是我们系统有一个查询组件比较关心是我们每一条查询它的时间的分布怎么样，会不会有频繁的这个慢查询，我们用这个Prometheus里面这个直方图类型的这种指标，我们把每个请求它的这个请求的时间分布给它记录下来，通过这个graph这种指标去记录下来，然后我们再埋点的时，我们指定一些常用的去统计。然后surface water，这里也重复介绍，然后把够用的这个APP也以这种方式写进来，然后在空调上完成了整个的这套进入。那当然还有一些是arms 也提供了一些基于这种ebpf，这是最近比较火的这种切入的这种可观测性的实现方案，这个我们主要是用来监控一些比如我们可能有一些系统的代码，我们不想改或者改可能发布的周期比较长，我们不愿意去改动这个系统代码，那我们使用这个切入的方式，去监控这个系统接口的这个red，刚才我们的这个也是通过arms这个cmonitor特征，用ebpf方式去通过系统内核的一些future，然后去实现这些信息的抓取和清楚。
这个也是需要我们在集群额外的安装一个cmonitor的这样一个APP，看到是我们在这里安装这个APP，然后安装上之后，我们会看到这里有一个 cmonitor agent ，是每个节点都需要启动一个。agent的作用是给它注册到这个系统，通过ebpf 的方式把它注册到这个系统内核当中，然后去抓取我们整台机器的这个网络流量。然后过滤出我们想要的这个service，它本身的这个网络拓扑，最后去找到我们想要的一些信息，比如这里我们可以看到，它可以监控到整个系统的QPS，包括一些相应时间的分布等，这些都非常有用信息。
我们完metrics，还有两部分非常重要的信息，是这个trace和 log。这一块儿，是我们给它时间关系，我们不多详细展开来讲，trace我们主要是也是用cmonitor的能力去做一些相关的事情。
像比如系统组件的日志，比如像k 8s本身控制的日志，还有包括像我们的一些JVM本身的一些dclog，还有包括像我们打到SDL上的一些信息，我们通过这个from tell ，the arms from tel也是一个去采用日志的这样一个探针，然后我们把日志投递到lockie做一个长期存储。像K8S系统事件的日志，我们是基于这个arms事件中心的这样一个功能，我们去把K8S本身的一些关键事件，还包括像我们的调度上的一些OM，L等这些关键的事件去给它监控。这里我也放了几个实际的这个系统中的截图，像trace相关的是我们通过这个cmonitor，如果使用cmonitor，我们会看到这样一个控制台，这个控制台本身可以看到我们每个请求它的这个经过的这些组件，然后在每个调用的时候，它接收用多长时间，处理多长时间，然后回应和总体考试等这些信息，这些trace的信息可以拿到。
像log，这里面举个例子，是我们通过在官方那里配置一个这个lockie的数据源，我们可以非常方便的是根据一些关键字或者甚至于我们什么关键字都不输，然后通过一些pop标签或者其他，能很快速的找到我们想要的pop或者想要的service本身下面挂这个pop的日志，都很方便能找到，然后对我们查问题是很有帮助的。
这个事件中心，我们关注的是一个pop它重启失败了，或者本身它因为镜像问题拉不起来等，或者因为OM的问题，或者其他，导致水流过高，它自身重启的这种事件，我们通过这个事件中心，大家简单演示一下是这里面会有一个这样的事件中心，这个控制台，我们会在底下看到是这些集群中的一些关键的事件。然后我们可以对一些等级比较高的这种事件进行一个订阅，这个订阅是用三部的方式，第一步是填写一些基本的规则，然后选择我们需要哪些模式去匹配这个事件，然后我们需要在这个事件匹配的时候，我们需要把告警发给谁，这是一个比较简单的这个配置方式。我们通过这种方式，我们把整个的把关键的时间给它监控起来。然后能达到及时去响应目的。
刚才我们讲到的是我们把数据如何给它收集起来，下一步，是如何我们打造一个非常高效可用的这样一个数据可视化和问题排查的这样一些工具。那首先，是当然Prometheus跟Grafara是一对这个黄金搭档。我们数据可视化的工具，选用了这个广发的作为我们的这个基础。在广泛的配置大盘的时候，这里是总结一些我们平时配置大盘的时候有一些实际的经历小的tips，首先我们每次在加载大盘时，我们需要在每个拍照上控制一些查询的这个时间线的个数，避免在前端展现了非常多的一些时间线，导致这个浏览器渲染力大，并且对于是问题排查来，一次性显示多时间线没有什么帮助。还有包括我们在大盘里variable，我们可以灵活地去在一张大盘上去切换各种各样的数据源，切换各种各样的查询条件，这也是一个我们是让这个大盘变得更好用的一种方式。然后可以使用transform这种放到这种transform的这种强大的功能，我们可以让大盘，是一些普通的大盘，比如像table，panel，比如像我们使用电子表格一样可以让它非常灵活的去展现这样的信息。还有包括有些时候我们忘记可能去勾选一些认知或者一次查询的这样一些开关，我们可能只需要展现一个瞬时的状态，如果不把开关给它关上，它可能会查询一个非常长的时间范围的一个数据，导致是大盘的渲染时间变慢，这个也是我们之前配大盘走过一些弯路。
理论上的东西结束后给大家看一些实际的一些大盘的配置，这个是我们用来监控这个节点信息，一些开发咨询这个pod信息的这样一些。这个大盘我们可以看到是它的信息相对来讲一目了然，并且我们通过不同的颜色去把一些关键的并且值得值得我们去关注的一些信息去给它标标记，这个也是用那个广发的里面的一些动态阈值的这样一些功能，去让这些数字去以不同的形式去展现出来，这也是一个提升排查问题效率的一个比较好的方式。
这个是arms本身自带的一些大盘，这个是像节点水位这个大盘。可以给大家看一看一下实际的大盘的效果，是是比如我们想关心一些，磁盘的LPS读写时间，网络流量等，这一张大牌都可以把我们想的信息都展示出来。比如像内存使用率，Cpu使用率等这些东西都是我们比较需要的一些信息。还有一些我们自己配置的，比如像我们业务上的一些全局的信息，我们是通过这个广泛的托管服务去配我们这些自定义的这些大盘，也是arms提供的这个最近新上线的这样一个功能是
在云上去托管一个Grafara的实力，我们通过这个云账号可以直接登录到这个发的这个界面，它有一些阿里云自己定制的一些特有的功能，这个大盘是我们去Prometheus了一张非常大，主要关心的是一些大的数字，是全局的一些latency，包括QPS，成功率等，包括错误码的分布情况，QPS的变化趋势，有些比较细腻的信息，比如像我们班分配，是我们因为是一个多副本部署的话，我们看是这个负载是不是分配的均衡。然后还可以看到是一些请求量比较大的这些top用户，可以有一些针对性的处理办法。像比如gateway组件，我们有些时候在发版的时候，我们需要在这里是展现是我们发了版之后，它的指标跟上个版本有什么变化，这块，可以带上这个版本。通过这个metrices 拿到我们这个pop的版本，摘下来。我们可在这个持续的panel中去以这个变量的形式去展现这个data source，这也是可以在这选到全球各个region的这个data source。并且可以快速的去切换到全球任何一个region，这个也是一个比较有用的功能。
还有比如像我们急群众依赖这个Kafka客户端和服务端的这个监控，来源于这个云监控提成。这个是我们一个实际的大盘为例，我们可以看出我们几个内部的总监。然后它会想依赖这个Kafka，Kafka我们会通过这样一些指标，去监控到是Kafka本身，包括它跟broker之间的连接数，平均消息长度为点提交速率，消费流量等这些都是我们需要去监控，包括像producer端，他有一些发送缓冲区的占用率，包括活跃的producer数等这些信息都给展现到大盘上。还有是像一些JVM相关的指标，比如像我们这个组件，它用Java编写，也需要去监控他一些JVM相关的一些GC的情况，包括像一些JVM的情况，这里看到有对内的对外的和总的，包括像ecs这种级别的。像GC相关的，比如像Major GC等。包括像一些分带的这些内存占用，或者GC它的效果好不好，然后像一些在CPUUC，包括像限程数，现成的状态等，有一些长期block的限程，都是需要关注包括像发板或者有些动态加载的类，在这个加载类的这个统计中可以看到，有没有一些持续没有持续上升的状态。然后比如我们系统里可能还会使用到一些direct，或者一些对外内存，这块我们可以给他及时进行监控的。还有比如像我们有一些我们想使用电子表格去统计一些集群中的一些安装的状态，或者一些重点客户的状态，这个时候，我们可以使用Grafara的这些transform的这种功能。把我们整个大盘打造成一个这种电子表格这种体验，比如像这个我们是使用这个transform。用transformed去把我们这个字段映射到这样一张电子表格上，并且我们打开了这个filter之后，是我们可以通过这个筛选各种各样的字段，达到我们想要的目的。
我们刚才展现的大部分都是一些指标的信息，还有一些比如像日志的信息。这个时候，我们需要通过lockie去在这个官方去查询这个lockie的数据，这里，我举了一个例子是比如我们center里会有各种各样的这种perla log，查询日志，查询日志本身它里面会原始信息会带很多，比如这次查询的时间，这次查询各种各样的信息，UID等这些信息，通过这种是后处理的方式，我们先把整个日志，我们想要的日志按行的方式筛选出来，然后我们通过一些模式匹配的方式，把我们想要的信息提取出来。并且我们在提取这些信息中，我们可以去把里面的某些切出来字段的去做一个大小关系的这样一个匹配，最终还可以将匹配出来的日志进行一个格式的二次处理。像我们这种是完整的进行整个流程之后，我们可以从集群的大量的这种查询之中，找到我们想要的一些娱乐信息，比如我们想知道是有多少查询语句是经常会出现慢查询的，我们会针对这个场景去优化我们的整个这个系统。这个也是我们的一些实际的经验。
那给大家介绍一下我们在告警的分析响应机制建设这块的一些经验。首先是我在总结了一些我们在配置这个告警，然后建立整个应急响应流程的一些基本的步骤首先，最开始是我们挑一些比较关键的指标，或者用户，跟用户体验相关的一些指标，你先配一些告警，然后配完报警后，我们需要有人去时时，去关注这些告警，肯定是要排一些同学去去做一些排版什么的，然后之后，在告警出发的时候，有一些影响的机制，它包括一些整理沉淀下来的文档，这些都是我们去需要人工介入处理的一些场景，之后，是我们处理好了之后，还需要做一些复盘，还有整个这套流程机制的这种优化。那最后是我们把这些优化的经验，反过来再去正反馈到这个告警配置上，整个是形成这样一个循环的流程，不断的去优化我们整个这个机制。在我们以前的这些整个这个流程里，是有一些不尽如人意的地方，首先第一点是原有的系统是我们是一套自建的这种告警系统，通过依赖自建的一个系统定时跑一些任务，去检查各种各样的指标，然后去掉一些丁丁的macbook，或者一些其他运维系统的，然后发出了这样一个告警，这块是有这么几点值得去感谢的地方，第一点是本身这个告警系统它应该是我们自建的，稳定性是我们自己需要负责，如果我们告警系统的这个稳定性还不如需要运维的这个系统本身的话，那个告警没有什么意义。并且我们因为随着我们整个这个集群开服的越来越多，这个配置也是越来越复杂，我们自己维护这个配置，并且想要这个配置全球生效，这是一个挺困难的事情，也遇到了很大的瓶颈。我想排班也是是我们最开始可能这个系统这个团队没有发展壮大的时候，可能一两个人，大家是轮着值班好，但是后来随着人越来越多，这个排班如果直接依赖手工，非常容易漏掉一些关键的节点，时间节点，这也是需要去注意的。还有像告警出发的时候，有一些告警它的触发条件非常单一，只是零或者一这个告警，并且这个告警本身这个信息，也很难灵活地去做一些根据我们整个的业务需要去做一些达标的处理，分级的处理等这些之前都是没有。还有包括像以前我们发出来这种信息，信息量也是非常非常频繁，里面只有一个这种文字的信息，还有他艾特谁这种信息。这个告警，第一它没有办法主动去认领，没法主动去关闭，并且当我们是系统真的出问题的时，可能同类的告警会发出很多，瞬间把整个群给刷屏了，所以我们也没有办法去主动屏蔽掉这种告警，这是也是一个非常不灵活的点。还有是当我们是后做一些复盘优化的时候，我们没有一些数据的支撑。没有办法根据一些已有的这些告警的统计信息，去拿到我们去优化我们整个这个流程。这也是我们之前系统中遇到的一些问题。我们之后，是因为我们整个使用arms整个这套产品，arms里面也有一些我们使用的功能非常强大的这样一些告警分级响应的这些这些工具来去帮助我们建立整个这套流程，首先第一点是我们这个告警模板，那这个告警模板意思是我只需要对于所有的集群，我们只需要配置一次这个告警规则，他可以让不同的集群去生效这个告警分子。像比如我们刚才我们到我们这个架构是基于ack的，我们每个region都是一个ack cluster，那这个cluster可能20个，像以前如果没有告警模板，我们需要再对每个cluster里面的指标配一些告警，自从有这个模板，我们这个工作，大大节省我们的时间，我们可以通过这种告警规则模板的方式去把我们的告警的room区Apply到全球各个region进行，非常方便。排班，arms中心的也有一个这个排版的功能。它可以是每个月可以动态的去做一些轮班替班这种工作，去把我们以前手工的排班去交给这个系统去做，也是挺靠谱的，没有什么漏错这种情况出现。
给大家是掩饰一些我们实际配置的一些告警，这个demo我们想明的问题是我们如果想对某些告警打上一些动态的标记，是在这个告警实际触发的时候，还没有这个标记，那我们通过这个arms的事件处理喽。报警这个处理和告警孵化的这些功能，可以在这个告警触发后，动态的去给它打上一个标记，并且做一些分级的处理，比如像我们这里展示的是我们给一些告警打上这种优先级，这个priority的这个标，然后我们打上这个标志后，我们对于priority比较高的，比如这期我们这算比较高的这种优先级，这个优先级的时候，我们把这个告警等级升级成P1，并且我们把通知策略，这个告警需要通知给谁，这个通知策略动态的修改，我们也是这样一个功能。
首先为了达到这个功能，首先我们需要有一个数据源来提供我们这个达标的第一句，这里我们做了这样几个事情，第一个事情是在告警运维中心，这个控制台，是有一个这个数据源的这样一个功能，这个数据源，是我们在告警的时候，一个告警触发的时候，他可以去调用这个数据源，通过HTTP请求或者ipc请求调用数据，调用这个数据源之后。他可以是从这个HTTP的这个url里去拿到我们打标的这个结果。这个接口是怎么实现的？是我们通过这个FC的另一个产品去实现，因为这个工作是比较简单的，我们也不需要自己去部署一个系统去专门完成这个事，我们直接用FC在线去把代码写好。然后这个代码主要它是去读这个ACM配置中心里的一些信息配置，比如这个配置项，我们指定的是一个UID，是外部的一个用户的他的这个ID和它本身用户在我们的这个处理的优先级的这个映射关系，我们把信息存在这个配置项里，然后我们通过FC去读取这个配置项，然后把这个接口，因为我们这是一个HTTP，HTTP类型的这种函数，它可以对外暴露一个HTTP的接口，然后给这个领域为中心，让他去动态的调用。当我们把这些配置好了后，我们还需要是我们需要配置一个事件处理流，这个事件处理流是刚才我们配置好这个数据，我们这个数据源里面选择这个数据，然后把我们想需要的信息，通过这种匹配更新模式的这种方式把告警的信息带到刚才我们看到那个接口，然后返回的是这个问题。返回这个之后，我们可以我们可以是拿到这样一些标记，并且打到这个告警上。这个是能完成的这样一些事情。还有是像告警中心，刚才我们的是一个告警，他如果只是一段纯文本，它的执行效率是比较低的，我们也可以通过认领关闭，关注，屏蔽等这些比较有用的功能，去把我们整个这个告警的质量去提升。这个也是一个告警中心提供了一个比较比较有用的功能。
因为告警我们事后肯定是需要复盘的，在复盘的时候需要知道我们每个人处理多少告警，这个这些告警我们用了多长时间去处理，这些告警平均的恢复时间是什么，这个在我们刚才引入了这样一些认领关闭恢复屏蔽的这些机制之后，这一点可以办到，因为实际上我们在处理告警的时候。arms告警中心，帮我们在后台记录了一些事件的日志，并且通过这些日志的分析，提供给我们这样一些有用的复盘的信息，让我们每次去review的时候，更方便的去用数据去说明一些之前不知道的事情。
还有最后一个是我们刚才整个是到告警和他的一些应急响应机制，我们在拿到这个告警后，我们可能还需要真正的去处理问题，处理问题，像我们当然希望是一切都能在一个白白平画的界面上去点击，也不用去SSH到某一台机器上，或者某一个pod里面去去手敲一些命令，这块我们也可以自己去开发前台界面，但是这个效率是比较低的，所以我们也是用了grafara去做我们这个整个这个白屏化的这个运维工具链。原理是我们在配置大盘的时候，我们引入了一些动态的信息，并且把这个动态信息以这个链接的形式去拼接到了这个转发的这个大盘里，可以给大家实际的观看，我们在这是有各种各样的，因为我们有各种各样的系统，而这个系统之间跳转的，如果我们没有这个官方的做这个链接拼接的话，我们可能需要自己手拼url，或者是到另一个系统里去搜各种各样的东西，这个效率是非常低的，那我们通过在grafara切入这种链接的方式去把我们想要的一些运维的动作都成这样一些链接之间的跳转，这个对我们实际效率的提升是非常有帮助的，并且能整个我们也可以通过grafara一套完整的工具去把所有的事情都完成，这个也是能够去标准化的去固化我们运维动作，减少人工出错的可能性。
最后，总结一下，我们整个这套体系目前还有一些未来即将要去完善的一些工作，也给大家打开一些思路，首先第一点是告警准确度和接手率的这个优化，我们刚才的是我们拿到了这些告警的这些复盘的信息，这些信息我们还没有想到一个特别好的方式去把它很高效地去利用起来，之后，我们尝试通过这个告警的准确度和接手率的这样的一些信息，去及时调整一些不合理的告警阈值，并且我们可能会去尝试多阈值的这种告警，比如告警在A到B这样一个范围之内，它是多少等级，然后在B以上是多少等级，或者在C以上他这是多少等级，这是一个多余值的这种告警模式。之后是还有一些数据类型的联动，比如我们在排查问题的时候，除了刚才到的这个 matrix trace 和 log 之外，还有一些 profile 的信息，像我们cpu的火焰图或者等这些信息，这些信息与可观测数据的联动，现在来看还是不太够的，通过将这三类数据和发展进行联动，也可以提升我们的问题排查的效率。还有是埋点成本的控制，虽然我们都是跟arms本身都算是内部的这种的系统，但埋点的成本是我们需要控制，像大家作为外部客户来讲，这个埋点成本当然也是也是更重要的，因为它直接关系到整个客户使用阿里的这个成本，我们通过是我们会定期的去对四监控指标的一些维度，一些发散的维度，比如 POD 里面的一些，UUID 等这些比较发散的维度，进行一个针对性的治理，并且对于一些无用的维度，做一些数据清理的工作，让我们这个埋点的成本控制在一个比较低的水平。
