腾讯在云原生可观测领域的探索与实践。原创

啊，今天给大家介绍一下，就腾讯在云原生可观测领域的探索与实践啊，首先自我介绍一下，就我叫罗佳李，然后是腾讯云的可观测平台技术总监，然后之前的话在主导过QQ以及空间等等多个核心模块的后台架构设计，然后现在是主要负责监控可观测这一部分的一个，呃，平台能力的一个建设。然本次分享的话，可能就呃主要围绕着四个方面去进行，首先是整个腾讯在可观测的一个发展的一个历史，然后我们的现在常说的magic log，推罗老师，您那个PPT，那个屏幕肯定要共享一下。哦，不好意思，不好意思，对对对，只听到声音没看到，OK，不好，应该可以啊，对对，现在可以啊，麻烦您一下，谢谢，嗯，好好可以了吧，嗯。可以了，你继续好的好的就是首先的话是介绍一下腾讯在可观测的一个发展的一个历史，然后我们的指标链路以及日志的这样几种能力是怎么去有机的结合起来的，然后会讲一些我们腾讯内部的一些可观策略案例的一些分享，以及我们整个腾讯云的一个可观测系统的设计与实现。

就首先我们来整体纵览一下整个我们的可观测的一个发展史，其实它是随着我们整个我们服务的一个架构的一个演变而演变的，那从最开始我们单体应用，然到我们的服务数量逐渐增多，我们的同时我们并行的开发者的数量也在增多，然后我们现在的容器化，微服务化，然后到逐渐的向servicemash网格化，这样的具有更强的调度能力等等这样一系列的技术的出现，我们整个我们的。一个从硬件层面来看，我们的从物理机，然后到我们的虚拟机，然后再到容器，然后再到可能无服务化等等这样的越来越虚拟化程度越来越高的这样一种方式，其实我们的一个可观察的手段，我们从日志到我们的指标，以及到我们的催性也是它是跟随的整个我们架构，以及我们的整个。

那么硬件体系，包括我们的容器体系的这样一个演变，而逐渐去演变的，那但其实我们大家可能都在谈这个东西，但到底它底层它或者它的细节是怎么样去去去从从日志，然后到指标，然后再到一层，怎么样去这样一个很细节的这样一个过程呢？其实今天就跟大家一起来去。分享一下我自己对这方面的一个思考，就首先我们从最传统的这样一个日志开始说起，其是从我们最开始我们写下第一行代码，我们去打印一个hello word，其实我们就是去写下了一行日志，我们去我们从我们的计算机最底层的数据结构去解析日志的话，其实日志它是一种非结构化的，是一种非常松散的一种数据结构。然后从我们后台的单机日志，到我们远程是再到我们一些进行染色的一些日志的一些能力的一个建设。然后再到我们客户端的日志，就比如说我们很多各种各样的iOS安卓的一些一些。

客户端其实我们的日志它可能装机量有上亿，甚至几十亿这样的一种规模，它是不可能去做到一个全量上上报客户端日志的一个能力的，所以说我们很多时候我们自己像一些我们，呃腾讯内部一些。那个早期的一些能力，它是能够通过一个TCP的长连接，去捞取到我们客户所需要的那个那一台客，那一台iOS或者安卓那一台机器上面的一个客户端，一个日志。然后从这样的一个客户端日志到后台的这样一个能力，其实我们逐渐的会发现我们的日志数量在非常非常以一个非常快速的一个一个速度去暴涨，我们查问题的能力，也是查问题的一个效率也是越来越低。这个时候我们就会再去做继续抽象，我们去把日志这种非结构化的数据，我们去做一个抽象，我们得到了一个指标跟维度这样的两个概念，为什么要提这个点呢？其实我们会发现在我们去接触到一些客户数据内部的一个开发的，其实他对指标跟维度其实都没有一个很好的一个一个一个定义，或者说是一个。

一个一个理解，就比如说我们的维度的话，我们比如说我们是APID或者是UID或者是IP，或者是它的地域，可能去这样子，我们去通过这样一个维度，比如说这五个字段，我们把它叫做一个维度组合，我们去能够唯一确定一台一台虚拟机，或者说唯一确定一台MYL，或者唯一确定一台ready，是它在一定层端一它在一定时间内，它的这几个维度组合，它是不会去改变的指标呢，就是我们常跟常说的，比如说CPU的使用量，或者是错误数，或者是。或者是一些那个内存的使用量这样的一个，它是会随着时间，它可能在每每一小时的60分钟里，或者一天内，它都是会进行一个改变，然后这些指标我们可以去通过一些。去做一些聚合，比如说做做一些max，做一些的一些聚合，来去对指标去做一个处理。然后使得他能够去做一个主动的一个告警检测，这是我们之前的一个日志所不具备的一个能力，比如说这里。

我写了一点，就是通过APID等于1234啊或啊，而且区域地域等于深圳的这样一个一个数据，我们能够对它的一个every count大于100的话，就进行一个告警检测，然后到这里的话，我们能够得到了一个从日志这种无序的或者是冗余的无结构化的这样的一个数据，然后达到我们我们的自定义的指标，我们的能够有指标加维度这样一种概念去把它给。抽象出来能够更更加有效的提升我们去定义问题的一个效率，但后面我们发现我们每一次调用，比如说我们调用RPC调用HTP，我们都需要去自己去打这些这些指标，这些维度，这是一件非常繁琐的一个事情，所以说从自定义指标的话，我们我们去进一步的进化到了我们去。做一些无侵入的一些一些接入，把这些指标给去他给他去抽象起来，然后通过一个。

一个中间件去能够把这样的一系列的指标加维度给去给给他自动上报上去，这里其实提到腾讯内部应该在零几年就有的这样一个系统，应该之前的一个很老的一个系统的话，它叫做魔教，可能有的有的开发者会听过，他会。把我们的一些试计模块、主调模块、备量模块、接口这样的一些维度，然后加上我们的成功数、失败数、总数等等这样的一系列的指标给它在一个中间建，比如说以前用C加加的话，就是在它的构造函数跟机构函数里面，就能够把这样的一个一个数据给上报上去。然后这样子我们就能够确保我们每一个网络调用都能够被监控起来，而不需要我们去自己去在每个地方去打用打印日志，或者在每个地方每一次网络调用的时候去自己去上报一些自定义的指标，到这里，其实我们整个的一个问题的定位能力其实还是非常高效的，这因为当前还是一种单体的一个应用的一种模式，就比举个例子，比如说我们当我们收到一个成功率的一个告警，比如说它是百低于百，低于99.9%，低于三个九，它就告警出来，我们这个时候我们首先去看它这个IP有没有聚集，如果有聚集可能说明你是某一台物理或者虚拟机出问题啊，可以把IP踢掉，如果没有聚集的话，我们可以再根据我们的一些错误码，一些时间戳，然后等等这样的一些数据，然后再到更详细的日志里面去查看它的一个那个，呃，具体的一个业务代码的一个问题。

啊，但是随着我们整个我们的服务的一个服务架构的一个发展，我们来到了K8S这样的一个时代，然后我个人理解的话，K8S给我们带来了很多的好处，比如说弹性，然后比如说考核深度等等这样的能力，那本质上它的一个架构的复杂性，其实也为我们去定位问题带来了更大的一个一个复杂性，我个人理解最关键的点对于很多。对于我们一线的开发者来说，最关键的其实就是一个node跟pod的概念，我们现在我们的服务都是运行在一个个的pod上面，不管是有状态的pod，还是无状态的，还是无状态的po的，然后这个时候哦，我们当我们有一些紧急情况的时候，我们可以把pod去漂移到其他的node上。

啊，这个时候其实这样多了一层的话，对于我们整个的一个呃可观策略能力就提出了一个更高的一个要求，然后同时其实也是跟KS架构的一个普及，我们的服务也是服务数量也是呈一个爆发式的一个增长，就可以看到这张图里面，看到这样的图，就是我们去定问题是是一件非常非常难的事情，如果我们还是用指标加上日志这样的一种方式，其实我们很难得到我们想要的一个问题，定位的一个效率，我们指标的日志其实只能定位我们比如说A服务调用B服这样一个点对点的一个关系，我们能够像谷歌提出的那种黄金指标，也只是解决我们点对点的这服务的一个关系。但其实我们可能真正的比如说我们我们打开我们的腾讯会议，我们可能后台可能经过了可能几十次甚至上百次的一个服务的一个调用，然后这个时候其实崔的话。

就能够帮助我们去把这样这么多的一些一些服务去能够给它串联起来，然后通过我们趋ID，不管你是注入到其PC的协议里面，还是HTP协议里面，能够去通过我们的协议去进行一个分布式的一个追踪，能够去把整个这样一个服务给串联起来。所以说就是总结一下，就是我们云原生的一个应用的话，就是随着我们开发者的数量越来越多，同一个项目的开发者的数量越来越多，整个对我们的一个效率的要求越来越高，然后同时我们整个的一个系统也变得更加复杂，开发S给我们带来了很多，但其实它本身一个分层的一个架构，其实也是让我们整个。我们整个一个软件工程的一个层次变复杂，架构变复杂，然后同时我们的大块，我们的容器也是提供了很多我们的灵活部署的能力，但其实本身我们去利用问题的一个。方式也会变得更加困难，然后同时随着云服务的这样一个快速，各个云计算厂商的一个快速的发展，其实我们去依赖的各种各样的一些上下游的一些云产品越来越多，所以说其实云原生应用的这样的一系列的特点，这样的一系列的复杂性，其实就就给我们带来了一个很大的一个一个挑战，我们可观测的能力到底要怎么去。

帮助这样的一些原生的应用去能够去提升它的可观特性，其实也就是提升可用性。然后接下来的话就是，就是从我们的内部的我们指标，我们的日志，我们的这样一种串联的能力，来去来去讲解一下整个的一个可观测试，可观测的一个能力的一个建设。那首先刚刚说到的我们单体时代的话，我们是通过指标跟日志的这样一种方式去定位问题，然后我们我们推信能够去通过我们的tra ID去把magic login给串联起来。但是其实大家都在说这个事情，但是其实就很少有看到一些文章或者分享，它是具体是讲的是怎么去把咱们到底这其中的原理是什么，首先我们可以看一下那个。

我们的一个右边的三个圈，其实大家都可能都会经常看到我们的一个magic，我们的一个tra这样log这样的一个圈。然后这是我们理想中的一个状态，但其实实际中是到实际中是怎么样的呢？其实实际中就是我们遇到过一些一些客户，或者是一些不管是内部还是外部的客户，其实他会就在初次使用的时候就发现，诶怎么我这里的链路断了。哇，这个这个太垃圾的，不用了，我还是去查日志吧，我这里面啥都有，我我总能查到问题的，我那我总能查到问题的，就是为什么会发生，为什么会发生这样的事情呢？就是本质上是。我可以从我们整个的一个span的一个数据模型开始开始的开始说起，Span是我们推里面我们最重要的这样的一个概念，它职域的话是叫跨越嘛，就是可以简单理解为我们A服务去调用B服务，会产生两条span，一条是client端SPA，一条是sor端的SPA。

而这span里面它具体包含哪个信息呢？包含了比如说你的应用的名字，你的接口的名字，或者说你的一些本地函数的名字，或者说你去你去，比如说你调用的是一个my circle呢，会还会有一些my circle的circlel语句，或者说你调用的是还会有的一个一个command命令。等等，还可能有自你自己自定义，打自定义的一些tag。所以说总结来讲的话是一个。其实就是去标识一次。调用它的一个具体的一些信息，然后我们有多个span的话，我们就可以通过我们的那个span里面它带的一个trace ID这样一个唯一key去把整个去关联起来，然后里面有个parent这样一个字段去就能够得到一个上下游的这样一个关系。就构成了我们催son的这样一个数据结构，然后我们从我们最开始我们刚刚讲到的日志，我们去给他结优化，我们得到了指标加维度这样一个数据结构，然后我们再对我们的指标加维度这样一个数据进行一个结构化，进行一个抽象化，我们就得到了span这样一个数据模型，然后再再把它串成一条。

就其实本质上我们的一个数据是在从一个非结构化，然后逐渐的往一个结构化的一个方向去发展，然后为什么崔信会出现刚刚说到的，可能有的开发者他第一次使用的时候，他就会断掉了。其实。其实我们仔细来想，我们每次在去用日志的时候，其实我们都是在人工的去做做推荐，比如说我们收到一个指标的一个告警，我们这个时候很可能我们大家可能都会有的一些动作，就是我们拿到一个返回码，或者是拿到一个IP地址，或者说拿到一个接口名，或者说拿到一个APID或者UID这样的数据，这样的信息，然后再根据它的时间去到日志里面去查询那个它的整个的一个数据的情况，我们目的就是想去构造出整这一次。

这次用户他触发的一个请求的整个的一个上下文的一个情况，这不就是在去通过时间戳去做一个做一个做一个催生这个事情嘛，其实我们每一个使用日志去纯粹使用日志的开发者，其实都是在去我们在日志里面通过时间戳去左转肉的一个催。那么为什么会出现刚刚说到的那个垂线在某些地方它会它会断裂的这样一种情况呢？这个其实就要去了解整个垂线的一个它上报数据，或者说我们我们业界把它叫做买点的这样一种一种一种实现的一种方式，我这里举个例子，以加PCGO这样一种它它使用非常广泛的一个。RPC的框架为例，就加PC它本身提供的intercept拦截器这样一种抽象公开代理，或者叫切面这样一种能力。那大概就是在你的发送请求前跟发送请求后，能够给到你一些可以自定义的地方，能够让你去做一个事情，然后右边代码这里是一个UN clientcept，这是一个一元的一个客户端的一个拦截器。

然后这里的话就是我们可以看到，呃，我们去上报trace数据的话，其实它是先去new一个traer嘛，就是new一个对象出来，然后去建立去new一个spend对象，然后把spend把它的IDID，然后的ID填进去，然后把service name，把interface name也填进去，然后可能可能然后在你收到收到那个返回包的时候，把返回码，或者把一些返回状态，把一些异常状态的信息给填进去，然后把在开始跟结束的时候，把开始的时间戳跟结束时间戳填进去，这样这里其实就就是一个很完整的一个我们的一个催生的一个上报数据的一个。一个过程。就可以看到，其实这个过程你单独来来讲，其实还是挺复杂的，如果说你每个地方你都要去手动去做这个事情，其实会是非常非常繁琐，同时也是非常非常容易出错的一个问题，因为我们可能指标跟维度都那个数据，那个字段的数量会很少，但是我们整个我们的催生相关的一些字段的数量会非常多，因为它会尽可能的去去去囊括更多的一些有用的一些信息。

然后加BCGO这样的一个拦截器的一个模式，就能够让他能够让开源的一些社区，或者说是云厂商去去实现的这样一个intercept，这样子用户你在用加BC去实现你自己的业务逻辑的时候，其实你只需要去import这样一个clientcept跟一个servercept intercept，你就能够去把这个催性的那个数据给报上去了，但其实我这里只是讲了加PCGO这样一种框架，但其实我们整个我们。软件工程，我们的语言，我们的框架，甚至我们各种的一些开源的一些library，其实都是非常多的，像Java这种语言，它是能够在语言层面提供了一种自检码修改，动态代理这样的一种能力，可能会嗯，那个会稍微简单一些，但是你像go，像刚刚说的，刚刚说的加PCGO，或者像C加加等等这样的一系列的一些语言，它本身在语言层面是没有切面的，没有LP那样的一个能力的，所以说加PCGO这样一种框架。

他是自己在框架层面上，他做了一个intercept这样一个切面，就能够让让那个开源社区的那贡献者能够把那个推线的那个上报的数据给贡献到在intercept里面，然后我们的那个业务开发者其实就直接去import一下，添加一下那个那个intercept其实就可以了。它本质上我们的一个无侵入，我们很多时候在说无侵入的买点，其实它的真相是我们很多不管是我们的开源社区和开源的协议，还是说各大云厂商的有一些私有的协议，他们都是他们在去做这一些买点的一些事情，帮助我们的真正一线的业务的使用者去做了这样一个买点，然后我们的那个一线业务的使用者就可以去能够得到这种无侵入的这样一种接入的一个能力，但其实我们去思考它这样一个复杂度是怎样的呢？

比如说我们M种语言，比如Java go加等等，然后有N种框架，比如说spring cloud像，GRRPC像，Double像等等，像这么多一些框架，还有很多批种，嗯，比如说library，像很多GA上很多很多小儿经的这样一些library。其实本质上它的买点的复杂度是M乘以N再乘以P的这样一个复杂度。所以说其实刚刚提到的我们某些开发者，他第一次使用催钱的时候，他会发现他自己的链路上不起来，可能就是当时他用的某个开源协议，他针对他的那个框架没有适配的特别好，或者是某个云厂商的一些数据的格式没有适配的特别好，而造成他当时的一个锻炼的一一个情况。啊，所以说其实为了解决这样一个这么多买点，这么M，这个M乘以N乘以P的这样一个复杂度的一个事情，其实社区也是在不停的去进行的一个演变，从最开始的open opens的这两个分庭抗礼的这样一个社区。

然后到2019年的话，他们合并成了open tomery，然后彻底去统一，希望彻底去能够统一整个我们magic login，然后生这样的一个数据的一个协议。然后其实本质上我去理解就是一个推广普通话的一个一个过程，就是让大家去把随意统一的，然后大家去力往一处使，不要去不要又重复去造一些，就是这种协议层面的一个轮子，然后本身我们的一个M乘N乘以P的这样一个复杂度已经够高了，我们就把协议统一的，然后大家去一起去把整个我们的一个无侵入的一个买点整个的一个。一个一个一个数据采集的这样一个一个事情给他做到更好。社区的话，其实就是希望是第一是统一协议，然后第二是能够有一个统一的一个agent，一个采集端能够去。避免我们现在各种各样的一些，呃呃，每一个协议，或者说每一个系统都会有自己做一个agent这样的一种一种方式，就可以看到，其实openimry这个社区的愿景其实是一个。

对于我们的一个一线的业务使用都是一个很好的事情，为什么这样子说呢？就是像现在很多的一些监控系统，不管是一些。一些那个开一些国外的还是国内的，其实如果你是私有协议的话，其实你是会绑定，绑定住你是绑定开发者的，你你比如说如果说你切换成了open kome的话，大家协议都是一样的，大家比拼的就是我们的成本，我们的产品的用户体验，然后以及以及我们整个的一些功能等等，你如果用的不好用的，用的比如说。比如说用用用的，比如说用的某个产品用的不好，它你可以随时切走，可能用通过open的那些，你可能只需要改一下目目的的那个上报的一个地址，就能够切到另外一套系统里面去，所以这个其实就是open本身也是为了让。

整个我们的一个监控的，不管是产品还是一些开源的一些一些项目，都能够有一个更市场化的这样一个竞争，然后开发者能够去更少的一些一些私有的协议，能够捆绑出开发者。这里我们就是通过刚才的一些介绍的话，其实我们去回顾我们整个的一个可观的一个发展史的话，就是我们从架构层面，从单体应用到我们的云原生到微服务的这样一种架构，然后我们的定位的手段，从我们非结构化的一种。日志数据，然后到我们逐渐的把它给抽象成一个数据结构指标，然后加维度，然后有些黄金指标，然后通过我们的日志去人工的去串起全年，然后再到3.0的话，我们去讲到的一体化全链路的一种监控，我们通过metric，通过login。能够去跟有机的结合起来，我们就是。把ID去注入到g b me data，或者是HP，能够进行一个分布式的一个最踪，一个全链路的一个监控，我们整体来看的话，其实从我们最开始我们手动去排查日志的话，这样一种低效人工的方式能够去进化成。

一种相对高效的，我们自动化的能够去通过指标，然后跳转到链路，然后再跳转到明细日志的这样一种一种更自动化跟高效的一种一种定位问题的一种模式。下面就是介绍一些我们腾讯内部的话，在一些可观这方面的一些案例的一个分享。就刚刚也是提到了open，它是会去统一协议，其实在可观测的层面的话，其实我们是也是希望能够统一协议，一个统一的一种一种设计的理念，能够提供服务，然后再通过我们场景化的一些能力，比如说我们的前端的的黄金指标，我们后台的黄金比以前端的后台打通了一些能力，能够去给到用户一个。更更加直观的，更加高效的这样一种一种定位问题的模式，就比如说我们前端的一个视角的环境指标，像我们会很关注首屏的一个渲染时间。

以及我们页面加载的一个一个分布的一个情况，以及比如说我们的一个页面完全加载它需要多少时间，然后我们的三秒三秒开率等等这样的一系列的指标，能够去让用户在只需要一行代码，一行JS的代码，就能够去把这样一些一系列的黄金指标给他。买点三报上去，能够去很快的去把整个那个web JS的一个服务给监控起来，实现它的一个可观测。然后同时的话，我们通过这样的能力能够去注入到htp handle里面，这样的方式能够很快的去从前端的一个用户的一个异常，然后快速的去到后台的它具体的定位到它那条链路，那条日志，其实这个事情是一个特别重要的一个一个点。就是我们我们去希望是能够从用户，他用户侧他最最嗯，从用户侧的一个错误，能够直接到达那个问题，那个定位的这样一个效率，这样一个效率其实是最高的。

然后从后台可用性方面也是能够去通过呃，应用层面的一些一些那个指标，或者说再下段到接口层面的指标，然后再继续下到。它的具体的一个链路，然后再继续继续进入到它的具体这个链路所绑定的一个日志的情况来进行一个。可观测能力的一个一个一个一个效率的一个提升。然后数据库这一块呢，就是我们会把它给异化出来，就为什么是这样子的呢？是因为我们现在很多的逻辑服务其实都是一个无状态的这样，这样一个逻辑服务，我们能够很方便的通过开发SG进行一个弹性伸缩，然后其实这样子的一个发展的趋势会让我们的一个数据库变得越来越重要，大家可以去review一下，就是不管是我们的my circle啊，这样这样一种关系型的数据库，或者是以分布式的一些关系型数据库，或者是一些呃，No circle。我们在我们整个服务里面是占占据了一个越来越重要的一个地位，所以说其实它本质上它我们的存储是一个有状态的服务，所以说它的一个可用性是一个至关重要的一个一个点，很多时候我们的瓶颈都是来自于这些有状态的这样的一些存储。

所以说我们去会去提炼出数据库方面的一些黄金指标，比如说像那个的一个成功率啊，像一些。一些重要的一些返回码的一些一些一些出现率啊等等这样的一系列的一些一些黄金指标，然后能够去直接看到它的具体的一条circle，能够看到你这条circle是到底是哪一个应用，哪一个接口出的问题。这样子其实就能够去加速我们去分析那个整个的一个一个数据库的一个一个性能的一个一个分析的一个效率。然后这里的话，其实呃，天生的我们通过垂ID，通过垂这样的能力的话，我们是能够去做我们的一个架构的一个服务治理的，就比如说右边这张图的话，就是任何一个我们的这个技术负责人看到右边这张图，可能他晚上都会睡不着觉。

那我们就通过这样的一些。Top的能力，然后逐渐的通过呃垂加ma加login这样的一种有机的结合起来，能够去帮助我们把整个我们的一个微服务的一个架构，能够治愈到一个相对来说健康的一种状态。然后以及我们能够通过我们不开源的普罗修斯的协议去上报一些各种各样的自定义的指标，然后通过gra的强大的可视化的能力，能够去定义出很多的一些大盘，一些比如说一些巡检的一些监控的大盘，或者说一些比如说双11活动，或者是一些电商的活动的一些一些大盘能够去帮助。因为同学帮助开发，同学去能够去提升他们整个的一个服务的可用性，以及一个问题定位的一个效率。然后最后的话就是介绍一下整个我们的一个可观测系统的一个设计与实现的一个一个大概的一个架构，以及设计的一个理念。

这，这，这是一个我们可观测系统的一个整体的架构，从我们数据的一个接入层，到我们数据的一个流处理的一个聚合层，再到我们整个的一个告警检测，以及我们的一个存储存的告警发送。整个系统的话，其实我们是一个一个很典型的一个data flow这样一种架构，三层的话，我们从数据的输入，到我们数据的处理，再到我们数据上层的应用，这样一种data的这样子这样的一种架构能够。去呃，最大化的去，去能够去保证我们接受数据的这样一个质量，以及我们告警检测的这样一个实时性。在我们接入层的话，其实我们是为了去适配我们更多的一种开源的协议，然后我们支持了一种多协议的这样一个receiver的一种架构，就刚刚提到了open ten的话，虽然说它呃我们都会积极拥抱open，但其实本质上它暂时来看，它还没有去完全的把整个开源的可观测的学一个统一调，比如说一个例子就是在加va这样一个。

提示一下，就open ten其实是很多很多买点，很多的实现，其实没有sky working做得好。比如说像。像go，像CR，像go的JA像等等，像pro协议等等，我们都是需要去对它做进行进行一定的适配，然后在我们的中间层去做一些自定义的一些插件的能力，能够把我们的的协议给底层的统一层oment协议，然后去支持到我们。嗯，那个不同的那个客户的一些需求。然后在我们的一个流处理层的话，其实也是需要对我们多协议的数据进行一个归一化，一个统一化的一个处理，就举个例子，嗯，像这个的一个数据的话，它其实是没有p service，是没有operation这样的一些一些数据的，它本身它只会有去ID跟parent ID这样的一些数据，所以说我们在一个数据处理层，我们是需要去做一个。数据完善的一个功，一个能力，我们本身，我们基于端之间关系，我们可以构建出端端的一个调用信息，我们就可以去把像p service，像operation这样的一些数据给他去在各个span里面，各个数据span数据里面去补全，补全这样子。

整个数据统一之后的话，就是我们也能够去提供一个更强大的一个数据检索的这样一个能力。就我们整个一个告警检测的一个架构的话，是一个流式检测的一个架构，我们尽可能的去避免。我们对存储的这样一个依赖，我们去，我们从最开始的数据上报，然后到我们的那个流处理层，我们去聚合，或者是呃，甚至二次聚合的一个能力，然后。然后匹配一些智能告警，一些同行比的一些一些检测的引导，这里我们可以简单介绍一下，像开源的普罗米修斯社区，或者是格瓦范纳的一些告警检测，它其实会比如说pro，它就是在呃呃让可以让可以让开发者去配置一条pro的circle，然后去设置一个人群的一个时间，然后它的告警检测其实就是在去。

定时的去轮存储，这样的一个好处是灵活，但一个坏处就是它其实基本上不能很难去承担一个稍微大的一个量的一个告警检测的一个一个能力，像我们现在的一个数据量级，可能达到每分钟上百万，上百万甚至上千万的这样一个数据量，就能够去通过这样一个流失检测的一个模型，能够去。支撑一个呃，非常非常量，非常量级非常大，然后实时性要求非常高的这样一个告警检测，以及告警发送的这样一种能力。然后我们去观察我们的一个用户的一个使用情况的话，就可以看到我们的一个监控数据的价值其实是与时间成反比的，我们的一个统计数据是90%的请求，90的查询请求都是在去看当天的数据，很少有去看历史的数据的。历史的数据的场景，可能一般就是一些复盘啊，或者说一些一些呃，服务治理等等一些这样的一些一些一些工作，我们可以通过rap的一些方式去把历史数据进行一个力度的这样一个。

放卷能够去降低我们的一个存储，然后同时我们在在存储的话，也是一种冷热分离的一个架构，我们能够在在比如说当天的数据，我们是存储一个全量的一个这样的一个数据，然后我们在。在一些，呃，比如说一天之后的一些数据，我们只去把一些常用的，常常检索的数据，我们去保留它的索引，然后我们。一些不常检索的数据，我们就只去像一个circle一样，这样一种方式去进行一种一种查询，能够让它极大的去降低我们的整个的这样的一个呃呃存储的一个成本，同时也能够最大最大限度的满足用户的这样一种一种诉求。所以说我们总结一下，其实我们整个的一个。可的发展史，刚刚也提到的，我们从单体到我们的微服务，从我们loging到我们的指标大日制，然后再到我们的可观测的一体化，我们从一个低效，然后往高效自动化的这样一种方向去演变，然后这里的话，其实我自己去，我自己去设置了一个这样的一个构建全链路可观测的一个tool list，因为本身像我现在是带带带一个带一个团队去。

呃，带一个团队，但其实本质上我们每天也是在去会，去跟着大家一起去定位问题，然后去思考怎么样去构建我们更好的一个。一个自监控的一个能力去帮助我们，因为本身我们可观的平台也是需要一系列的一些一些那个自监控的一些能力。我自己总结的这七点图的意思，其实这其实这是这这个分享里面，我可能觉得是最重要的这样一个这样的这样的一个PPT。其实我们为什么会去关注可观测呢？其实本质上就是为了去提升可溶性吧，如果说我们的服务没有问题，可能我我自己我都不会，比如说一周或者一个月，我自己都不会去想去打开那些监控的数据，数据去看，本质上就是为了去提升我们的一个可用性，我们才会去关注我们的一个可观测。

所以所以那这样一二三四五六七点的话。比如一二点就是我们从后后台调用，然后前端调用，然后还有我们的各方面的存储的一个调用，我们都能够通过一些云产品或者开源的一些项目去能够实现无侵入的接入，能够确保每一个网络调用，不管是前端还是后台的，然后不管是你的存储层的那些。调用都能够在我们的那个告警的一个一个。一个一个监控之下，然后这样的一种无侵入的无侵入业务的一个能力，然后第三点呢，第四点就是我们的业务的一些自定义的一些指标的告警，以及日志类型的一些一些告警，然后第五第六的话就是我们的一些推荐的一些能力，通过比如说通过open或者sky working等等开源的协议，或者是一些云厂商私有的一协议去去把啊日志跟垂给关联起来，这样一种。能力，就我们构建的这样一种metric tra log的一些。

能力之后还要去通过压测工具。从用户角度。我们把，比如说我们把。比如说一个电商的一个项目，我们去把QBS提升了两倍或者三倍。我们去观测。我们去观测我们建立的这些监控大盘，我们建立的这些指标日志，这样链路，这样的数据的情况，然后这样子才我们才能够去通过我们这样12345677步的话，我们能够去。把我们整个系统的一个可观特性，也都是可用性给提升起来，然后其中其实只有标红的三跟四，其实是需要业务真实的去上报数据的那12567，其实这这七步其实都可以去通过一些云产品，不管是开源的还是一些付费的云产品，去进行一个无侵入的进无侵入的一个接入，就能够做好这七点的话，其实就能够把我们的一个项目的一个可观测性以及可用性给提升起来。然后。

我自己的话也是针对刚刚说的那个todo list去做一个可观测的一个效率的一个视频的一个模式，就是我们可以去，可以去自己去review一下，我们自己在工作中去查问题的方式，我们到底是嗯，那种完全依赖于日志，然后那种低效的方式，我们还是说我们能够，比如说第一步我们去通过指标去配置告警，然后第二步我们能够通过。我侵入接入的推去定位到具体的代码行，然后第三步才是通过日志去定位到具体的一个代码逻辑，具体的一个问题，然后我们能够通过指标链，日志这三种方式去均衡的去解决我们的一个一个我们的呃系统中的一个问题，然后来提升我们整个的一个效率，而不是把所有的呃那个。希望都投在我们打印的那种，嗯，比如说每天可能几TB，甚至上PB的日志的那个数据里面去，那子是一种非常低效的一种这样的一种模型。

本次我自己的分享就到这里了，就是谢谢大家。