基于 eBPF 的 Kubernetes 可观测实践-技术圈

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

背景介绍

Cloud Native

问题排查的原则

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

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

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

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

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

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

Kubernetes 可观测挑战

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

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

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

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

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

基于 eBPF 的可观测实践分享

Cloud Native

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，超过后将收敛成星号，代表通用的收敛标记。此外，还在查询侧进行了优化，主要做了精度的降级。

统一可观测交互界面

Cloud Native

统一告警

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

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

统一的关联分析逻辑

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

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

统一 Grafana 大盘

基于以上设想，我们推出了统一的 Grafana 大盘。它符合关联分析逻辑，无论是全局还是特定实体都有总览，能够发现问题细节，能够排查问题；它包含日志、事件、指标等多数据源，以告警异常阈值为驱动，整个大盘可以交互、点击跳转，可以定位根因，涵盖了 K8s 集群最核心的资源类型。

统一拓扑图

我们也推出了统一的拓扑大图，它具备拓扑感知、依赖分析、流量监控、上下文关联等特性，可以按维度筛选节点和边，构建业务语义化的视图。

Demo 演示：基于 eBPF 的统一交互页面

在容器服务 ACK 进入一个集群后，点击运维管理，进入集群拓扑功能页面。如果没有安装 eBPF 探针则会提示安装，安装完成后开箱即用，可以获得整个集群的流量拓扑。

页面包含了 deployment、deamonset、和 statfulset 之间的流量关系。点击节点可以看到它对外提供的应用性能，也可以查看节点的上下游。通过上下游的查看，可以快速检查它是否按照预定的架构运行。

此外，也可以点击边进行查看，比如可以看到 MySQL 的 QPS 以及响应时间等。

除了查看指标，还可以查看详情，比如查看 SQL 语句以及网络耗时，比如请求发到对端用了多久、对端处理用了多久、响应的内容下载耗时多久等，可以快速定位问题所在。同时还提供了节点过滤的能力，可以快速过滤出用户感兴趣的节点，同时也可以搜索对应的节点。

Grafana 统一的大盘为 1+N 的模式。1是指集群的全局大盘提供了整个集群最核心的资源总览，包含事件，可以快速查看各类事件的个数及详情，可以查看节点是否健康、无状态应用 deployment 是否健康以及有状态应用、deamonset 等。

每一个特定资源总览的结构也是一致的，包含“总”和“分”。“总”是对整个集群进行概括的总结，可以快速通过阈值确认是否有问题，有问题的阈值会用鲜艳的颜色标出。比如上图可以看出有 1 个节点的 CPU 请求率过高，而具体哪一个节点的请求率过高，则由“分”负责查找，通过请求率排序，快速找到问题节点。

上图显示集群级别有两个 Pod 不是 ready 状态。通过对 phase 进行排序快速获取两个处于 pending 状态的 Pod。也可以看到有 15 个 Pod 在过去 24 小时存在重启行为，进行排序后即可快速找到这些 Pod。

可以点击具体节点，查看其 CPU 请求率的 top 10 ，点击查看详情后可在系统资源里进行查看，以判断请求量是否合理，并进行修正。

由此可见，Grafana 大盘具备很强的交互能力和逻辑。

前端应用的每一个 deployment 或资源详情页也具备排查逻辑。概览中展示了管控层、CPU、网络、内存等情况，一眼便能知晓系统是否存在问题，可以快速查看问题所在。

与此同时，大盘还集成了日志以及 7 层的应用性。

以上能力全部是基于 eBPF 的无侵入性提供的开箱即用的能力。

总结与展望

Cloud Native

总结

阿里云可观测团队构建了 kubernetes 统一监控，无侵入式地提供多语言、应用性能黄金指标，支持多种协议，结合 Kubernetes 管控层与网络系统层监控，提供全栈一体式的可观测体验。通过流量拓扑、链路、资源的关系，可进行关联分析，进一步提升在 Kubernetes 环境下排查问题的效率。

展望

未来，阿里云可观测团队将进一步挖掘 eBPF 全覆盖、无侵入、可编程的特性，在以下三个方面持续发力：

第一，可扩展 APM，简称 eAPM。围绕 APM 不断扩展边界，解决其侵入每种语言都需要单独埋点的问题，解决在应用层面看不到的底层黑盒问题，包括以下几个方面：

1. 无侵入式的多语言性能监控。

2. 无侵入式的分布式链路追踪。

3. 应用请求粒度的系统与网络分析。

第二，提供工具，针对包括 tracing、profiling、动态网络包跟踪以及内核事件在用户态进行处理的开发框架进行优化。

第三，实现 eBPF 增强的内置指标、链路和日志，主要包括对应用协议更多的支持以及高阶的系统指标和网络指标。