阿里云可观测峰会-行业实践分论坛| 学习笔记（三）-阿里云开发者社区

开发者学堂课程【阿里云可观测峰会-行业实践分论坛：阿里云可观测峰会-行业实践分论坛】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/776/detail/13940

阿里云可观测峰会-行业实践分论坛

三、友邦人寿可观测体系设计与落地

今天要给大家的主题是友邦人寿可观测体系的设计与落地。PPT将分为两部分。前半部分主要是由给大家介绍一下人寿的业务架构和特点，然后会介绍一下当前遇到的一些具体的特点，就会讲一下是如何思考和设计，客观的系统去解决当前遇到的一些具体特点。后半部分呢由阿里云的另一位去具体的介绍一下是如何实施的客观的系统的

1. 个人介绍

是来自有关寿康熟悉部门的应用负责人。在保险行业从业近十年一直从事保险核心系统的架构和研发工作。服务的企业管理层对保险公司有很多海外的保险，这些分别来自于南美巴西，拿下印度等等，沙特，地中海小岛、塞浦路斯，荷兰，并且一直花大力气推广和应用原生技术从事原生应用的设计工作。会给大家介绍一下友邦保险人寿以及的业务架构。根据商业过程中遇到一些问题和特点，将展现给大家看，是如何思考和设计可观测系统的落地和实施的。友邦保险是在香港联合交易所上市的人寿保险集团覆盖18个市场。友邦保险今日的业务成就可追溯至1999年逾一个世纪前上海发力，截至2020年12月31号集团总资产是3400亿美元。保险于1992年在上海设立分公司是改革开放后最早一批获发个人人身保险业务营业执照的非本土保险机构之一。也是一家保险营销员制度引进到国内的保险公司，2020年6月，友邦获批将友邦保险公司上海分公司改建友邦人寿保险公司，2020年7月有关人寿正式成为中国内地首家外资独资公司有APP，在2021年荣获最佳保险科技平台，欢迎大家去appstore，华为市场，官网去下载体验的服务，保险业务流程很复杂，大致来讲可以是应用的客服工具去发掘用户自身的保险需求，最后承担，然后引导用户注册并使用的一款游戏APP，运营和管理的客户，这里面会涉及到很多业务和系统。

为了进行友邦健康长久好生活的slogan，过程中对应用做了大量的危化改造，快速变化的业务要求和系统要求，并且把原来一些在S400里面程序做了微文化的改造，提高了可能时间，会获得更好的弹性扩容能力，采用了容器化的方案，应用运行在里面，或者在弹性情况能力和自学能力，但是这样做，其实给带来了幸福的提升，观测微服务的运行，观测KS形成了的挑战。还有一个应用因为历史原因是外采没有源码，评估价太高，不适合做微服务化改造，但是仍然对这个问题进行了容错的改造把它们部署。还有一个应用因为像的服务之间的调用就涉及很复杂的情况，签约之后实在的带来了L提升，但是访问内容不出复杂度也比高很建设一个好的观测。会面临以下一些特点。

首先面临第一个就是观测复杂度的提升，原生微服务化虽然带来了很高的可以，但是总体提升系统系统的复杂度要给带来了可观的幅度的加大，比如说的保费计算成功率。交单成功率，用户的日活，月活，其实都是散落在各个业务模块，是否可以提供一个全局的视角给业务，让可以观察到整个生命周期里面一些重要业务节点运营情况，原规划之后，其实是后来要解决的事情，还想知道一些研发的具体状况，比如说：就可以知道一些研发具体情况，到底发生了一些哪些问题。

第二个，就是技术转型困难，由于一些历史原因有传统的基于受理的应用，有基于struts应用，有web ：Sernerless应用，但也有捷径的开发利用技术，选型不一，版本各异，导致选择可靠的技术和电动方面，其实面临很大的困难。

第三，就是统一关的困难，友邦一家金融公司能够开发系统运维就因为其实是完全分开的，之前的日志组合库的，没有一个办法让这些数据在同一个界面或者同样里面去呈现。举个简单例子，在IDC机房时代应用，如果知道一些日志需要登录到具体服务器上去，如果是多实例部署，不知道日志在哪一台上面，就是把所有的日志都拿下来去分析非常不方便

第四个特点就是指标志，应用程序其实是非常多的，只要单单就数据库来说可能就有超过两种指标，怎样才能压缩这些指标比较容易比较理解跟追踪的一个数量，就需要不断的去回顾去删减这些指标。

最后一个也是最重要就是快速故障定位，在ac集团时代其实没有一个很直观的方式让应用知道自己利用资源是不够的，虽然已经有一些商业的一些工具但是那个比较贵，没有一个经济有效的方式让应用产生一个当前的瓶颈，当问题发生的时候，因为只有少量的应用安装了APM，所以应用是不完整的无法做到快速的故障定位。

在了解完自身的系统结构也有特点，以及的观测中的一些特点之后，梳理并确立了分系统建设步骤，还有分这几个阶段，在方案设计阶段，一直在思考什么样的关系才是一个好的符合自身需求的关系，认为至少要满足这5个要求，服务资源的追踪,可以把服务运行点上的cpu、内存、网络、磁盘应用指标也聚合起来，当问题发生的时候，可以很方便查到是哪个指标出现了异常。

第二个，可以提供服务可观测试图，试图按照服务量调用服务的解决耗时，按照服务热点排名，这样的话应用可以很方便，知道哪些API是一个热点，API请求量比较高，那些API的ARP时间较长，这些方面去规划支撑的服务资源

第三个就是提供教练的这种，从API接收请求，最后一个依赖服务能够把这些请求串联起来，并且最好是无侵入式可以从tures很方便的去关联到日志，这样当问题发生的时候可以帮你知道当前是哪个链路出问题。

第三，就是调用时长分布可以观察到服务的，可以帮助观测到上游跟下游，可以观察到一步的一些耗时，等到出行启动慢的时候就可以很方便观察，到底是当前的服务应用比较耗时

最后一个就是可以关联数据库的操作，帮助应用观察到关联接口存在值得查询存在问题查询这种存在慢查询等操作。

下面就请阿里云右京同学去介绍一下是如何实施和观测系统，

刘晓花名右京，已经来自阿里云今天交付技术的原生交付专家，从2015年开始就一直在前线探索世界和不到云原生相关的技术工作，右侧可以看一下，这是团队提供的云原生交互服务，如企业文化it治理，南宁中应用容器化，还有微服务架构咨询和可观测性咨询，最后还有CMA品鉴中心，有需要的话可以了解一下，减免客户审批提到有关，为了满足业务发展需求，在技术层面需要做云原生技术架构的升级和改造，因此和客户再应用溶剂化和可观测性上展开了深度的合作

下面来介绍有关可观测的设计和实施部分。结合客户的业务的情况和监控的重点，通过几十次的讨论和推演，最终明确了两个重要的建设思路

首先根据业务价值自上而下的设计和观测体系，从业务监控、应用监控和资源监控一直向下推进，在此前讨论碰到的误区是之下而上设计的，后来发现其他企业都存在类似问题，什么意思比如一上来我们就会关注一些资源性的一些指标，像CPU ：应用系统的一些日志，日常的一些日志，那么这样会存在什么问题呢，就是说如果出现问题，团队会浪费大量的时间和精力。经历在排查一些从来不会导致客户受影响的一些问题，或者说客户和老板优先发现了一些问题，那么无疑这个监控系统是失败的，所以首先需要关注和设计跟用户体验或者核心交易相关的一些业务监控，比如说来关注投保人数，投保金额的一些指标来回答这个业务是否出问题。

其次需要结合业务设计服务的一些列入追踪应用性能监控，比如说，把某一个应用的XXXAPI接口翻译成业务可读懂，比如像保单生效的接口处理时间和处理数量以及这个价格还调用了其他哪些服务，或者说依赖了哪些服务。还有一些像比如说IBS的一些买车的一些组件，或者MQ的一些组件的来最终回答哪里出了问题

最后需要结合应用的诊断工具，像结尾M的调优工具，还有应用日志以及向资源级别的监控，如容器，虚拟机来最终确认到底是代码问题呢，还是底层资源的一些使用问题，资源问题，这样从确定事故发生定位引起事故的原因，进而再确认问题的本身，来提升故障的发现和问题定位的能力。那么再确认了自上而下的可观测体系之后，接下来就需要明确和观测的指标范围

基于客户识别在前面完成，重点里面提到研发过程当中的度量指标，其实是缺失的，所以认为可观测指标不仅仅是运行，还得把研发态加入进来形成应用全生命周期的。先看一下研发态，看系统经过原生改造后，有关的cip流水线都是通过GPS进行自动化的，为了提升软件的个研发效率，就需要侧向出可衡量的一些指标，没有度量就没有改进。譬如应用每天的构建次数，构建时长还有构建成功率，以及部署频率或者部署成功率，还有行程这些指标的一些基础元数据清晰的

第二块就在运行态分为三层，这样监控重要性等级依次是升高的，资源监控层主要聚焦在K8S集群的node节点磁盘网络还有运行PUD一些监控，还有核心产品，比如像SLB，MK，数据库等这些监控指标，应用层的话，主要聚焦在应用的健康度，状态码，还有用性能的监控，比如像RP，RPS，还有错误处，还有JM的节点，这些性能指标上面个业务成长，主要监控的这样一些业务的核心指标，如PV，Uv，包括投保人数，投保金额，还有投保的签单数等等，这块儿是直接影响着监控系统的一个设计的一个成分，或者说好坏，因为这是最能够体现业务价值的，也是领导最关心。

前面可观测性体系的核指标范围的建设思路已经明确了，接下来就需要在架构方案和技术实现上进行设计。右面的一张图，总体的设计思路分为三层

第一层是采集场，看左下方的研发态的数据采集。因为要符合有关的技术架构和建设需求，选择用Java自己编写流水线的CD的数据采集器，当研发同学在使用产品时进行应用的一个viewed或者deploy的时候，该采集器能把应用构建的数据和部署的数据全部存到数据库里面去。另外在这个采集数据的时候，加上了相关关联的一个tab，之前的个原数据的共享，比如流水线构建的应用名称必须和开发室的服务名称是一致的，这样构建失败的时候就能够快速知道是哪个应用出错。

第二，针对应用的ATM探针，社区一般使用字节码增强的吴兴路技术，比如，像国内做的比较好的skywalker，但是由于有方架构的复杂度，比如同时会存在是一零年左右的4X架构，现在spring ：cloud的一个架构，SKY探针，不能完全覆盖这种场景，所以第一步就考虑AMS这种，同时对深度，性能，诊断也是有比较高的要求，希望能够提升一下阿里开源的member ：down的能力，同时ATM探针会影响应用性的，所以最终选择了经过双11大规模检验的，对于各类云产品中间件容器集群的监控指标采集，通过prometheus的各类export进行采集，prometheus作为云原生领域监控的一个，在社区已经形成共识了。用这个采集主要使用MS的方式进行采集，相比sight的占用资源较少，工程上也比较简单。

第二层是存储层，对存储数据源的选型思，研发肽的元数据，pipeline的构建，数据存储在Mac里面，因为这部分数据量不大，而且是结构化的像个max监控指标的数据存储在阿里云的prometheus上的产品上，日志和调用链数据存储在阿里云的SS产品，因为考虑到业务的增长未来会产生大量的数据，这两款产品，能够保证监控系统的稳定性和可扩展性，还有高可用性。同时，产品都是Sernerless化的，只需按量付费，也不存在磁盘或者说空间的浪费。

第三层，就是最上面一层叫统一展示层。选择使用可能方法进行汇聚和展示广泛，作为一款开源的可视化的爆款产品监控搭配大盘的标配成长内部再选型的时候讨论一些是高度一致，另外为了保障运行的高指挥数，并且将数据统一传入到数据库里面，然后根据之前设计的指标选择对应的数据源编写查询数据结合丰富的图表进行统一的展示就能做非常酷炫的大屏

重点介绍一下业务监控的实现，把采集到es里面的业务日志、业务日志做统计分析，像SS这种SQL的查询功能非常丰富，语句的编写也非常方便，比如说数据总量环比，同比等等，之后呢通过SNS广告的插件集成到可研发里面，这样的业务统计数据就能够在可研发放到它个平台上展示出来。

最后给大家展示一下的建设成果，整体通过大屏中屏和小屏的方式，形成指挥决策，研发仪表盘，用性能展示，包括告警推送，多维度的监控的能力。其中左侧的大屏放了业务的核心指标，容器集群的资源利用率，包括surface的健康度，以及联动性的通用指标，进行全局的呈现。给公司的领导和家公司提供决策支持又长放的赠品，大家可以看一下，主要放了流水线，研发效率指标和应用性能的指标还有防止调用量，帮助研发的同学提升效率和问题定位的一个速度。右下方的个小屏，通过历史数据的对比设置了报警的阀值，当出现异常时，通过钉钉或者短信报警的方式推送到电脑、手机终端，帮助运维的同学能够及时的发现和处理问题。以上是整体可观测性建设的设计方案和实施效果。今天分享的内容到此结束，欢迎各位朋友到群里继续交流。

四、阿里云 ACK 容器服务生产级可观测体系建设实践

来自阿里云原生 ACK 容器服务团队的冯诗淳，接下来就为大家带来阿里云ACK容器服务生产即可观测体系的建设与实践。

首先先介绍一下阿里云服务器团队，责阿里云公有云上的云服务，然后在2020第一季度，在权威机构Forrester发布的公共农技服务分析师报告中，阿里云容器服务团队荣获了顶尖Google的全球领导者相信评级。这也是首次由中国科技公司进入该领域的领导者。然后可观测能力在分析师的报告中也是占有不可或缺的地位，然后ACK的观测能力也是得到了分析师非常高的肯定，分析师非常不吝啬地使用了excellent等等的词汇，说明的观测能力是非常的接触的，而且在产品间也是做到了无缝的集成，是很有效率的。为异常诊断和就是服务的业务中提供的能力，这个也说了就是客观测试构建用户的It系统和业务体系的重要组成部分。

接下来介绍一下就是整个position的大纲，首先从三个方面来介绍，第一个是介绍整个ACK选择体系的介绍，然后其中会就是介绍整体的全景概要，以及从就是可观测非常经典的三大自主学习平台，这个三个方向具体的介绍这个体系的组成部分。

第二，会在第一部分介绍各个体系的过程中穿插的介绍不同部分的一些常见的时间场景，然后包括了业务系统的工程条件，以及就是稳定性的保障，产品已经在生产期的规模几分钟稳定性的保持的时间

最后一部分，会介绍就是利用这些ACK可观测的能力，如何为客户快速建立们的boss体系，其中包括了就是X ：it和ios，以及最近比较需求比较强烈的反应体系。

首先就是看到的是ACK体系的全景图金字塔，然后ACK的可观测体系可以从上到下分为四层，然后最上面是就是最接近用户接入的业务监控，其中包括了用户前端就是包括前端的流量，基本上以及前端的系统，JS的响应速度等等的一些监控，以及就是的入口目标会通过。Open ：Telemetry来监测，就是English的请求、请求量以及请求的状态，然后用户也可以定制它的业务是指通过长期服务的日志监控来实现的业务自动监控。

然后第二层包括用户的应用监控。有OCPM这种APM产品，提供用户的，比如说Java，还有tures等等，也支持open ：open去协议多元的这个方案，然后再下来是容器的主体，容器的主体就是容器的

容器层包括了容器的技术资源容器的，容器引擎的基础的稳定性。然后其中使用阿里prometheus能够占的比例当中展示不同集团层面的资源应用，然后系统，其中也包括您私人，其中包括云监控产品提供云资源的监控能力。然后其中容器厂也包括了世界体系以及日志体系，其中是由的世界中心和政治中心覆盖。

然后再下一层，就是最底层是的基础资源层INF的问题，其中囊括了不同的云资源，虚拟化，操作系统内核等等。容器厂和最下面的基础架构层，都可以使用，基于无侵入式的加入日志的监控能力来做网络和调用的整体推进。ACK的可观测体系自上而下可以用这四层拆分，但是每一层综合观测的三大支柱有着不同程度的影响。然后等会儿会从三个节点三大支柱的不同维度来详细介绍各部分的

一个例子串联一下整个ACK的综合体系，这是一个用户的异常诊断的案例，这个用户有一个线上系统跑在ACK基础中，然后线上其实是流量有朝九晚五的不同，业务不同造成这个应用会跟随这个不同高度，不同就产生不同的水位波动，然后这是一个用户这个业务在早上九点多发生，就是业务流量激增的时候出现异常诊断过程，然后首先收到了业务报警，可以看到核心的一个PUD出现了单的情况，这个时候用户收到之后就可以快速的进行执行对这个核心系统进行重启，或者进行扩容，进行马上的执行，然后用户市场开始找到就是这个问题原因。

首先通用流量的这个角度去分析，看到当时确实出现了这个整个对外访问成功率。下降以及出现了499的这反馈一个请求说明，其实这是非常是经常用的，然后再从资源以及拓展层面，可以看到确实是由于流量导致的水位复杂，但是在当天早上九点的时候会有一个工程队气氛明显的水位的飙升，这也就是库场所在综合上面的这些问题，以及就是第一时间报警出来的这个核心业务的PUD的地方，然后结合了就是下面的业务进行分析，可以看到，当时的任务确实是出现了异常日志的异常日志的输出，然后根据这个日志输出，加上使用了上次加的屏幕应用监控。

然后可以看到代码定位到当时就是产生了一个缓存bug，由于早上九点左右就是飙升的缓存引发了bug，最后造成频繁的数据库出现这个调用结果反应可能出现了数据库的查询，最后通过修复bug，然后彻底的闭环了整个异常，这是一个非常就是典型的贯穿了整个ACK和观测沟通能力的一个异常的排查过程，也帮助更好的理解就是ACK整个可观测体系是如何相互如何相协调的。

然后首先先介绍一下，就是整个异常诊断，发现问题最快的一个手段，也是就是KYS场景下经常容易被人忽略的一个手段，就是在login体系里面，其实KYS包含了就是事件的体系，就是事件体系，属于login三大支柱，Logic这个分支，然后在社区的KYS中，其实就包含了非常成熟的时间体系，然后社区的KYS提供了应用藏的时间，以及runtime的时间，然后ACK可客观体系在社区的可观测体系之上做了从表层到底层都进行了覆盖和增强，做到了事件体系的就是全部看。

首先就是从最上面的应用事件就是也提供了就是用户的灰度发布异常事件，以及就是HPA等等到异常行为的事情。然后增加了office的问题，就是集团化控事件，包括用户对基层的日常操作，以及重要的变更，甚至是成本和预算的超标等等。然后接下来提供的就是集群核心组件立场。集群的稳定性其实很大，一部分是由集团的核心组件的健康来保证，集群核心组件包括PSD，CDR等都做了异常事件的增强，如果出现异常事件会第一时间进行触达，然后也包括融合出现背景太亮之间，包括存储等等

然后也就是做了一些就是容器阶层的增强，包括了DBS结构等等立场，然后底层就是不光是容器层，容器资源层，整体的基础资源层，包括了操作系统，也会就是整合到整体的一个生态体系中，当这个集群中的节点出现了操作系统，配合档期，档期以及一些操作性配置的异常之前也会整合到的acg世界体系中，当然操作系统就会更加测量值，就是的资源的异常，目前也是能够统一整合到ACK的实践体系中，所以当同时用一个容器服务的咨询师，也是可以感知到一直到一层的异常事件作为的重启服务的运维保障，提供更强的覆盖和保障能力。

刚才介绍的就是非常复杂和庞大的世界体系，在产品能力上，用户是如何使用这些能力。其实很简单在SBS中提供了开箱即用的世界的能力，在购买容器中之后，可以见开启市场中心即可享受刚才复杂的世界体系，有预知的事件大屏，会对重要的事情进行突出以及统计。同时事件中心也提供了水分的能力，为后面基于事件驱动的体系提供了能力基础，然后ACK集群更多的社会资源的生命周期进行管控。事件中心也提供以事件为盲点的资源生命周期的监控能力。可以看到这上面就是一个PUD的生命周期中最重要的几个时间点的时间，事件可以以此进行性能的调试优化，以及对异常状态的快速反应

事件体系解决完了之后回到副类日常体系。Booking在中主要的使用场景，首先是重要的流量English等等。在ACK的日志中默认提供了English等等这种重要场景的默认大盘，可以在接入English大盘之后，快速的看到的几十元的流量，其中包括PV，UV，还有就是应用的异常状态等等以及统计快速清晰并运用。第二个场景是审计场景及群众的资源，经常被不同的账号访问使用，集群的安全也是日益需要重点关注，然后提供了审计日志，还可以快速的分析技术的资源的访问和使用问题，然后在未被授权的这些访问中可以进行报警和理解，会继续提供更安全的环节，最后也是最常用的，就是如何快速的在从里接入用户的应用支持。提供了原生的无切入式的日子获取方式，只需要通过一个简单的CD或者是在POS上打一个，就可以把后台生成采集到的中心并享受这种新的多维的强大的分析能力。

日志体系介绍完了之后，来介绍覆盖产品推广的metric体系，metric体系，首先是在做稳定性保障和性能调优时最常用的体系，水位的指标等等，都通过大盘直观地为用户进行展示。然后也是运产品册预知大盘的产品体验。购买了一个ACK的集训之后可以见着开启prometheus的大屏，也预支了重要的场景的prometheus这些大屏都是经过上面业务运维的成熟经验的沉淀。然后prometheus方案会涉及到不同的服务，不光是包括容器测、容器覆层，其中包括最核心的的应用网络，然后核心的控制面的指标，还包括比如说B场景gpu的指标以及存储，比如CSY等等。

外部存储产品也包括了资源的优化，或者是成本的优化指标，然后使用统一的prometheus数据，这种方案能够不光是能够支持容器尝试的指标，也支持云产品不同产品的指标，以及甚至于产品上不同中间件的指标，可以做到所有的成绩的指标都在统一的prometheus数据链路中，然后进行统一的大屏展示。然后集群控制面的核心组件，包括图片、色彩以及PCM等也做了这部分托管的核心组件指标。后进群不只是托管，负责托管这部分的核心组件。负责维护的SV，同时也会暴露透明这些指标性的给到用户，让用户使用的安心。

然后指标场景是稳定性保障的一个重要知识点，然后这里很荣幸的就是有这一个案例，就是把ACK非常荣幸的为2022年冬奥会助力冬奥的系统圆满平稳的运行，然后ACK系统ACK集群中部署冬奥等多个核心业务系统，包括冬奥的过程，然后票场就是比赛场馆的票用性等等，然后也是为这些多个核心的功耗系统保驾护航，然后这些独特核心系统，多维加系统架构，当真正使用的时候会有近千个的实力，而是通过进入了压测的方式，首先先合理的进行容量评估，然后在生产的时候，然后同时配合为冬奥就是配置首评为大盘实时的进行应用把正当时保证了东奥通道系统访问的说法。

说到刚才说到的就是稳定性的珠宝，然后第三个场景就是生产及的集训如何进行，就是基础的稳定性保障。就是很多用户的生产系统其实是规模很大的，就是常常到达了千级别节点的集群规模之后，用户在技术上的应用，有时候会进行密集的大规模的集群资源访问，这个时候经常会出现技术稳定性的一些问题，指标的增强为这个这种场景及稳定性的场景做了更多的保护。

然后这种获取两个最常见的场景，就是用户在这种大规模集群中频繁密集的访问集群资源，会影响首先问题影响到apiserver如果出现这种情况API会较高，会处于一个高位，然后so的技术也会出现一个高位，然后这个时候负担其实是很高的可能会出现状况请求的丢请求的情况这是ISO的一个，就是降级，降级的特性，然后这个时候其实是有可能像这种业务的发布，或者甚至影响变更，第二个，就是当这种密集的资源访问情况出现的时候，也可能影响的是，然后看到这种情况就是的请求延迟，体会标志高位，可能一次ABP的访问可能出现。这个时候很有可能影响用户业务。这种情况的支付只读请求数会飙升。遇到这种情况的时候，提供了这种核心组件的结构，可以快速的发现这是ABS的水位和请求之间的一些问题做到问题的发现。

然后第二步可以根据adsl的防治。快速的定位是哪个应用做了什么动作，导致APS的穴位和资源请求，最后配合用户定位，最终找到对应的进行执行最终闭环问题。这就是生产期一些集群的保障事件

这里的话也介绍一下，近期推出了promises ：for ：ack ：Pro，这个是的prometheus升级的一个升级服务，包括了多个数据源的监控，能够在同一张大屏上看到多个数据源的，包括了基本事件日志，还有就是后续会介绍的GPS和城市的应用指标，网络指标等等，做到极致的体验用户。

通过关联分析的逻辑。从动态到细节，然后通过多数据源这种多角度的观察能力，不同角度的一些排查。最后查到就是可以更好方便用户进行稳定的保障，以及异常问题的发现，最后快速更快速的就没问题。就是这个升级图敬请期待

最后介绍一下Tracing体系，在客观的体系里面Tracing是最早能够定位，就是定位问题跟能力。首先在ACK里面推行体系分为两部分，一部分是应用场地，提供放CPS能力，其中也支持openid协议，这种协议使可以支持多种语言的应用，然后当比如说Java，也可以提供无切入式偿API能力，只需要在ATPUD上打上一个ATP，然后Java应用活动享受实时的监控数据服务也可以看到实时的应用水位。以及鉴定指标。

也可以看到应用上下游分布式和微服务的全局调用。然后再加上一个条件。您还会享受profiling 以及多维占的标准，不同语言可以汇聚成同一张微服务分布式调用追踪大图，可以看到分布式调用从而定位这个问题。

然后近期也推出了基于ETF能力的网络层面的推动力，通过技术在内核层面实现了很大的改动，而且是非常低的性能消耗的一种网络学习的能力。可以看到，提供了全职TOP快速定位问题的的一个网络，但是以及资源层面的展示，然后也支持后面统一的。在这场统一的全局架构视图中，会集合多个账号进行统一视角客观地观察。

最后介绍就是基于这些观测能力的利器，其实真正需要帮助用户建立成熟和可靠的体系。

首先是推荐使用事件驱动的aiops体系，用户可以通过事件来作为统计驱动生产进行问题的发现，负数，以及的AI就是智能化的运维操作的一个桥梁，然后在ACK事件中心为核心构造了一个就是统一的时间格式的规范，然后的事件会统一的市场配置格式的规范提供给用户，然后最后会就是运行的事件视界中心为核心，然后其中还包括比如说镜像的一些构建事件，最后通过统一的一个事件处理由给到用户，这些事件会统一的收口输出给用户，用户可以通过订阅这些事件去做这些事情的智能化的一个动作，以及构建的Xbox就是体系。用户比如说可以通过某个应用的业务进行业务事件的推送，并且对事件进行智能化的处理，比如说智能的扩容或者缩容等等。然后也提供了ACK报警，通过统计的报警配置，为用户构建ios的体系，帮助用户快速建立运维的就是订阅和收发和问题排账和处理的体系。接下来会介绍首先是刚才说到就是保险中心会为用户提供统一的配置，帮助用户快速的建立。在ACK场景上的异常诊断的异常规整期，首先不知道大家有没有遇到这样的问题，做一个业务的人员可能最头疼的第一个是没有能够完全运维整个系统的经验，然后ACK已经提供了相应的奖励，沉淀了常用的勇气，常规机开箱即用即可继承这些成果的总结，第二个可能要头疼问题，发现了异常，但是处理这个异常的人是需要快速的匹配这个异常和真正能够处理这个异常任务，所以可以通过报警消息的系统平台的关系，构建体系，不同的异常可以通过重新的订阅配置关系投递到真正能够解决这个立场的人，然后，再就是无法快速的找到处理这个异常的标准处理流程。

然后目前ACK也沉淀了标准的异常，以及对应标准处理的sop手册，可以看到当发现一个警告，这个应用是什么类型的，然后可以给用户提供处理这个异常的标准Sop修复流程。

介绍一下最近需求将增加CF的体系，可观测试数据的来源提供方，公司体系离不开数据，首先这个视频的背景是在近期价格较大，用户其实越来越多的，其实遇到了上云上云阶段，或者已经上原治理阶段的就是上征信的问题，用户会就是遇到尚品之前如何上云的规划，然后上了之后云产品种类丰富，以及这个技术用到的资源类型丰富计费，然后第三个就是可能有用户，是高度SaaS的应用是在同一地区中进行共享，一个应用如何分摊的成本增长，就是每年都有新的业务生成，每年都有新的业务下线，然后集群资源使用关系，谈谈如何进行持续优化治理，最后就是这些能力尝试使用Excel表进行管理，然后这种老式的方式在于人的场景下有丰富的用户利用，有丰富的账单资源管理。然后JK提供了原生企业，It成本治理的方案，然后通过多维度的成本分摊和估算的模型，为一个集群的资源进行成本估算，然后可以通过跟一个下降的趋势的预测进行洞察，集群上面好多应用业务的成本，可以细腻的下方进行成本，容器场景包含了多种场景，AI多集群等多种场景的成本，会有成熟的这个发展。以及，提供企业升级，首先可以让容器场景的计费成本以及分摊算清，接下来还推出了类似的资源以及应用资源的智能推荐可以帮资源推荐的成本，所需的成本，以及进行预防控制，最后会根据不同的场景进行成本优化，如大数据、AI、游戏等等，最后场景的支持也是多样化的，包括多余和风格与等等，都会在统一的材质平面进行展示和统一管理。

然后Philips体系，由于比较新所以还是比较难理解。这边是一个非常就是实在的例子，就是中华财险，中华财险这个客户是在就是进行了一个从传统it架构到原生化的过程，是会有千亿，千和集群的规模，然后业务是非常多的SaaS化的线上业务，具有高度的多重化。然后也是金融行业的客户，对业务的要求非常的高，而且对成本的趋势敏感度也非常高。然后就遇到了刚才说的就是容量规划，算清成本，然后这些潜质资源能发现，以及就是这个成本优化和业务平衡的一些挑战，然后通过ack 的成本制，这个方案对进行了不管是压测进行对话，还是通过的产品分析进行业务分账的账单，账单管理和分析，然后最后成本分析帮助找到了资源，闲置资源的中华，以及就是分配为提供了分配资源的优化策略，最后容器服务还提供了弹性等策略的一些优化手段，最后通过这些在整个上课的过程中，整个群的资源的分配率可以达到30%多，这个是比较浪费的，然后可以做到非常好的10%以下的集群资源闲置率，这个已经是行业里面非常好的就是一个非常典型的在上升过程中进行承担治理的一个难点。