基于 eBPF 的 Kubernetes 可观测实践-六虎

作者：刘洋（炎寻）

可观测是为了处理问题，所以在聊可观测之前，应先对问题排查的普适原则进行了解。

布景介绍

问题排查的原则

以排查系统问题为例，要了解系统，要先注重基础知识，了解编程言语底子的计算机科学知识，注重系统大图比如架构布置和严重流程，要注重工作细节，要对中心功用的算法和数据结构了然于心，还要注重系统的运维东西，可以了解发布、回滚和监控。

在了解的基础上，还要可以复现问题，首要注重问题发生的触发条件以及问题发生时数据现场的保存，包含方针、链路、日志、工作等。

有了现场再加之关于系统的，才可以定位问题。通过现场保存的数据，进行相关分析；依据了解，可以快速用二分定位到根因。在定位的进程中，尤其要注重改动，由于有很多的系统问题是由改动导致的。

确定根因后再进行修改，既要治标也要治本，并且要充沛验证，保证不引入新的问题。

以上为问题排查的普适原则，它不只适用于系统问题的排查，也可以运用到日子的方方面面。

而可观测使得问题排查的进程更加高效、安稳、低本钱。它可以帮忙我们了解系统，出现问题的时分可以留下足够多的现场，可以使数据之间很便利地进行相关，帮忙我们做二分的相关分析，终究还可以验证修改是否正确。

Kubernetes 可观测应战

复杂度是恒定的，它不会消失，只会搬运。我们构建的编程言语、编程结构、容器操作系统都只是将复杂度关在适合的当地。假如悉数工作正常，皆大欢喜；而一旦出现问题，就是灾祸。复杂度不断下沉的趋势使得可观测面临了很大的压力。Kubernetes的流行使得微服务架构非常遍及，多言语、多通信协议成为常态，这也在另一方面带来了应战。

应战 1：端到端观测复杂度上升，埋点本钱居高不下。但是这只是冰山一角，有很多才干下沉到 Kubernetes 管控层、容器工作层、网络和操作系统层面，这些基础设施才干的下沉带来了很大应战。

应战 2：由于注重点的分离，使得运用问题与底层问题无法自顶向下构成相关。

应战 3：虽然有许多东西，但是上下文缺失、数据散落，导致无法通过这些数据很好地了解运用，由于现场的缺失无法相关，而使问题排查功率低下。

可观测需求有共同的技术来处理自身的复杂度。

依据 eBPF 的可观测实践分享

eBPF 介绍

从一初步，内核就是可观测的绝佳方位，但是由于功率和安全问题一向无法完结。通过多年展开，eBPF 技术为可观测打开了新的大门。

eBPF 是一项可以安全地在内核中工作沙盒程序的技术，无需修改代码即可在内核用户态程序工作发生时工作。它具有以下特性：

无侵入特性：观测本钱极低，运用无需修改任何代码，也无需重启进程。

动态可编程性：无需重启探针，动态下发 eBPF 脚本即可修改探针侧的逻辑。

高功用：自带 JIT 编译，使探针可以取得内核本地工作的功率。

安全：verifier 机制约束了 eBPF 脚本可以拜访的内核函数，保证内核工作的安稳。

除了这些令人振奋的特性外，eBPF 的运用流程也非常便利。以监控、运用、功用为例，只需求加载编译 eBPF 程序监听网络的内核工作，解析网络协议，然后聚合成方针，输出 Trace 即可。

eBPF 得到了许多大公司的支撑，展开非常迅猛。以前一年，阿里云可观测团队依据 eBPF 技术构建了共同可观测途径。其架构如下图：

依据 eBPF 的共同可观测途径架构

最底层是数据收集层，首要采用 Tracepoints、Kprobre、eBPF 函数抓取相关系统调用，相关进程容器信息，构成原始工作，并通过 eBPF 和 sysdig 的结合支撑多内核版别。一同为了处理工作爆炸的问题，引入了工作过滤和高功用工作传输机制。

往上是数据处理层。用户态获取到原始工作后，首要进行协议的解析，生成方针、链路、日志等数据，进程中也会对信息做收敛。然后填充元信息，比如 K8s 信息填充或自定义运用信息填充，终究监控数据会通过 OpenTelemetry Collector 输出。引入 OpenTelemetry Collector 首要为了支撑多种数据类型以及多数据传输通道，支撑将监控数据写入用户指定的存储。

再往上是数据存储层，默许情况下，方针会运用 influxDB 存储在 Prometheus，链路和日志运用 SLS 存储在 Trace。

最上是数据服务层，通过 ARMS 的前端以及 Grafana 终究出现给用户多种多样的可观测服务。

怎样进行无侵入式多言语的协议解析

ARMS 可观测团队注重 eBPF 在运用层的运用，通过监听网络内核调用，构建连接跟踪，将传输的网络包进行协议分析，得到运用层面的央求照应，终究得以无侵入式地支撑多言语场景下央求数、照应时间、差错数、黄金方针的监控。

现在我们支撑 HTTP、 Redis 、DNS、Kafka、MySQL、gRPC 、http2 等协议，支撑的协议列表也在不断扩大中。

线上问题与处理办法

通过一年多的生产实践，遇到最多的问题首要有以下四个：

榜首，内核版别适配问题。eBPF 在内核版别 4.14 以上才有较为成熟的支撑。但是线上依然存在许多老的内核版别，这部分需求运用 sysdig 进行支撑。高版别在 core 不成熟的情况下，运用动态下载内核图文件以及动态编译的办法进行支撑。

第二，内核工作爆炸。传统的监听 Tracepoints、Kprobre 会发生巨大的工作，给探针的功用构成巨大压力。为了处理这个问题，我们引入了工作过滤机制，只处理网络调用工作，一同优化工作传输序列化，达到高功用工作传输的意图。

第三，在工作的消费侧，协议解析功率低下。为此我们优化了高功用解析算法，比如可以削减分析的字节数，优化更多的匹配算法提高解析的功率。一同还运用了多线程内存复用等工程方法提高协议解析功率。

第四，方针时间线爆炸。全部工作终究都会聚合为方针、链路和日志，其中方针方面由于单个维度发散，会对存储的安稳性构成极大的影响。因而，我们支撑在写方针的时分进行维度收敛，比如每个维度的基数不得超过 100，超往后将收敛成星号，代表通用的收敛标记。此外，还在查询侧进行了优化，首要做了精度的降级。

共同可观测交互界面

共同告警

eBPF 技术的无侵入性以及多言语支撑的特性使得开箱即用成为了或许。依据此，阿里云可观测团队初步构建共同可观测界面。

首要是共同告警。接入阿里云 eBPF 监控，我们设计了一套默许的告警模板，涵盖了运用层、 K8s 管控层、基础设施层和云服务层，供应了开箱即用的帮忙用户发现问题的才干。

共同的相关分析逻辑

有了 eBPF 保存现场数据，加上告警系统奉告存在问题，后续应怎样共同进行相关分析，找到根因？

我们认为需求有一个界面来承载相关分析逻辑。它应当方针清晰，比如要处理容量规划问题、本钱消耗问题仍是运用功用问题；它应当内容丰富，包含处理问题需求的全部内容，比如方针、链路、日志、工作、问题的影响面、相相联络等；它应当具有非常清晰的运用途径，可以回答当时是否有问题，未来是否有问题、问题的影响是什么、问题的根因是什么、用户能做什么等，以此一步步引导用户处理问题。