通过用于可观测性的 AI 助手和您组织的操作手册增强 SRE 故障排除能力

可观测性 AI 助手利用自然语言界面，通过自动调用函数来请求、分析和可视化您的数据，从而将数据转化为可操作的可观测性，帮助用户探索和分析可观测性数据。该助手还可以建立一个知识库，该知识库由 Elastic Learned Sparse EncodeR (ELSER) 提供支持，以提供来自私有数据的其他上下文和建议，以及使用 RAG（检索增强生成）的大型语言模型 (LLM)。Elastic Stack 作为一个具有开箱即用语义搜索和 LLM 集成连接器的向量数据库，以及可观测性解决方案，是将公司独特的可观测性知识与生成式 AI 相结合以提取最大价值的完美工具包。

增强 SRE 的故障排除能力

大型组织中的站点可靠性工程师 (SRE) 在定位用于排除警报、监控系统或获取见解的必要信息时，常常面临挑战，原因是资源分散且可能过时。对于经验较少的 SRE 来说，即使有操作手册，他们也可能需要帮助，这个问题尤其突出。重复发生的事件是另一个问题，因为值班人员可能不了解之前的解决方案和后续步骤。成熟的 SRE 团队通常会投入大量时间进行系统改进，以尽量减少“救火”的情况，他们会利用大量的自动化和文档来支持值班人员。

Elastic® 通过将生成式 AI 模型与使用 RAG 从您的内部数据中搜索到的相关结果相结合，来解决这些挑战。由我们的语义搜索检索模型 ELSER 提供支持的可观测性 AI 助手的内部知识库可以在对话期间的任何时候回忆信息，并根据内部知识提供 RAG 响应。

此知识库可以使用您组织的信息进行丰富，例如操作手册、GitHub 问题、内部文档和 Slack 消息，从而使 AI 助手能够提供特定的帮助。助手还可以记录和存储 SRE 在排除问题时正在进行的对话中的特定信息，从而有效地创建供将来参考的操作手册。此外，助手还可以生成事件、系统状态、操作手册、事后分析或公开声明的摘要。

这种检索、总结和呈现上下文相关信息的能力对于 SRE 团队来说是一项重大变革，它将工作从追逐文档和数据转变为直观、上下文敏感的用户体验。知识库（请参阅要求）充当可观测性知识的中心存储库，打破文档孤岛并整合部落知识，使这些信息可供 SRE 访问，并由 LLM 的强大功能进行增强。

您的 LLM 提供商可能会在使用 AI 助手时收集查询遥测数据。如果您的数据是机密的或包含敏感详细信息，我们建议您验证您提供给 AI 助手的 LLM 连接器的数据处理策略。

在本博客文章中，我们将介绍使用内部信息丰富您的知识库 (KB) 的不同方法。我们将重点关注一个特定警报，该警报表明具有“502 Bad Gateway”错误的日志增加，并且已超过警报的阈值。

如何使用知识库排除警报

在 KB 使用内部信息进行丰富之前，当 SRE 询问 AI 助手如何排除警报时，来自 LLM 的响应将基于其在训练期间学习的数据；但是，LLM 无法回答与私有、最近或新兴知识相关的问题。在这种情况下，当要求提供排除警报的步骤时，响应将基于一般信息。

但是，一旦 KB 使用您的操作手册进行了丰富，当您的团队收到关于“502 Bad Gateway”错误的新警报时，他们就可以使用 AI 助手访问内部知识进行故障排除，并使用语义搜索在知识库中找到适当的操作手册。

在本博客中，我们将介绍在知识库中添加有关如何排除警报的内部信息的不同方法

要求助手记住现有操作手册的内容。
要求助手总结对话期间采取的步骤并将其存储在知识库中，并将其存储为操作手册。
使用我们的连接器和 API 将您的操作手册从 GitHub 或其他外部来源导入到知识库。

将操作手册添加到 KB 后，AI 助手现在能够回忆起操作手册中的内部和特定信息。通过利用检索到的信息，LLM 可以为排除警报提供更准确和相关的建议。这可能包括建议警报的潜在原因、解决问题的步骤、未来事件的预防措施，或要求助手帮助使用函数执行操作手册中提到的步骤。通过掌握更准确和相关的信息，SRE 可以更快地解决警报，从而减少停机时间并提高服务可靠性。

您的知识库文档将存储在索引 .kibana-observability-ai-assistant-kb-* 中。请记住，LLM 对模型一次可以读取和写入的信息量有限制，称为令牌限制。想象一下，您正在阅读一本书，但您一次只能记住一定数量的单词。一旦您达到该限制，您就会开始忘记您之前读过的单词。这类似于 LLM 中令牌限制的工作方式。

为了使操作手册保持在检索增强生成 (RAG) 模型的令牌限制内，请确保信息简洁且相关。使用项目符号以保持清晰，避免重复，并使用链接获取其他信息。定期查看和更新操作手册，以删除过时或不相关的信息。目标是提供清晰、简洁且有效的故障排除信息，而不会因令牌限制而影响质量。LLM 非常适合总结，因此您可以要求 AI 助手帮助您使操作手册更加简洁。

要求助手记住现有操作手册的内容

将 Runbook 存储到知识库的最简单方法是直接让 AI 助手来完成！开启一个新的对话，并提问“你能把这个 Runbook 存储到知识库以供将来参考吗？”，然后粘贴 Runbook 的纯文本内容。

AI 助手会自动将其存储在知识库中，就这么简单。

让助手总结并存储对话过程中采取的步骤到知识库中

你还可以让 AI 助手在对话时记住一些事情——例如，在使用 AI 助手排查完警报后，你可以要求“记住下次如何排查此警报”。AI 助手会创建一个排查警报的步骤摘要，并将其添加到知识库中，从而为将来参考创建 Runbook。下次你遇到类似情况时，AI 助手将回忆起这些信息并用它来帮助你。

在下面的演示中，用户要求助手记住为排查警报根本原因而采取的步骤，并在再次发生这种情况时 ping Slack 频道。在稍后与助手的对话中，用户询问如何解决类似问题，AI 助手能够记住这些步骤，并提醒用户 ping Slack 频道。

收到警报后，你可以打开 AI 助手聊天并测试对警报进行故障排除。调查警报后，请 AI 助手总结分析和查找根本原因所采取的步骤。为了下次记住它们，如果再次遇到类似的警报，可以添加额外的指示，比如警告 Slack 频道。

助手将使用内置功能来总结步骤，并将它们存储到你的知识库中，以便在以后的对话中可以调用它们。

开启一个新的对话，询问当排查与我们刚刚调查的警报类似的警报时需要采取哪些步骤。助手将能够回忆起存储在知识库中与特定警报相关的信息，使用基于 ELSER 的语义搜索，并提供排查该警报所采取步骤的摘要，包括通知 Slack 频道的最后指示。

使用 API 或我们的 GitHub 连接器将存储在 GitHub 中的 Runbook 导入到知识库

你还可以通过将专有数据（例如，GitHub Issues、Markdown 文件、Jira 工单、文本文件）摄取到 Elastic 中，以编程方式将它们添加到知识库中。

如果你的组织创建的 Runbook 存储在 GitHub 中的 Markdown 文档中，请按照本博客文章下一节中的步骤将 Runbook 文档索引到你的知识库中。

将文档摄取到知识库中的步骤如下：

将你组织的知识摄取到 Elasticsearch 中

选项 1： 使用 Elastic Web 爬虫 。使用 Web 爬虫以编程方式发现、提取和索引来自网站和知识库的可搜索内容。当你使用 Web 爬虫摄取数据时，会创建一个搜索优化的 Elasticsearch® 索引来保存和同步网页内容。

选项 2：使用 Elasticsearch 的 Index API 。观看教程，其中演示了如何使用 Elasticsearch 语言客户端从应用程序中摄取数据。

选项 3：构建你自己的连接器。 请按照此博客中描述的步骤操作：如何为 Elasticsearch 创建自定义连接器。

选项 4：使用 Elasticsearch Workplace Search 连接器 。例如，GitHub 连接器可以自动捕获、同步和索引 issues、Markdown 文件、pull requests 和 repos。

按照以下步骤在 GitHub 中配置 GitHub 连接器，以从 GitHub 平台创建一个 OAuth 应用程序。

现在你可以将 GitHub 实例连接到你的组织。前往你组织的 Search > Workplace Search 管理仪表板，然后找到“Sources”选项卡。

在“Configured Sources”列表中选择 GitHub （或 GitHub Enterprise），并按照显示的 GitHub 身份验证流程操作。成功完成身份验证流程后，你将被重定向到 Workplace Search，并提示你选择要同步的组织。

配置连接器并选择组织后，内容应同步，你将能够在“Sources”中看到它。如果你不需要索引所有可用内容，你可以通过 API 指定索引规则。这将有助于缩短索引时间并限制索引的大小。请参阅自定义索引。

源已在 Elastic 中创建了一个索引，其中包含你组织的内容（Issues、Markdown 文件…）。你可以通过导航到 Stack Management > Index Management，激活右侧的 Include hidden Indices 按钮，并搜索 “GitHub” 来找到索引名称。

你可以通过创建数据视图并在 Discover 中浏览它来探索已索引的文档。转到 Stack Management > Kibana > Data Views > Create data view 并输入数据视图名称、索引模式（确保在高级选项中激活“Allow hidden and system indices”），以及时间戳字段。

你现在可以使用数据视图在 Discover 中探索文档。

使用 AI 助手的语义搜索管道将内部 Runbook 重新索引到 AI 助手的知识库索引中

你的知识库文档存储在索引 .kibana-observability-ai-assistant-kb-* 中。要将从 GitHub 导入的内部 Runbook 添加到 KB，你只需将你在上一步中创建的索引中的文档重新索引到 KB 的索引中。要向 KB 中的文档添加语义搜索功能，重新索引还应使用为 KB 预先配置的 ELSER 管道 .kibana-observability-ai-assistant-kb-ingest-pipeline。

通过使用 KB 索引创建数据视图，你可以在 Discover 中探索内容。

你在 Management > Dev Tools 中执行以下查询，确保替换以下内容（在 “_source” 和 “inline” 上）：

InternalDocsIndex：存储内部文档的索引的名称
text_field：包含内部文档文本的字段的名称
timestamp：内部文档中时间戳的字段的名称
public：（true 或 false）如果为 true，则使文档对定义的 Kibana Space 中的所有用户（如果已定义）或所有空间（如果未定义）可用；如果为 false，则文档将仅限于指示的用户
（可选）space：如果已定义，则限制内部文档仅在特定的 Kibana Space 中可用
（可选）user.name：如果已定义，则限制内部文档仅对特定用户可用
（可选）“query” 过滤器，仅索引某些文档（见下文）

POST _reindex
{
    "source": {
        "index": "<InternalDocsIndex>",
        "_source": [
            "<text_field>",
            "<timestamp>",
            "namespace",
            "is_correction",
            "public",
            "confidence"
        ]
    },
    "dest": {
        "index": ".kibana-observability-ai-assistant-kb-000001",
        "pipeline": ".kibana-observability-ai-assistant-kb-ingest-pipeline"
    },
    "script": {
        "inline": "ctx._source.text=ctx._source.remove(\"<text_field>\");ctx._source.namespace=\"<space>\";ctx._source.is_correction=false;ctx._source.public=<public>;ctx._source.confidence=\"high\";ctx._source['@timestamp']=ctx._source.remove(\"<timestamp>\");ctx._source['user.name'] = \"<user.name>\""
    }
}

你可能希望指定你在 KB 中重新索引的文档类型——例如，你可能只想重新索引 Markdown 文档（如 Runbook）。你可以向源中的文档添加 “query” 过滤器。在 GitHub 的情况下，Runbook 由包含字符串 “file” 的 “type” 字段标识，你可以像下面指示的那样将其添加到重新索引查询中。要添加 GitHub Issues，你还可以在查询中包含包含字符串 “issues” 的 “type” 字段

"source": {
        "index": "<InternalDocsIndex>",
        "_source": [
            "<text_field>",
            "<timestamp>",
            "namespace",
            "is_correction",
            "public",
            "confidence"
        ],
    "query": {
      "terms": {
        "type": ["file"]
      }
    }

太棒了！现在数据已存储在你的知识库中，你可以向 Observability AI 助手提出有关它的任何问题

结论

总之，利用内部 Observability 知识并将其添加到 Elastic 知识库可以大大增强 AI 助手的能力。通过手动输入信息或以编程方式摄取文档，SRE 可以创建一个通过 Elastic 和 LLM 的强大功能访问的知识中央存储库。AI 助手可以调用此信息、协助处理事件，并使用检索增强生成为特定上下文提供量身定制的可观测性。通过遵循本文概述的步骤，组织可以释放其 Elastic AI 助手的全部潜力。

立即开始使用 Elastic AI 助手丰富你的知识库，并为你的 SRE 团队提供他们所需的工具，以便取得卓越的成绩。请按照本文概述的步骤，将你的事件管理和警报补救流程提升到一个新的水平。你迈向更高效、更有效的 SRE 运营的旅程现在开始。

本文中描述的任何特性或功能的发布和时间安排仍由 Elastic 自行决定。任何当前不可用的特性或功能可能不会按时交付，甚至根本不会交付。

在此博客文章中，我们可能使用或引用了第三方生成式 AI 工具，这些工具归其各自所有者所有和运营。Elastic 对第三方工具没有任何控制权，我们对其内容、操作或使用概不负责，也不对因你使用此类工具而可能造成的任何损失或损害承担责任。使用包含个人、敏感或机密信息的 AI 工具时请谨慎。你提交的任何数据都可能用于 AI 训练或其他目的。我们不保证你提供的信息将保持安全或机密。你应在使用任何生成式 AI 工具之前熟悉其隐私惯例和使用条款。

Elastic、Elasticsearch、ESRE、Elasticsearch Relevance Engine 和相关标记是 Elasticsearch N.V. 在美国和其他国家/地区的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。