Strobelight:Meta用于大规模基础设施的eBPF分析器框架

Meta开源大规模基础设施分析器Strobelight!集成eBPF技术,CPU周期减少20%,服务器需求降10-20%。Strobelight协调CPU、GPU、内存等42个分析器,低开销监控系统事件,追踪函数调用、堆栈、AI/GPU分析及内存泄漏,助力云原生应用性能优化!

译自:Strobelight: Meta's eBPF Profiler Framework for Massive Infra

作者:Steven J Vaughan-Nichols

想象一下,你负责监控 Meta 的大规模基础设施。这想想就很可怕,不是吗?现在,Meta 的工程团队取得了一项突破性进展,他们成功地利用 eBPF 技术来增强其全公司范围内的分析器 Strobelight

当我说“增强”时,我指的不是只有专业的性能工程师才会喜欢的细微改进。不,我指的是“CPU 周期减少 20%,相当于 Meta 顶级服务所需的服务器数量减少 10-20%”。这在计算方面节省了很多,相当于在资金方面节省了很多。

Strobelight 是 Meta 的全公司范围内的分析器框架,旨在为公司的大规模基础设施提供全面的分析能力。它由多个子分析器组成,这些子分析器收集各种类型的性能数据,包括 CPU、GPU 和内存配置文件。该框架的首要任务是识别性能瓶颈并优化 Meta 机器集群中的资源利用率。

Strobelight 最近成功的关键在于集成 eBPF。它支持在 Linux 内核中直接进行高效、低开销的监控和系统事件跟踪。通过利用 eBPF,Strobelight 现在可以以对系统资源的最小影响来收集性能数据。

确切地说,根据 eBPF 基金会 的说法,eBPG 使 Meta 能够跟踪在函数调用和执行路径中花费的 CPU 时间;本机和非本机语言(例如,Python、Java 和 Erlang)的调用堆栈;关闭 CPU 时间和服务请求延迟分析;以及 AI/GPU 分析和内存跟踪。

eBPF 节省成本

除了节省计算时间和现金外,eBPF 基金会 声称,在 Strobelight 中使用 eBPF 还通过一个字符的代码更改,每年节省了相当于 15,000 台服务器的容量。这让我印象深刻。它还可以更快地进行调试和性能分析。这使工程师能够在回归到达生产环境之前阻止它们。

借助 eBPF,Strobelight 现在可以跟踪 GPU 内存分配并更有效地检测内存泄漏。Meta 软件工程师 Riham Selim 表示,eBPG 可以在任何时间点了解每个 GPU 的内存分配情况。

请注意,eBPF 并不完美。Selim 指出。它缺乏对 GPU 内部结构的可见性;大量的数据可能会让人不知所措;并且它缺乏特定于应用程序的理解。因此,例如,您需要将可观测性代码添加到 PyTorch 程序中,而不是仅仅依赖 eBPF。

因此,重要的是要理解 Strobelight 远不止 eBPF。根据 Meta 的说法,“Strobelight……不是一个单一的分析器,而是许多不同分析器(甚至是临时分析器)的协调器,它在 Meta 的所有生产主机上运行,收集有关 CPU 使用率、内存分配和正在运行的进程的其他性能指标的详细信息。”

事实上,Strobe Light 总共有 42 个不同的分析器。其中大多数(但并非全部)都基于 eBPF。

安全注入自定义代码

因此,eBPF 对于 Strobelight 至关重要。Meta 工程师指出,“eBPF 允许将自定义代码安全地注入到内核中,这使得以非常低的开销收集不同类型的数据成为可能,并在可观测性领域释放了如此多的可能性,以至于很难想象没有它 Strobe Light 将如何工作。”

不要问我你怎么做。我对可观测性略知一二,如果没有 eBPF。我什至不知道从哪里开始。幸运的是,由于我们有 eBPF,因此我们不必担心这一点。

想亲自尝试一下吗?你可以的。StrobeLight 的大部分内容最近已在 Apache 2 许可下开源。然而,Meta 尚未开源 Strobelight 的分析器和库。该公司承诺将会这样做,因为通过开放它们,它们将变得“更加强大和有用”。即便如此,这里已经有足够的开放内容,对于任何想要密切关注大型基础设施系统的人来说,Strobelight 仍然值得探索。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注