基于 eBPF 的 Kubernetes 可观测实践

作者：阿里巴巴云原生

2022 年 8 月 04 日
本文字数：4190 字
阅读完需：约 14 分钟

作者：刘洋（炎寻）

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

背景介绍

问题排查的原则

1.png

以排查系统问题为例，要理解系统，要先关注基础知识，理解编程语言基本的计算机科学知识，关注系统大图比如架构部署和重大流程，要关注运行细节，要对核心功能的算法和数据结构了然于心，还要关注系统的运维工具，能够了解发布、回滚和监控。

在理解的基础上，还要能够复现问题，主要关注问题发生的触发条件以及问题发生时数据现场的保留，包含指标、链路、日志、事件等。

有了现场再加之对于系统的，才可以定位问题。通过现场保留的数据，进行关联分析；基于理解，可以快速用二分定位到根因。在定位的过程中，尤其要关注变更，因为有大量的系统问题是由变更导致的。

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

以上为问题排查的普适原则，它不仅适用于系统问题的排查，也可以应用到生活的方方面面。

而可观测使得问题排查的过程更加高效、稳定、低成本。它能够帮助我们理解系统，出现问题的时候能够留下足够多的现场，能够使数据之间很方便地进行关联，帮助我们做二分的关联分析，最终还可以验证修复是否正确。

Kubernetes 可观测挑战

2.jpeg

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

挑战 1：端到端观测复杂度上升，埋点成本居高不下。然而这只是冰山一角，有大量能力下沉到 Kubernetes 管控层、容器运行层、网络和操作系统层面，这些基础设施能力的下沉带来了很大挑战。

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

挑战 3：虽然有很多工具，但是上下文缺失、数据散落，导致无法通过这些数据很好地理解应用，因为现场的缺失无法关联，而使问题排查效率低下。

可观测需要有统一的技术来解决自身的复杂度。

基于 eBPF 的可观测实践分享

eBPF 介绍

3.png

从一开始，内核就是可观测的绝佳位置，然而由于效率和安全问题一直无法实现。经过多年发展，eBPF 技术为可观测打开了新的大门。

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

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

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

高性能：自带 JIT 编译，使探针能够获得内核本地运行的效率。

安全：verifier 机制限制了 eBPF 脚本能够访问的内核函数，保证内核运行的稳定。

除了这些令人振奋的特性外，eBPF 的使用流程也非常方便。以监控、应用、性能为例，只需要加载编译 eBPF 程序监听网络的内核事件，解析网络协议，然后聚合成指标，输出 Trace 即可。

eBPF 得到了很多大公司的支持，发展十分迅猛。过去一年，阿里云可观测团队基于 eBPF 技术构建了统一可观测平台。其架构如下图：

4.png

基于 eBPF 的统一可观测平台架构

最底层是数据采集层，主要采用 Tracepoints、Kprobre、eBPF 函数抓取相关系统调用，关联进程容器信息，形成原始事件，并通过 eBPF 和 sysdig 的结合支持多内核版本。同时为了解决事件爆炸的问题，引入了事件过滤和高性能事件传输机制。

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

再往上是数据存储层，默认情况下，指标会使用 influxDB 存储在 Prometheus，链路和日志使用 SLS 存储在 Trace。

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

如何进行无侵入式多语言的协议解析

5.png

ARMS 可观测团队关注 eBPF 在应用层的应用，通过监听网络内核调用，构建连接跟踪，将传输的网络包进行协议分析，得到应用层面的请求响应，最终得以无侵入式地支持多语言场景下请求数、响应时间、错误数、黄金指标的监控。

目前我们支持 HTTP、 Redis 、DNS、Kafka、MySQL、gRPC 、http2 等协议，支持的协议列表也在不断扩充中。

线上问题与解决方法

6.png

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

第一，内核版本适配问题。eBPF 在内核版本 4.14 以上才有较为成熟的支持。但是线上依然存在很多老的内核版本，这部分需要使用 sysdig 进行支持。高版本在 core 不成熟的情况下，使用动态下载内核图文件以及动态编译的方式进行支持。

第二，内核事件爆炸。传统的监听 Tracepoints、Kprobre 会产生巨大的事件，给探针的性能造成巨大压力。为了解决这个问题，我们引入了事件过滤机制，只处理网络调用事件，同时优化事件传输序列化，达到高性能事件传输的目的。

第三，在事件的消费侧，协议解析效率低下。为此我们优化了高性能解析算法，比如可以减少分析的字节数，优化更多的匹配算法提升解析的效率。同时还使用了多线程内存复用等工程手段提升协议解析效率。

第四，指标时间线爆炸。所有事件最终都会聚合为指标、链路和日志，其中指标方面由于个别维度发散，会对存储的稳定性造成极大的影响。因此，我们支持在写指标的时候进行维度收敛，比如每个维度的基数不得超过 100，超过后将收敛成星号，代表通用的收敛标记。此外，还在查询侧进行了优化，主要做了精度的降级。

统一可观测交互界面

统一告警

7.jpeg

eBPF 技术的无侵入性以及多语言支持的特性使得开箱即用成为了可能。基于此，阿里云可观测团队开始构建统一可观测界面。

首先是统一告警。接入阿里云 eBPF 监控，我们设计了一套默认的告警模板，涵盖了应用层、 K8s 管控层、基础设施层和云服务层，提供了开箱即用的帮助用户发现问题的能力。

统一的关联分析逻辑

8.png

有了 eBPF 保存现场数据，加上告警系统告知存在问题，后续应如何统一进行关联分析，找到根因？

我们认为需要有一个界面来承载关联分析逻辑。它应当目标明确，比如要解决容量规划问题、成本消耗问题还是应用性能问题；它应当内容丰富，包含解决问题需要的所有内容，比如指标、链路、日志、事件、问题的影响面、关联关系等；它应当具备非常清晰的使用路径，能够回答当前是否有问题，未来是否有问题、问题的影响是什么、问题的根因是什么、用户能做什么等，以此一步步引导用户解决问题。