PromCopilot: Simplifying Prometheus Metric Querying in Cloud Native Online Service Systems via Large Language Models

本文提出了基于大语言模型的 PromCopilot 框架，通过结合知识图谱与协同推理机制，将工程师的自然语言问题自动转化为 Prometheus 查询语言（PromQL），从而简化了云原生在线服务系统中的指标查询过程，并构建了首个 Text-to-PromQL 基准数据集以验证其有效性。

要点

这篇论文介绍了一个名为 PromCopilot 的新工具，它的核心使命是：让工程师不用写复杂的代码，直接用“人话”就能从庞大的监控系统中查到自己想要的信息。

为了让你更容易理解，我们可以把这篇论文的内容想象成在一个超级巨大的、自动化的物流仓库里发生的故事。

1. 背景：那个让人头秃的“超级仓库”

想象一下，现代互联网服务（比如淘宝、微信、抖音）就像一个超级巨大的自动化物流仓库。

• 货物：就是各种数据（比如 CPU 用了多少、内存剩多少、有多少人在访问）。
• 监控员：就是工程师们，他们负责盯着仓库，确保一切运转正常。
• Prometheus（普罗米修斯）：这是目前最流行的“仓库管理系统”，它记录了仓库里每一秒发生的所有事情。

现在的痛点是什么？
在这个仓库里，数据多到爆炸。工程师如果想查“订单服务所在的节点里，哪个服务器的内存最空闲？”，他们不能直接问系统，必须用一种叫 PromQL 的“外星语言”（一种非常专业的查询代码）来写指令。

这就好比你进图书馆，想借一本书，不能直接跟图书管理员说“我想找那本红色的书”，而必须背诵复杂的索书号规则、书架编号、甚至还要懂图书馆的底层数据库结构。如果写错了，查出来的就是垃圾信息，或者根本查不到。这对工程师来说，既难学又费时间。

2. 解决方案：PromCopilot —— 你的“超级翻译官”

为了解决这个问题，作者们发明了 PromCopilot。你可以把它想象成一位既懂仓库结构、又懂人类语言的“超级翻译官”。

它的工作流程非常巧妙，分三步走：

第一步：画一张“超级地图”（构建知识图谱）

在仓库里，东西之间关系错综复杂（比如：订单服务 -> 运行在 Pod 上 -> Pod 在某个节点上 -> 节点有内存数据）。
PromCopilot 首先会把这些复杂的关系画成一张巨大的“关系地图”（知识图谱）。

• 这就好比它把仓库的布局、货物位置、运输路线全部画在了一张纸上，并且标记得清清楚楚。
• 这张地图是动态更新的，仓库里多了一台机器，地图马上就会更新。

第二步：听懂“人话”并指路（问题解析与检索）

当工程师问：“帮我看看订单服务所在的节点，哪个内存最空闲？”
PromCopilot 不会直接瞎猜，它会：

1. 听懂意图：识别出关键词“订单服务”、“节点”、“内存”。

2. 查地图：利用刚才那张“超级地图”，像侦探一样进行多跳推理。

   • 第一跳：找到“订单服务”在哪里？ -> 找到了几个 Pod。
   • 第二跳：这些 Pod 在哪些节点上？ -> 找到了具体的节点 ID。
   • 第三跳：这些节点上有没有“内存”这个指标？ -> 找到了对应的数据标签。

   这就像你问：“我想找那个卖咖啡的店。”翻译官会先查地图找到“咖啡店”，再查它所在的“街道”，最后告诉你“它在第三大道”。

第三步：生成“外星指令”（生成 PromQL）

最后，PromCopilot 把查到的所有信息（具体的节点 ID、指标名称、标签），结合大语言模型（LLM）的编程能力，自动翻译成那个复杂的 PromQL 代码。
工程师只需要看结果，甚至可以直接运行，完全不需要自己去写那些令人头秃的代码。

3. 为什么它比以前的方法好？

以前也有类似的技术（比如让 AI 学习以前的问答记录），但在这个场景下行不通，原因就像：

• 以前的方法（Few-shot Learning）：像是让一个实习生背“去年的考题”。如果今年仓库布局变了（比如服务扩容了，节点换了），去年的答案就失效了。
• PromCopilot：像是给实习生发了一张实时更新的地图。不管仓库怎么变，只要查地图，就能找到最新的路。它不依赖死记硬背，而是依赖实时推理。

4. 效果怎么样？

作者们做了一个实验，就像在仓库里搞了一场“找东西比赛”：

• 比赛内容：给工程师 280 个自然语言问题，看谁能最快、最准地写出正确的查询代码。
• 结果：
  • 普通的 AI（直接问大模型）：准确率只有 2.6%（几乎全错，因为它不懂仓库的具体结构）。
  • 加了“历史题库”的 AI：准确率到了 37.4%（有点进步，但遇到新问题还是懵）。
  • PromCopilot：准确率高达 69.1%！而且它还能帮工程师把找东西的时间从 6 分钟 缩短到 1 分半钟。

5. 总结：它意味着什么？

这篇论文的核心贡献在于：

1. 首创了“自然语言转监控代码”的框架：以前没人专门研究怎么把“人话”变成“监控代码”，这是第一个吃螃蟹的。
2. 解决了“上下文缺失”的难题：它证明了，只要给 AI 一张实时的“关系地图”，AI 就能在复杂的系统中精准推理，而不是靠瞎猜。
3. 解放了工程师：以后工程师不需要花大量时间去查文档、记指标名，直接问“我的系统哪里慢了？”，PromCopilot 就能帮你把代码写好。

一句话总结：
PromCopilot 就像给复杂的云原生系统装上了一个智能导航仪。以前工程师得像老练的飞行员一样手动操作仪表盘（写代码），现在只要对着导航仪说“我要去北京”，它就能自动规划路线并驾驶飞机（生成查询代码）带你到达目的地。

技术摘要

以下是关于论文 《PromCopilot: Simplifying Prometheus Metric Querying in Cloud Native Online Service Systems via Large Language Models》 的详细技术总结：

1. 研究背景与问题定义 (Problem)

• 背景：随着云原生在线服务系统（如微服务架构）的日益复杂，指标监控（Metric Monitoring）已成为保障系统可靠性的关键基础设施。Prometheus 及其查询语言 PromQL 是事实上的行业标准。
• 痛点：
  1. 高门槛：编写 PromQL 查询不仅需要掌握复杂的领域特定语言（DSL）语法，还需要深入理解系统的具体上下文（如服务部署拓扑、组件依赖关系、具体的指标名称和标签）。
  2. 上下文缺失：工程师在编写查询时，往往需要花费大量时间在不同平台间搜索系统部署信息（例如：某个服务部署在哪些节点上？这些节点的内存指标标签是什么？）。
  3. 现有方案局限：
     • 通用大语言模型（LLM）缺乏私有领域的系统上下文知识（如具体的指标名、节点 ID），直接生成容易导致语法正确但语义错误的查询。
     • 基于微调或少样本学习（Few-shot Learning）的方法依赖历史问答数据，但在微服务架构中，组件状态（如 Pod 数量、节点分布）是动态变化的，历史数据难以匹配当前实时状态。
     • 传统的检索增强生成（RAG）难以处理多跳推理（Multi-hop Reasoning），例如从“服务名”推导到“部署该服务的节点”再到“节点指标”的复杂路径。

2. 核心方法论 (Methodology)

论文提出了 PromCopilot，一个基于大语言模型（LLM）和知识图谱（Knowledge Graph, KG）协同推理的 Text-to-PromQL 框架。

2.1 系统上下文知识图谱构建 (System Context Knowledge Graph)

为了弥补 LLM 缺乏私有领域知识的缺陷，PromCopilot 首先构建了一个描述系统复杂上下文的 KG：

• 数据源：整合了 Prometheus（指标元数据）、Kubernetes（资源元数据）、分布式追踪（Traces）和系统文档。
• Schema 设计：
  • 系统组件实体：包括 Node, Deployment, Pod, Service, Container, API 等 9 种类型，反映 Kubernetes 资源间的依赖、层级和调用关系。
  • 指标数据实体：包括 Metric 和 Label-Value Pair，反映指标与具体组件的关联。
• 构建过程：自动提取上述数据源中的实体和关系，融合后存入图数据库（Neo4j），并实时更新以保持与系统状态一致。

2.2 协同推理流程 (Synergistic Reasoning)

PromCopilot 将自然语言问题转化为 PromQL 查询的过程分为四个步骤：

1. 问题解析 (Question Parsing)：

   • 利用 LLM 从自然语言中提取两类关键信息：
     • 组件关系路径 (Components Relation Paths)：识别问题中涉及的实体及其依赖关系（例如：Service -> Pod -> Node），使用占位符表示未明确提及的实体名称。
     • 指标 - 组件对 (Metric-Component Pairs)：识别用户想查询的指标描述及其直接关联的组件类型。

2. 系统组件知识检索 (System Component Knowledge Retrieval)：

   • 基于提取的“组件关系路径”，在知识图谱中进行多跳检索（BFS 算法）。
   • 利用相似度搜索（BM25）修正实体名称，将路径中的占位符替换为图谱中真实的实体（如具体的 Pod ID 和 Node ID），生成具体的推理路径（Reasoning Paths）。

3. 指标知识检索 (Metric Knowledge Retrieval)：

   • 指标检索：根据组件类型，在图谱中查找关联的候选指标，利用 BM25 根据描述相关性排序，选取 Top-K 候选指标。
   • 标签值对检索：结合推理路径中的组件信息，检索相关的系统组件标签（如 instance）；利用 LLM 识别语义标签（如 method），并检索具体的标签值。

4. 查询生成 (Query Generation)：

   • 将原始自然语言问题、检索到的指标元数据（名称、描述）、以及完整的推理路径（包含组件依赖和标签信息）作为上下文（Context），输入给 LLM。
   • LLM 基于 Chain-of-Thought (CoT) 和少样本示例，生成最终的 PromQL 查询语句。

3. 主要贡献 (Key Contributions)

1. 框架创新：提出了 PromCopilot，这是首个针对 Text-to-PromQL 任务的框架。它创新性地结合了知识图谱（用于描述动态系统上下文）和 LLM（用于自然语言理解与代码生成），通过协同推理解决私有领域知识缺失和多跳推理难题。
2. 基准数据集：构建了首个 Text-to-PromQL 基准数据集。基于开源微服务系统 TrainTicket，人工构建了 280 个“自然语言问题 - PromQL 查询”对，涵盖了复杂的系统上下文和多跳推理场景，填补了该领域无公开数据集的空白。
3. 实证研究：通过广泛的实验验证了框架的有效性，并进行了消融实验和用户研究，证明了知识图谱在提升查询准确率方面的关键作用。

4. 实验结果 (Results)

• 评估指标：
  • MetricAcc：使用正确指标的比例。
  • SyntaxAcc：语法正确的比例。
  • QueryAcc：查询完全正确（或等价）的比例。
• 性能表现：
  • 使用 GPT-4-Turbo 作为基座模型时，PromCopilot 的 QueryAcc 达到 69.1%，MetricAcc 达到 91.3%。
  • 相比之下，仅使用 Basic Prompt 的 QueryAcc 仅为 2.6%，基于 Few-shot Learning 的方法最高仅为 37.4%。
  • 使用 DeepSeek-Coder-V2 时，PromCopilot 的 QueryAcc 为 66.9%，同样显著优于基线。
• 检索精度：
  • 指标检索的 Recall 达到 90.3%。
  • 推理路径（组件知识）检索的 Recall 达到 90.8%。
• 用户研究：
  • 8 位资深工程师参与测试。使用 PromCopilot 完成查询的平均时间（101.65 秒）仅为使用其他工具（如搜索、手动编写）的 26.6%。
  • 用户对工具的正确性和有用性评分均较高（平均分 > 3.5/4.0）。

5. 意义与价值 (Significance)

• 降低运维门槛：显著降低了工程师使用 Prometheus 进行故障诊断和性能优化的门槛，使非专家也能通过自然语言快速获取关键指标。
• 解决动态上下文难题：通过知识图谱实时同步系统状态，解决了传统 LLM 方法无法适应云原生系统动态变化（如弹性伸缩）的痛点。
• AIOps 新范式：为 AIOps 领域提供了一种不依赖历史故障数据、基于实时系统上下文推理的新范式，提升了系统在未知场景下的泛化能力。
• 开源贡献：公开的数据集和代码为后续研究 Text-to-PromQL 及相关领域提供了重要的基准和工具。

总结：PromCopilot 通过“知识图谱 + 大模型”的双引擎架构，成功将复杂的云原生系统上下文转化为 LLM 可理解的上下文信息，极大地提升了自然语言转 PromQL 的准确率和效率，是云原生可观测性领域的一项重要进展。