作者:Sean Heelan
在这篇文章中,我将介绍 sysgrok,这是一个研究原型,我们正在研究大型语言模型 (LLM)(例如 OpenAI 的 GPT 模型)如何应用于性能优化、根本原因分析和系统工程领域的问题。 你可以在 GitHub 上找到它。
sysgrok 可以执行以下操作:
Sysgrok 的功能针对三大类解决方案:
Sysgrok 仍处于早期阶段,但我们发布它是因为它已经可用于各种任务 - 我们希望它将成为其他人执行类似实验的便捷基础。 如果你有任何想法,请随时向我们发送 PR 或在 GitHub 上提交问题!
LLM,例如 OpenAI 的 GPT 模型,在过去几个月中迅速流行,为各种产品提供自然语言界面和核心引擎,从客户助理聊天机器人到数据操作助手,再到编码助理。 这种趋势的一个有趣的方面是,基本上所有这些应用程序都使用现成的通用模型,这些模型没有针对当前的任务进行专门训练或微调。 相反,它们接受了整个互联网大范围的培训,因此适用于各种各样的任务。
那么,我们能否利用这些模型来帮助进行性能分析、调试和优化呢? 有多种方法可用于调查性能问题、对根本原因进行分类并提出优化方案。 但从本质上讲,任何性能分析工作都将涉及查看各种工具(例如 Linux 命令行工具或可观察平台)的输出,并解释该输出以形成有关系统状态的假设。 GPT 模型训练的材料包括软件工程、调试、基础设施分析、操作系统内部结构、Kubernetes、Linux 命令及其用法以及性能分析方法。 因此,这些模型可用于总结、解释和假设性能工程师日常遇到的数据和问题,这可以加快工程师进行分析的速度。
我们可以更进一步,超越纯粹将 LLM 用于工程师自己的调查过程中的数据分析和问题回答。 正如我们稍后将在本文中展示的那样,LLM 本身可用于在某些情况下驱动该流程,由 LLM 决定运行哪些命令或查看哪些数据源来调试问题。
有关 sysgrok 支持的全套功能,请查看 GitHub 存储库。 总的来说,它支持三种解决问题的方法:
在这种模式下,LLM 会收到工程师使用的另一个工具的输出,例如 Linux 命令行工具、分析器或可观察平台。 sysgrok 的目标是解释、总结并提出补救措施。
例如,topn 子命令采用分析器报告的最昂贵的函数,解释输出,然后建议优化系统的方法。
该视频还展示了 sysgrok 提供的聊天功能。 当提供 –chat 参数时,sysgrok 将在 LLM 的每次响应后进入聊天会话。
此功能还可以普遍应用于 Linux 命令行工具的输出。 例如,在《60 秒 Linux 性能分析》一文中,Brendan Gregg 概述了 SRE 在首次连接到遇到性能或稳定性问题的主机时应运行的 10 个命令。 analyzecmd 子命令将要连接的主机和要执行的命令作为输入,然后为用户分析和总结命令的输出。 我们可以使用它来自动化 Gregg 描述的过程,并向用户提供 10 个命令生成的所有数据的一段摘要,从而省去他们必须逐一查看命令输出的麻烦。
在性能工程和 SRE 工作中,有些任务会反复出现。 对于这些,我们可以构建有针对性的自动化助手,工程师或 sysgrok 本身可以直接使用它们来解决其他问题。
例如,findfaster 子命令将库或程序的名称作为输入,并使用 LLM 查找更快、等效的替代品。 这是性能工程中非常常见的任务。
Sysgrok 中这种方法的另一个示例是 explainfunction 子命令。 该子命令采用库的名称和该库中的函数。 它解释了该库的用途及其常见用例,然后解释了该函数。 最后,如果该库和函数消耗大量 CPU 资源,它会建议可能的优化。
LLM 的用途不仅限于集中回答问题、总结和类似任务。 它也不限于一次性使用,即提出一个单一的、孤立的问题。 sysgrok debughost 子命令演示了如何将 LLM 用作代理中的 “大脑”,以实现自动解决问题的目标。 在此模式下,LLM 嵌入到一个进程中,该进程使用 LLM 来决定如何调试特定问题,并使其能够连接到主机、执行命令和访问其他数据源。
debughost 命令可能是 sysgrok 目前最具实验性的部分。 它展示了在性能分析自动化代理的道路上迈出的一步,但要实现这一目标还需要大量的研发工作。
在这篇文章中,我介绍了 sysgrok,这是一种新的开源人工智能助手,用于分析、理解和优化系统。 我们还讨论了 sysgrok 实现的三大类方法:
你可以在 GitHub 上找到 sysgrok 项目。 请随意创建 PR 和问题,或者如果你想讨论一般 LLM 的项目或应用,你可以通过 [email protected] 直接与我联系。