他把设备重启了仍然解决不了问题然后换各种东西一个一个的试然后最后试出来这个东西不匹配然后换一个就好了这个我们今天讲的这个主题其实蛮应景的我们讲的是TraceProfiling主要是来追踪程序的这种行为怎么样去看到程序执行的每一个步骤首先先介绍一下我叫常诚从2010年就在浙江大学SEL实验室做助理研究员在干了十年主要专注在云原生以及分布式计算里面然后2016年兼职创立了杭州协运科技专注在容去银然后2022年我们开员了Kindling基于EVPF的项目2023年我们创立了一个新的公司叫云关秋豪现在专注在故障的更衣定位上面大家如果有兴趣可以加我的微信那我这里就快一点对然后就是我们先介绍一下可观的性当前的一个现状相当于Tracing, Magical, Logging我相信大家都已经接触的比较多了这里我就不在追数到底分别是什么了但是现在一个趋势就是Open Telemetry它会将Tracing, Magical, Logging这三种技术融合得越来越紧密其实就会看到我们的Tracing当中可以看到Magical, Magical可以看到Tracing互相跳跳跳去会更来越来越融合这是未来的一个发展趋势但是即便这样我们找到故障的更衣仍然很难为什么很难呢我们分析一下就是第一个如果我们知道我们代码在干什么然后发生了什么事情其实我们知道这个故障更衣相对来说是比较容易的比如说我们从日治里面发现我们程序在干什么推论出来程序在干什么其实相对来说比较容易可观测性的工具都出现就是帮助我们理解程序在过程当中干了什么但是有很多时候仍然存在于盲目区也就是在可观性右边这幅图里面出现了就是unknown的问题就是有时候我们都不知道我们不知道这个盲目区的存在就导致我们在很多时候只能猜测程序如果出了问题它是由于什么导致的然后只能猜测然后边猜测边去找证据来证明我们的猜测那传统呢怎么解决这个问题呢传统解决这个问题就是我解决不了我就去找专家找我们公司的牛儿这个是非常以来专家经验然后我们遇到问题专家遇到问题呢基本上也是说未遇到的问题然后他深入调研通过各种方式去猜测去验证然后验证完之后呢把这个经验固化出来变成专家经验这里有一个踩坑填坑的过程但是这里面有一些问题就是就是左下角显示的就是如果专家不在这个指标大家能不能理解比如说我问大家一下就是大家理不理解大家对CPU Throttle这个指标有多少人理解的请举下手 麻烦这两个人对 是两个人说明这个CPU Throttle其实看上去这个指标其实在伯伦修斯的指标里面体系里面已经都是大家都踩了但是其实真正理解这个指标含义的人是很少的是非常少的像我们在座的只有两个人能理解这两位是专家对还有一些就是专家我请问一下两位专家你们对CPU Throttle那你们对内核的内存了解吗对内核的网络了解吧对内核的调度都了解吧估计也比较难就是可能是某些指标就很难做到全方位的完整的理解所以这是很难的只能是某一个方面那对于这个问题对于我们online的问题怎么解决呢Gatlin它其实有一个思路在Gatlin的这个APM就是叫可观正性这个魔力相限里面它提到了说基本上就是中间那一天中间那一个黑色的字体就是交互式的这种这种去探索各种各样的指标然后包括Tracing Metric Logging让大家可以交互的探索可以从Tracing跳到metric从metric跳到logging各种方式跳来跳去这种方式我们认为它仍然属于一种启发式的排站就是我人如果处理过这个问题有经验那我看到这个问题那我可能会有一些想法那甚至我原来的思路去排场但是这个就越来越运气跟着它经验了如果这个问题你原来恰巧遇到过那它就刚刚很好像刚才我们遇到了这个现象刚才为什么闪瓶那个国外小科过来他跟我说他也是第一次遇到他没见过所以他把这个东西强制重启了不解决问题他也不知道接下来咋办了所以后来另外一个大胡子大爷他估计有经验一点所以他就把这个设备换了一下然后就发现解决问题了所以这个就是有时候就很有运气他重启不解决问题他怎么办就只能一个一个的试最后这个刚才我们亲身经历了一下就是他试出来的一个结论就是把这个换掉没问题了那只能说明这个我原来这个设备跟这个东西不一样只能说明这个一点那我们要解决这个问题怎么办在程序里面就是其实我们先要分析一下这些马红区来自于什么地方那我们首先第一个如果一次请求他漫于平常他就是比较异常了那从一条trace的记录里面来看APM的trace的记录里面来看我们是可以定位出哪一个span比较慢的这个tracing这个是什么我就不在这里追数了其实比如说我们定位到这个span比较慢好 那我们继续往下面看这个trace为什么慢呢那我们从过APM的一些数据他会给我们一系列的方法来告诉我们说有很多方法慢那我们如果又找到了这个方法比较慢那其实问题就变成从span为什么慢转换成了为什么这个方法比较慢这个过程其实就从一个问题转换成另外一个问题那其实这个问题仍然没有解决这个黑河仍然是存在的那其实根本的这个原因就是由于代码它的执行过程带来了盲区那我们可以看一下就是我们基本上一般写程序写的是用户程代码就是用户代码那我们跑在呢跑在公共库上面比如说我们一些就是这些比如说加法的话用到阿帕奇的这种内库比较多然后可能还用JVM虚拟机如果够的话就是够的虚拟机然后再往下面跑跑到GLIB-C的这个内库里面然后再往下面跑然后跑在这个syscore上面对于绝大多数人员而言绝大多数程序而言我们熟悉的是用户代码那我们可能还熟悉呢如果大家看过一些原码的话可能对公共库的代码还是比较了解的但是对于虚拟机可能就只是仅限于了解了那对于下面的这种行为呢可能就完全不了解了这种模式在传统云虚拟机的环境下面其实是没有问题的因为大家GLIB-C Syscore它的行为跟预期是一致的因为大家在虚拟机里面基本上很多时候大家在云虚拟机里面跑我只要关心我的用户代码就可以了因为底层的代码它的这个行为是跑基本上是在独享一个虚拟机里面的很多跑的环境比如说跑个4核8G或者2核4G的这个程序里面就是虚拟机里面一个VM就跑了是一个程序所以在这种情况下底层的冲突共享资源并不严重但是我们如果在云虚拟机里面我们的资源是共享是非常多的我们所有的CPU 内存 网络 存储全都是共享的而且很多时候大家跑的是一个大机器这是比如说128核256G的这种机器去跑云虚拟机的环境这底层的程序就有可能由于别的程序的冲突带来的共享的问题会导致这个我给大家举一个诡异的例子这里一个诡异的例子就是DocA它在写程序的时候它有很多的写操作它会把PageCache写满写满了之后DocB这个导媒蛋它在写程序它在分配一个内存就是MLOCK分配内存但是由于PageCache被DocA写满了所以内核它就要清理PageCache导致整个机器上整个Node上面所有的进程都会慢这个知识点我不知道大家了解吧如果了解的话请举下手这个多一点 四五个人这个知识点了解的话这个其实很多人是不知道的在不知道的情况下你就不会想到说我分配一个内存会导致我内核在清理换存这个情况几乎就是刚才我们在做的人其实是比较少的如果大家来排的话可能就只有四五个人可能会往这个方向想对 这个例子想表明的意思就是其实在我们整个的内核里面有非常多的程序是共享了很多的资源的在远远生环境里面所以就很多的知识点其实大家如果要一一的积累这是不现实的然后这个盲区的本质来自于分层代码的不熟悉但是我们现在设计软件的时候不可能不分层去设计但是在跟我们的排帐这就导致了矛盾我们排帐只有掌握了细节我们理解了它程序的工作原理我们才能知道这个东西为什么出问题 为什么异常然后为什么自己慢这个细节才能对得上但是这个排帐就导致了矛盾那一种方法就是把每个人所有的知识点所有内核的东西都去学习都去理解这个其实是不现实的因为没有人有这么多的超小的记忆力这不现实那有没有一些工具能够把一些我们现在在看到的这些黑盒子的情况包括分层代码隐藏的这些执行情况能够打开呢我们可以看到现在有一些技术叫做continuous profilingcontinuous profiling我这里简单的介绍一下这个是在谷歌2010年发的论文然后2019年他们做出了第一款的continuous profiling的产品然后后续的这个是CNCF一个官方blog上面有一个这样的图后来后续现在很多的大公司像亚马逊、Dead Dog他们都在做continuous profiling还有很多的开源项目那他们怎么实现原理呢主要的实现原理就是通过探测CPU上比如说我一个程序它执行了CPU上这个程序执行了这个方法然后比如说隔壹定周期去探测探测完了之后把这个方法给列出来从而相对于拍照我在然后分析这个拍照的快照的这个数据从而得到这个代码的执行对战所以在CPU的火焰图里面我们可以看到看到这个程序它的哪些方法执行的时间比较久可以看到这个方法比如说刚才我们举的那个例子一个你新创一个内存导致内核在清理这个缓存那其实从内存的角度从这个火焰图的角度是可以看到我们有一块内核的代码执行的时间是比较久的这个是火焰图能够看到的一些场景但是它也有一些限制比如说我们常见的一个生产环境的业务它不可能只有一个接口被调用它经常的情况是它会有ABCD这种各种各样的接口它都会被调让我们举一个例子这个接口它每个调的次数是不一致的然后但是我们现在就发现某一个接口它比平常慢我们怎么样去定位它的问题从火焰图里面能定位出它的问题呢从火焰图里面你要从统计细细里面分析出单次的信息是非常难的因为这个火焰图它进入的是一分钟里面这个程序执行了所有的数据所有的数据都在这里所以你要分析出单次的请求它为什么办它的火焰图是什么样子这个几乎不现实这是它的第一个限制然后第二个限制呢就是我们知道程序的执行就刚才说了ONCPU它的火焰图的执行原理是去探测我们的这个程序它在CPU上它执行了是哪个方法然后得到了这个执行对战但是如果我们这个程序由于锁由于网络由于存储等各种原因它被限制住了那这个时候其实在火焰图里面在CPU的ONCPU的火焰图里面是看不到任何相关的信息的所以后来又有一个另外一个概念的出现叫做OFFCPUOFFCPU它也会生成一个火焰图告诉你这个程序由于在OFF的情况下它等待了多少的时间对这个是OFFCPU但是现在很多的continuous profiling的工具它其实是没有OFFCPU的然后即便有了OFFCPU它这两个因为我们要分析一次请求比如说URB它的执行过程是什么样子的那如果我们只看从统计信息里面去看就是前面讲的ON跟OFF这两个信息怎么串联在一起呢其实是没有办法的你只要靠人去非常极限的猜测把两者关联在一起这个是非常难的然后还有一些工具还有一些工具就比如说大家可能接触过的阿萨斯然后包括现在有一些国外的创业公司他们在做的像下面写的Light WrongLight Wrong他们是可以允许我们在在生产环境里面去针对某些函数去判断某些函数执行了多少时间看出这些函数执行的包括参数等等这些东西都是非常有用的它是一些神器很多人现在都会用这些工具但是这些工具在云渊生的平台里面它是不够的因为它只能覆盖就是用户程的代码以及公共内库的代码对于底层的这些GVMGLIP-C、SISCO就刚才我们举成那个场景如果我分配内存出现了内核的CPU在清理缓存的情况对于Arthos以及Light Wrong这种工具它都很难去发现问题去从而给到线索我们认为我们的核心的速度Trips Profiling是可以打开这个盲区的我们怎么打开这个盲区我先带着大家回忆一下线程包括代码怎么在操作设讨上执行的一个原理就是我们用户程写的代码用户程写的代码不管你是Gava、SISCO whatever只要你写的代码这是用户程在操作设讨程里面看就是用户程的代码用户程的代码它会在CPU上跑会执行一些函数当它执行到一些函数的时候比如说执行到一些系统调用还有一些想运营一些中端的时候它会陷到Clone里面来Clone里面来Clone里面来了然后这个就是就是进行了一个模式切换再摸Clone模的就比如说刚才我们举的那个例子当我申请内存的时候它就从用户程写入到了CloneClone Type然后Clone Type比如说我现在在申请磁盘申请网络申请存储申请或者是等所等等由于各种东西我就会现出到这种等待的状态里面这个现成状态是现出等待的状态里面来的等到这些条件满足的时候我们这个现成的状态又变成Roundable是可以被CPU再次调度当我们CPU资源充分的时候又可以被调度到这个Clone状态去继续运行或者运行完这个比如说这个SysCore被继续完的时候它会回溯到用户台在用户台继续执行这是整个的一个过程那如果我们能够能够根据这个现成把刚才说的这些所有的点位刚才说的所有的这些点位我们用EBPF在内核的这个技术上面我们去Tracking我们然后根据现成根据这些关系把它串联起来我们就然后同时我们跟Tracing关联起来那我们就可以把一次请求一次请求它执行的过程完整地还原出来了这就有点像我们自己内部把它称为程序上头就有点相当于我们看到的程序在CPU上执行的一无一失的执行过程它可能比如说先拿了在程序上执行了一些什么自己的一些用户台的代码然后可能执行了一个系统调用比如说一铺或者是分配类传比如说刚才我们讲的那个例子分配类传它就会执行一个分配类传的这个SysCore然后接下来出现了一系列的刚才那个例子就是内核的代码它的清理内核的这个缓存导致这个回应图就可以看到代码在执行那些东西然后给大家介绍一下我们的Kindling的开源项目我们的核心功能TraceProfining其实就是想左边那个其实就是想要做到把一次请求一次用户请求它的完整的一个执行过程我们一无一失地还原出来从而知道知道这个程序发生了什么问题从而把这个盲区给打开那我们人就知道因为我们知道了这个程序在干什么了那我们当然也就能回答这个程序为什么故障了大概我们是这样的一个思路那我们可以TraceProfining可以干什么呢可以我们现在在官方网站上我们记录了这些信息就是所有的线程所有的线程它的执行状态我们都被记录下来可以被看到你可以看到所有的线程它之间相互的关系等等那每一个比如说跟Tracing关联起来之后我们可以知道一个Tracing的span它在干什么它执行的从时间开始到结束它是哪个线程那个线程在干什么我们可以一无一失地还原回来然后包括包括刚才我们举例讲的那个例子比如说它的火焰图它的用户态的火焰图以及任何态的火焰图我们可以把它关联在一起可以从而发现到底是火焰图这是哪段代码是CPU的代码如果执行的反码的话到底是哪段代码执行的时间比较久对然后如果大家不熟悉代码的话其实对内核代码不熟悉像刚才这些内核代码不熟悉其实是可以很简单地去网上搜一把就可以知道我们内核在干什么了不用去把每个知识点都掌握这是我们的一个经验然后还有一个比如说网络网络的相关的指标我们也可以被关联进来以及文件纯主相关的指标也可以被关联进来这就是我们所谓的Trace Profiling我们可以看一下第一个例子就是User Case 1就是CPU的资源 收线的例子我们知道在源源渗渗的环境里面大家都会给Port分配Limit跟Request但是大家现在我们问过很多的用户大家分配的Request和Limit是否合理很多时候就是我拍脑袋我分配一个纸 我拍脑袋比如说0.5个盒 一个盒等等我拍脑袋但是这个是不是合理的是不是多了 是不是少了我不知道还有一个就是CPU利用率CPU利用率其实很多时候大家会认为说只要总体利用率不超过40%不超过50%认为这个程序就肯定不会由于CPU的原因而产生缓慢的影响但是实际上我们容器的CPU统计率它的周期是按照秒分钟这种级别去统计的但是在某一个时刻比如说就某一个毫秒或者是某一个100毫秒一段或者是200毫秒的时间段仍然可能发生我们CPU slaughter也就是说可以看到这样的程序我们一个程序它在执行的时候可能会出现我们有一段时间这个就是由于CPU资源不充足会出现说我们wrong queue latency等待CPU的资源调度然后在CPU上跑这个颜色代表是写了wrong queue latency代表就是由于CPU资源不充分而被从CPU执行上面拉下来然后下面后面一个是CPU又可以执行了然后CPU不充分又执行CPU不充分又执行这个每一个周期每一个周期缺省的大概是100毫秒如果我有10个周期就是一秒钟一秒钟可以看到如果出现了这种情况说明什么说明这个程序的CPU资源其实是或者是你这个limit的分配是不合理的或者是说某一个时刻在一个高峰时刻它的资源是不合理的但是其他的时候如果CPU的资源利用率总体的资源利用率只有40%或者50%说明什么说明其他的绝大多数在高峰期以后平缓了它的CPU6率又是充足的所以现在有一些工具可以做CPU burst可以去临时的去往后面的周期去借一些资源CPU资源去调度这个事情但是你要去做这些行为你得先知道我有这个现象的发生所以这就是我们可以通过我们的Trace Profiling可以看到一次请求它的CPU资源不足的这个情况然后还有一种执行情况就是我的CPU的代码资源如果执行的这个利用率很高我们是可以包括设置某些情况下我们CPU资源是标高的标高的那突然后来又降下来了这个时候怎么办对应物有没有影响包括对哪些Trace是有影响的这个其实我们也可以看到它的这个火焰图你可以通过对比通过不同的版本对比看看这个火焰图里面执行的这些数据是什么样子的然后另外一个场景就是存储的场景存储的场景大家我不知道大家在生产环境里面如果看到一个进程它的IO很高我们科技可以科技各种命令看到它的IO很高但是它的那些哪个文件IO为什么高它IO有多高其实我们只能看到一些统计的从Linux命令里面只能打到一些统计的数据通过我们Trace Profiling我们是可以看到比如说一次请求从开始到结束它中间这些紫色的部分紫色的部分都是在做文件的IO包括我们可以知道它在读什么文件在写什么文件写了多少数据这个我们都可以知道我们就可以知道这个IO对我们的请求有没有影响这些毛刺是否是由存储导致的然后还有就是DNS问题然后这里可以统一统一看成是网络问题比如说在Trace里面有个经典的问题就是Client看到数据很慢Server看到数据很快那为什么那为什么其实如果我们可以看到Client这边执行了一个Trace Profiling的数据的话比如说我这边看到一个例子就是它这个执行再执行一个非常长的我们自己指出的一个故障一个DNS的故障DNS的故障可以看到这个系统调用叫Epo它执行一个Epo的SysCode它去执行这个DNS然后大家可以看到这个Epo的数据是从一个接口访问8888.53888就是DNS的这个服务器53就是DNS的Port我们看到它从访问到回来这个系统调用时间很久那我们就知道这个问题其实发生在底层的这个DNS的这个调用上面跟我们的程序肯定就没有关系那其实这个就可以用来做资证包括我们很多时候会出现说我们比如说看了一些网络指标假设我们看到SRTTRTT包括重传这些指标可能会偶尔地波动那这些波动对我的请求有没有影响呢那其实其实可能是没有影响的那我们这个工具就可以注实它让它知道这个程序到底有没有受到这个请求有没有受到这个DNS的波动的影响包括受到网络的波动的影响等等然后包括GC的问题GC其实大家如果生产环境发现GC的话基本上都是靠经验去猜测说这里有GC然后后续看一些GC的时间点那我们是可以把这个GC的时间发生的情况给注实掉怎么注实呢就是比如说我们一个GVM里面VM之外的其实代表的就是这个GVM的这个主线程然后XNIO这是Undertone的一个模型那它的这是一个业务线程那我们可以看到这两个图里面可以看到这个CPU其实这里面在红色的表示在CPU上跑然后可以看到它的火焰图火焰图里面大概可以看到它其实在进行GC的操作然后看到业务线程其实接下来你可以看到两个on跟off是两个相互切割的这个情况对比出来就可以看到说这个情况就做实了是这个XNIO线程上面的业务在这个执行过程当中它已经被GC影响得比较严重这个是可以看到这样的一个情况然后还有就是锁的情况在代码里面在我们的很多业务代码里面可能大家平常自己是不会加锁的但是我们用的很多的内裤比如说数据库连接池比如说线程连接池等等各种磁化的工具然后还有很多的这些代码它都会有一些隐藏的这些锁的形式的存在我们可以看到然后从我们的这种催思波反领是可以看到两个线程它的交叉的去等待锁的然后时间有限最后还有一页PBT就是这个我们称之为北极新的排帐理论什么意思呢这是我们跟阿里龙西社区联合发布的对这个数据可以干什么我们只要把催思波反领的数据进行一个分析提存我们可以得到这样的一个数据从催思波反领一次开始到一次结束的时间我们可以看到它完整的比如说一次请求从开始到结束我们可以看到它的CPU时间网络时间存储时间然后以及等待时间那如果对于专家前面我们讲的专家而言专家的工具而言它其实是一开始的时候是不知道我应该往哪个方向去排查因为线索给的有限通过我们这个工具我可以知道比如说CPU的时间长我要排查的问题就是往CPU的方向我们可以下面去看比如说RoundQ再去看RoundQ的时间再去看CPU的回应图然后RoundQ又可以继续往下面排查可以一个标准化的形式可以把每一个部分我们都可以标准化地去找到它故障的原因从了一步一步地下来这个就是标准化的排站我们认为这个北极星的排站指标其实就想给大家设定一个北极星让我们排站的时候是有思路的可以一步一步地往下去走好我基本上讲完了不知道大家有没有问题比如说这个系统本身它的请求量比较高的话就是说如果加了这些监控的话它会不会对系统本身的性能带来一些影响我重复一下你的问题刚才主要办法要求我们重复问题我重复问题就是说因为我们这个感觉埋了很多的内核的点位这个点位在高并发压侧的情况下或者是高法外量的情况下对程序会不会有影响对吧 是这个问题是的对 这个问题是这样因为其实我们所以说我们要在内核态对 第一个你埋点肯定会有程序的影响你埋一个kpro现在他们好像有一个benchmarking测出来大概是几十纳秒的一个影响几十纳秒的一个影响那你埋得多那肯定会有影响但是其实这个只要你把数据你在内核态是可以处理掉的这个影响其实我们自己加测下来几乎就感知不到可能一毫秒都没有一维秒都没有对 这个是感知不到的在我们自己测试的情况下不知道大家还有没有别的问题往后面给合吧你好 我问一下我比较关心SpanID怎么和你现成的数据做关联这个就是通过Span就是因为我们可以知道从JVM里面从JVM里面这个是有一个串联的过程从JVM里面我们知道这个是哪个现成对不对这个是要跟JVM Java Agent或者是Go的那边的东西Sdk叫结合键的我没有回答你的问题没有那我问一下现在像Go这种和Rust的这种绿色现成就是Grid Thread能进攻到吗其实理论上也是可以的因为你程序执行的时候在操作系统上面看它不管你是什么现成不管你是鞋层你是什么样子只要在操作系统上的现成跑都是这个逻辑吧这个是没变化的只是在用户态Go的比如说鞋层里面它可能会有自己的一个管理器它在调度在真正执行的时候它还是在操作系统的现成逻辑在做的这个理论都是可以的OK 明白谢谢后面那个还是接着第一个同学问的那个问题其实我们在那个产线上面有用那个parallel scope而做那个continuous profiling就是像您讲的那个CPU开销确实很小EPPF做这个事情确实很高效但是它会产生大量的数据存储然后您这个又做trace又做profiling它产生的数据量会不会更加可怕非常可怕这个就把问题重复一遍就是我们产生的数据量是不是非常大非常可怕从这个数据量的情况下确实很大比如说一秒钟一个trace profilingprofiling下来的数据大概可能都是10兆到100兆左右就看你的这个现成的比如说我一个jvm里面有200个现成如果200个现成都在跑那确实数据量很大但是呢但是其实这个是后续有办法是可以去优化它比如说你不需要profilingprofiling你出来数据之后你在类传里面其实是可以丢掉的因为这些数据只要没有故障的时候其实你是可以不用保留的但是我们现在还没有在开源里面还没有做到这一步这数据量确实很大但是你要看清楚问题这个是一个矛盾你要看清楚问题你就必须有更多的数据但是呢只要不影响我们的逻辑是只要不影响性能看到数据之后呢实际上是可以在边缘端产生一些算法去丢掉一些数据从而来保证总体的成本是可控的是这样一个逻辑好的 谢谢你好 我这边有两个问题第一个就是关于北极星排帐指标这一块是在Kending里面已经有了还是说只是一个理论的一个设计阿里的CISO-M也有了Kending里也有了对 有这个数据第二个问题就是延续刚刚那位老师的就是针对后面的一些存储的话是有推荐的还是说已经适配了哪一些存储呢比如说像我们现在开源的项目里面适配的是Elastic Search就是直接往ES里面存包括指标链路都放在ES里面对OK 好 谢谢对 是的你好 有几个问题就是那个第一个 您刚才说您做的Conditional Profile的时候对性能没影响但其实性能影响很小我看您那个代码里边用了好多K-ProB这个肯定有性能影响这个您之前有具体数据吗比如说是几毫秒还是怎么样我们可能对这个延迟比较明的对 我们测下来呢就是有一些Batchmarking这不是我们测的其他的一些EPF项目测的一次K-ProB的这个买点的延时大概是一百纳秒以下大概是一百纳秒以下就是您那个项目具体的延迟我们自己的测下来的延时大概是一毫秒以内一毫秒以内对一次K-ProB 是吧不 不 不是整个的我们拦截了这么多缺少一点这么缺少一点我看您代码里边那个K-ProB点还挺多的是 是 是然后第二个我看您那个项目上存储是ES 是吧对这个数据是可以一直长存吗我们现在的核心还在探证端ES只是现在因为你总要有个工具来吧数据存下来吧所以我们现在先选择的是ES我们这个部分还没有优化它ES存储效率比较低后边这种数据会持久存储吗ES是一种持久存储方式只是说它的存储效率不高就是你们后边没有考虑4倍比如说Client House之类的这种东西是吧暂时还没有做我们暂时先把探证先往上掉你们这个后边有计划做那种分析能力吗你说的分析能力是排账比如说我可能会在下线一直跑Continual Profiling然后我会在上线前对比几次之前Continual Profiling 火焰图有没有变化这个是好的提议我们以后可能会走因为这里一直存这个玩意儿对没有这个计划是吧不是 这是个好提议我们可以做进去挺好的就是有加一些采样吗对其实未来的一种方式就是采样可以减少存储也是一种方式目前还没有 但我会来对好 没问题好 谢谢大家