eBPF效应

云云众生s

发布于 2024-06-19 13:41:11

430

发布于 2024-06-19 13:41:11

文章被收录于专栏：云云众生s云云众生s

eBPF 在可观测性中的应用——对 Groundcover、Odigos、Grafana Beyla、Pixie、Cilium 和 Apache SkyWalking 等领先的可观测性平台中 eBPF 使用情况的回顾

译自 The eBPF Effect，作者 Admin。

eBPF 如何重塑可观察性工程（第一部分）

eBPF 一夜成名，但其发展由来已久。正如去年的解锁内核纪录片所示，eBPF 解释器早在 2014 年就首次合并到了 Linux 网络堆栈中。近年来，Isovalent 一直处于将该技术带给更广泛受众的最前沿 - 特别是通过开发诸如 Cilium 和 Tetragon 等尖端的开源产品。

eBPF 是一款变革性技术，因为它允许应用程序直接连接到 Linux 内核。这意味着 eBPF 应用程序可以清晰地查看网络流量，同时具有较小的占用空间和巨大的可扩展性。可观测性平台的潜力巨大，因为应用程序可以连接到内核，而无需任何类型的用户检测。

eBPF 概述

在此综述中，我们将了解一些领先的可观测性平台如何在其工具中利用 eBPF 的强大功能。引人注目的是，许多 eBPF 的早期采用者都是可观测性市场的新手。显然，没有现有代码库需要重新设计的较新的堆栈比现有供应商（尤其是那些具有大型代码库和复杂架构的供应商）更适合采用这项新技术。

优势

因此，我们知道 eBPF 是一项强大且革命性的技术 - 但在可观测性平台中使用它有哪些实际优势？eBPF 的第一个优势之一是它是开源的。它是一个可观测性工具的构建模块，不涉及任何许可费用。因此，它大大降低了可观测性领域新进入者的进入门槛。同样值得注意的是，此综述中列出的所有产品都是 OSS。

其次，eBPF（理论上）消除了开发客户端 SDK 的需要。这可以看作是对用户和供应商的双赢。为与多种语言、平台和版本兼容而开发 SDK 需要供应商投入大量精力和资金。对于最终用户而言，集成过程变得更加顺畅，因为云原生服务不再需要检测。第三，与基于 SDK 的解决方案相比，eBPF 应用程序更快、更具可扩展性，并且资源占用更少。

然而，正如我们所知，每项技术决策都意味着某种权衡，eBPF 也概莫能外。有一些限制和注意事项需要牢记。

限制

第一个是，目前，eBPF 是一项仅适用于 Linux 的技术。它不是跨平台的 - 尽管 Windows 版本正在开发中。许多 eBPF 解决方案被描述为“云原生” - 这通常归结为在 Kubernetes 上运行 - 这显然又意味着在 Linux 主机上运行。市场上的许多基于 eBPF 的系统都假设您正在 K8S 集群中运行您的服务。如果您使用的是其他平台，那么它们可能不合适。如果您在 Windows 网络上运行，那么当前一代的 eBPF 解决方案根本无法工作。

类似地，eBPF 解决方案将无法连接到无服务器技术，例如 Azure Functions 或 AWS Lambdas，因为您无法在无服务器环境中将解决方案加载到 Linux 内核中。同样的限制也适用于 Azure Web 应用程序或 AWS Elastic Beanstalk 等技术。虽然这绝不是一个障碍，但这确实意味着使用这些技术的公司将需要一个解决方案，该解决方案支持通过 eBPF 以及通过代理或管道获取遥测。

第三，目前，eBPF 可观测性存在功能限制。eBPF 很强大，但它不是魔杖。虽然 eBPF 是一种奇妙的使能器，但需要大量的专业工程技能和知识才能编写出健壮、高性能且高度可扩展的 eBPF 程序。并非所有 eBPF 程序都是平等的。有些只涵盖一小部分语言，而另一些在捕获日志指标和跟踪方面可能只有部分或不完整的功能。

在了解了 eBPF 的一些一般原理和理论之后，现在是时候开始了解一些领先的可观测性解决方案如何利用其强大功能了。在本文的第一部分，我们将了解 Pixie - eBPF 在可观测性领域的先驱。在第二部分，我们将调查市场上其他一些领先的产品。

Pixie

如果我们不以 Pixie 开始此综述，那将是一种疏忽 - 据我们所知，这是第一个在可观测性工具中利用 eBPF 的工具。Pixie 是一个开源项目，早在 2021 年就被 New Relic 贡献给了 CNCF，事实上，该项目仍然与 New Relic 紧密集成。与大多数基于 eBPF 的工具一样，Pixie 设置 eBPF 探针以触发许多内核或用户空间事件。

当 Pixie 部署在 K8S 集群中时，它会部署 eBPF 内核探针 (kprobes)，这些探针被设置为在用于网络的 Linux 系统调用上触发。然后，当您的应用程序进行与网络相关的系统调用（例如 send() 和 recv()）时，Pixie 的 eBPF 探针会嗅探数据并将其发送到 Pixie Edge Module (PEM)。在 PEM 中，数据会根据检测到的协议进行解析并存储以供查询。这封装在下面的图表中：

图表：Pixie 中的 eBPF

从概念上讲，“挂接到内核进程”的想法听起来很简单。然而，对于可观测性系统来说，实际应用需要相当大的技术复杂性。完整的堆栈跟踪不会仅仅存在于一个整洁的小盒子中等待被收集。在 Pixie 中，通过查看 CPU 上应用程序的指令指针来恢复堆栈跟踪，然后检查堆栈以找到所有父函数（帧）的指令指针。遍历堆栈以重建堆栈跟踪有一些复杂性，但基本情况如下所示。从叶帧开始，并使用帧指针连续找到下一个父帧。每个堆栈帧都包含一个返回地址指令指针，该指针被记录下来以构建整个堆栈跟踪。

遍历调用堆栈

动态结构化日志记录

捕获度量和 CPU 分析功能可能是大多数 eBPF 实施中的可观测性解决方案的标准功能。让 Pixie 真正脱颖而出的功能之一是其动态日志记录功能，这是调试应用程序的一个改变游戏规则的功能。通常情况下，如果你发现应用程序中的功能不能如预期地运行，并且需要向其中添加日志记录，那么你需要编辑、重新编译和重新部署你的代码。动态日志记录是 Pixie 中的一个 Alpha 功能，它允许用户在函数运行时向其中添加日志记录。本文展示了如何使用简单的脚本为二进制文件添加新功能。该函数能够捕获参数并将输出写入表中，如下所示。