基于eBPF的Trace_profiling程序摄像头技术如何定位故障根因

用户对可观测性需求可以用 1-5-10 来界定，1分钟发现-5 分钟响应-10 分钟恢复。然而现实是要想实现1-5-10，是非常难的。

即便已经采用了当前可观测性主流技术Tracing、Logging、Metrics技术之后，面对故障根因定位，实际上仍然需要非常丰富的经验才能够再定位故障根因，而定位时间因个人的能力而异，这就导致解决时间不可预期。

开源项目Kindling在全球首创的提出基于eBPF技术融合Tracing、Logging、Metrics的Trace_profiling程序摄像头技术，期望可以帮助用户在分钟级以标准化步骤定位全资源的故障根因。

接下来，将重点讲我们是怎么去做的，以及相关的一些预热case。

一、当前可观测性技术采用之后仍然面临的问题

先回顾下在可观测性领域里当前常见的一些技术tracing，也即常见的一些接触的产品，比如开源的SkyWalking、pinpoint、opentelemetry等。

Metric 在云原生领域用的比较多的就是Prometheus，在传统环境中用的比较多的是Zabbix，Logging则以ELK技术为主。很多公司可能这三个技术都已经用到了，仍然面临的现状是最终要落地1-5-10是非常困难的。

在国外来看Splunk在 2022 年做的一个可观测性的调查报告，其中就提到了相关的机构对可观测性的成熟度面临的以下挑战。我重点将上述两个挑战标红了。

第一个挑战即很多不同来源的数据如Metric、Tracing、Logging，如何能够将其关联起来并使得用户理解，这是一个很大的挑战。

第二个挑战，很多的指标、数据都已经超出了普通人能够理解、记忆的范围，即便看到了异常仍然不能深刻理解这些指标异常所代表的背后含义。

Splunk调研报告后面两个问题其相对来说比较容易。在云原生环境或者在分布式环境里，只需要将相关的 tracing 或是类似于普罗米修斯的现代化工具能够用起来，问题就不大了。

在重复一次我们认为当前可观测性落地1-5-10的难题主要是：

1、指标太多，不知何时看何种指标。

现在也有一些技术，比如aiops做单指标的异常检测的时候，会检测出很多的指标毛刺，这时一旦有异常发生，到底看哪个指标，便成为了很大的问题。

2、异常指标太多，每种指标都要去排查，周期太长。

每一种指标都排查，或是找那种偏差度比较大的指标都排查，指标排查的周期很长，最终导致的结果是落地1-5-10很难。

3、解决问题时间周期不可预期。

10 分钟之内要恢复问题几乎不可能，所以解决问题的时间就不可预期。这是我们认为当前可观测性里存在的一个比较大的问题。

二、1-5-10是生产环境稳定所追求的技术目标

上述讲了很多次1-5-10，这里再简单带着大家回顾一下。可能还有一些朋友不知道，1-5-10对应故障的是“1 分钟发现-5 分钟响应-10 分钟恢复”。

1分钟发现问题：落地难点在于告警与监控指标体系如何完善。

1. 告警淹没
2. 告警风暴
3. 网络传输指标异常
4. 服务器主机指标异常
5. 应用指标异常
6. 业务指标异常

5分钟响应：落地难点在于快速标准化，定界问题，完善的全链路追踪与指标体系能够做到初因高效定位。

1. 快速定界与定位问题难

10分钟恢复：落地难点在于故障的根因快速定位难。

三、故障根因定位是当前可观测性悬而未决的难题

常见的的故障恢复方式：先重启。但是实际上重启只能解决比如内存泄漏的这种问题，而实际上下图中为我们在国外看到的一个调查报告对其翻译出来的故障占比，可以发现很多的问题并非通过简单重启就能够解决。

故障根因复杂多样，需要建立非常完善的告警体系，以及相关的监控指标。其中碰到的技术难点就是告警的风暴，包括各个地方都可能告警，网络出问题、服务指标、应用指标、业务指标。

我们常规的解决思路：在解决这个问题的时候解决不了，一般公司就会请他们公司的大牛出面。大牛解决问题也是根据自己以过往的经验，遇到过类似的问题，再遵循过往的思路去寻求解决方案。

如果没有碰到过解决方案就比较麻烦了，可能需要查各种各样的数据，做不同的尝试，这些都是很麻烦的问题。基于以上种种问题，Kindling想做的就是成为解决问题的一个神器。

先简短介绍一下 kindling 是什么，以及我们想做什么。

Kindling 是作为一个云原生的可观测性的工具。Trace-profiling 的作用是将一次用户的请求，基于应用程序与 kernel 的行为进行很好的联动，还原程序从处理请求到写回响应的一次完整的程序执行过程，完整地还原程序的执行行为。

四、Trace_profiling程序摄像头的解题思路

有了这个行为之后，我们认为就可以解决这个根因了。故障根因定位怎么做？就需要做到帮助用户在高效理解合适的指标，从而理解程序发生问题的根因。

核心思路是先要实现两个目标：高效；找到合适的指标，从而理解发生问题的根因。

1、高效：用户能够在初因定位之后，先理清楚应该看哪一类指标，而不是盲目在指标海中对比各个异常指标。

利用eBPF技术将程序代码执行过程转化成资源消耗过程：

1. CPU
2. 网络
3. 内存
4. 存储

帮助用户理解一次trace调用中到底何种资源成为瓶颈，之后再聚焦分析指标；

2、找到合适的指标：利用eBPF成为联合剂将Trace与log，metric的关联，将指标按照资源分类，每种指标从宏观层面到微观层面指标。比如网络先看带宽，发包率等指标，进而再看rtt、丢包、重传相关指标。

五、Trace_profiling程序摄像头的核心价值

我们认为用 Kindling 里能做到一个很重要的事情，即黄色标明部分将程序的代码执行过程转换成资源的消耗过程，还原成一个 trace 的span。在这个节点执行过程当中，发现它分别在 CPU、存储、网络上消耗了多少时间等等。

而且，可以通过不同的时长呈现给用户，看执行的时候到底是哪一类资源消耗的最长，对应地就去看哪一类合适的指标。我们不仅仅只是做了第一步，还采了很多其他的一些指标，包括比如网络上采了rtt 、丢包、重传、零窗口等等，这些指标就会将eBPF作为粘合剂将 Trace与 Log、Metric都关联在一起。

我们每一种指标即可从宏观到微观，让它一步一步的下转去发现问题。这就是 Kindling 针对落地 1-5-10 的解决思路。

接下来介绍下相关的一些 user case。介绍之前，先把核心价值再重复一遍。

第一步先找到trace，其后分析 trace 里span 的相关信息，如果是一些 trace 信息很容易通过span定位出是下游的问题，比如下游的 SQL 语句慢。

但是当定位不出来之时，即可分类。分类是可以分cpu、网络、存储等等一些相关的指标，帮助自己很好的理解这一次用户请求到底做了些什么。

六、UseCase1：生产环境CPU不定时飙高

先看看遇到 的case 1 也即案例 1， 当出现了生产环境进程的 CPU 不定时飙高，但并非一直飙高不下，偶尔比如出现个 10 秒后结束了，又出现 10 秒又结束了。但是它不定时地来，如此一来就很难找到规律。

我们常规解决 CPU 飙高问题的方法：

1.登录上CPU不定时飙高的机器；

2.排查占用CPU的进程；

3.找出实际占用最高CPU的线程；

4.用jstack获取对应线程的堆栈信息，找出耗CPU的代码位置对应修复。

不足之处：

1.现场并未保留，难以重现，CPU在某些地方一直卡住比较适用常规解法；

2.耗时， 由于不定时飙高，需要找CPU飙高的规律，但是规律难寻；

3.人有误操作可能；

4.Jstack性能消耗大，没有办法一直常开；

5.不同业务URL都会占用一定的CPU使用量，很难定位到底是哪个业务导致的CPU使量比较高，从而会被误导排查很多正常使用的CPU代码。

下文将演示一下我们做出的效果。此前先回顾一个预备的知识，当程序做序列化的时候，是比较消耗 CPU 的。

以下给大家看的实例，是一次 trace 当中的请求，主要就是做序列化。我们对比了不同的序列化的实现方式下它消耗的时间。可以看到第一步找trace，其后开始重复span，这是我们从 SkyWalking 拿出来的span。这一问题拿出示范之后，会发现代码执行时间比较长，其实对程序员或者架构师帮助并不大，不知道接下来怎么办。

如果再深入地结合trace-profiling，会看到响应时间 280 多毫秒。在处理请求开始我们程序呈现的时间，开始以及结束代表了线程在处理请求的时候完整的执行过程。红色部分代表的就是它在 CPU 上跑，可以看到这 285 毫秒几乎都在 CPU 上跑的。

从CPU上可以看到它分了很多间隔，有很多条线。linux内核对该线程执行过程进行了上下文切换，它会switch 一下发生一次内核的context。

放到 switch 之后，再做 CPU 的一些内容，每个 CPU 宏的空格上面点进去呈现的下面的代码就是线程级别的还原图，通过代码可以知道哪些代码在CPU执行。

因为我们用的是fastjson 的库的类都可以看得到这是哪些方法在执行。如果是 Jackson 也是一样的效果，如果是Gson也是一样的。还有一个 net.sf.json，请大家不要用，其效率最低。

七、UseCase2：k8s环境使用servicename 进行远程调用

另外一个case，在 K8S 云原生环境里实现service name 的远程调用时，若碰到了一个比较尴尬的问题，当我们把 a 与b， a 调b，从 a 的客户端发现 a 调 b 的时间很长，但是在 b 的 server 端通过 trace 串联时发现 b 的执行时间不慢。这时就比较尴尬。

这个时间大家想当然了，就会认为这一问题诱因即网络，所以就去做相对应的排查。有时候经常排查出来之后，发现既没丢包又没重传，网络质量也很好。此时就比较尴尬，不知道怎么回事了。

实际上仍然是一样的道理。通过我们的系统也能够完整地还原出trace。

常规解题方法：

1.用tracing系统串联客户端与服务端数据；

2.直接排查网络质量。

不足之处：

1.当用tracing系统串联客户端与服务端数据之后，发现Client延时数据过大，而server端延时过小之时，问题比较难以解释；

2.想当然的怀疑网络问题，经过一番排查发现网络质量好像没有问题，接下来束手无策。

标准化排障步骤：

1.找关键Trace，通过Trace系统，结合时间点，找出可能存在问题的关键Trace；

2.查Span信息；

3.对比分析Span信息，找出与预期不符的地方。

未来我们可以看到后面的网络时间比较长，整个的这一大段，从这里开始虚线到后面结束的时间都在做网络。

目前我们还没有做到关联这些丢包等相关的指标，但是未来会将这些指标都关联进来，这样即可在一个位置地方知道网络这么长，到底是由于传输的大小，还是其他丢包、重传这些情况。

这是一个DNS请求，在云原生环境里面DNS请求 是相对来说比较普遍的一个现象，如果DNS请求比较长，可以直接看到DNS请求比较长的时间段。

还有一个原生存储，举一个简单点的例子，如果你的程序有写磁盘或者读磁盘，但是磁盘出现了坏道或者慢，或是远程通过云原生的存储搭建了GlusterFS等等。在绝大多数情况下，大家是不会先怀疑存储有问题的。

八、UseCase3：云原生存储出现问题

针对存储问题，现在比较难于监控，没有什么好的手段。唯一的办法就是通过对程序的日志打代码。程序代码打日志去记录这些时间要求对运维人员来操作就不现实，对于开发人员也要求相对比较高，而且对代码要比较熟悉，这就很难了。

总结下来，有以下几点不足之处：

1.蛛丝马迹的发现需要对代码，对环境非常熟悉；

2.同样的日志，不同的人看能得到不同的理解；

3.常规指标与监控很难发现问题。

此外即便产生了日志，若非恰巧日志打到那个位置，也很难马上归因到这是由于存储出了问题。同样地，通过上述说法也是找到trace，找到span，发现时间执行很长。

进去可以看到执行时间里有很多的黄色、蓝色、紫色，紫色的区域，就会发现从开始到结束的时间里， 1. 47 秒可以看到文件的存储。文件存储的IO的时间占用了一大半时间，这就是文件的IO。在我们这里也可以精准地还原出来，就知道存储可能是有问题的。

九、UseCase4：云原生环境网络TCP窗口配置有问题——导致1M左右报文返回延时大

最后一个case，其实场景可能大家碰到的比较少，但是很可能碰到过，只是没有意识到碰到了问题。一次RPC的调用，当返回的包的大小是 1 M-3 M的时候，传输时间比较大，可能会接近 1 秒钟，但实际上我们的带宽、机房，不管是在阿里云的云服务器上还是自建机房，现在很少是百兆的交换网络了，基本上都是千兆、万兆级别的。如果你传输一个 1 M的数据都要花个几秒钟，这其实是有问题的，并且问题会在出现在大家实际的开发或是生产环境里。

我们的常规解题方法，有以下两点：

1.查看网络带宽；

2.不断调整日志点位，通过日志确认网络发生或者接收时间。

不足之处：

1.不同框架适配周期长；

2.对网络理解不深的人很难意识到网络传输会有问题，日志都不会往这个方向打。

可以看到的一次典型的问题就是 a 调b。从 a 、b 的视角均慢了，但是 b 为什么慢？如果通过代码角度看是完全看不出来的。我们上述演示的效果也是。

这里回忆到 TCP 的原理，就上述情况就不去讲 TCP 窗口的工作原理了，但是我想说的是，因为 TCP 窗口配置不到导致的延时比较慢的现象，对于很多人来说可能比较陌生。

而你的真实环境一旦出现此问题之后，希望可以通过我们的工具来为大家提供一个提示，让大家知道“诶，这个地方有问题，我应该往这个方向去排查”。

还是同样的道理：可以看到一次请求先查看trace，执行时间很慢，span 给不出更多的线索。可以看到整个请求里，从开始到结束的较长时间里，总用时 500 多毫秒，CPU可能跑了大概 1/ 10，即 50 多毫秒。其实程序处理请求的时间可以认为是很快的。

接下来可以看到都是程序产生的一些锁。为什么会有这么多锁？代码的动态演示，如果大家有兴趣，可以到Kindling的官网上看一些case。

这里可以得到一个tomcat 在往回写数据的时候会加锁，它交给 NIO线程写回去，说明问题就出现在数据响应外传上。

最后我们也做了一个实验，当调TCP窗口的时候，实际上不同的TCP窗口会导致响应延时有所差异。可以看到当接收方的包大小不一致的时候，从80 多Kb到 4 Mb的时候，延时基本上降了一倍。若上述所言可得到这些信息，就会给你一个很明确的指导意见让你去调窗口。

至此我基本上就分享完了，有想交流讨论的问题欢迎加入到Kindling 开源社区，也是Apache的license。

｜嘉宾介绍｜

苌程

Kindling 创始人

2010年开始承担浙江大学SEL实验室带队老师职责，专注于云原生分布式领域研究。2016年作为联合创始人创立谐云科技并兼任CTO, 信通院云原生成熟度特聘专家顾问。2020年在公司内部孵化了eBPF云原生可观测性项目，并与头部标杆金融机构展开合作。在2022年创立Kindling——eBPF可观测性开源项目。