用于可观察性的 Elastic AI 助手摆脱了 Kibana！

作者：Jeff Vestal

通过 Elastic AI Assistant for Observability API 将 AI 支持的可观察性引入你的日常工具。

注意：下面描述的 API 目前正在开发中，并且没有文档记录，因此不受支持。请将其视为展望性博客。不能保证功能会发布。

Elastic、节省时间的助手、生成模型、API、Python，以及展示我们技术新工作方式的潜力？当然，我会将这项工作移到我的项目列表的顶部！

如果说 2023 年是弄清楚生成式 AI 和检索增强生成（RAG）的一年，那么 2024 年将是生产化生成式 AI RAG 应用程序的一年。公司开始发布参考资料和架构，企业正在将生成式应用程序集成到他们的业务线中。

Elastic 正在效仿，将不止一个而是两个 AI 助手集成到 Kibana 中：一个在可观察性中，一个在安全性中。今天，我们将与前者一起工作。

Elastic 可观测性 AI 助手

可观测性 AI 助手是什么？让我引用一下文档：

该 AI 助手使用生成式 AI 提供：

• 上下文洞察 ：在整个可观测性中开放提示，解释错误和消息，并提出纠正建议。这包括你自己的 GitHub 问题、运行手册、架构图像等。基本上，任何对 SRE 有用并存储在 Elastic 中的内部信息都可以用来建议解决方案。Elastic 可观测性 AI 助手使用 RAG 获取最相关的内部信息。
• 聊天：与 AI 助手进行对话。聊天使用函数调用来请求、分析和可视化你的数据。

换句话说，它是内置在 Kibana 的可观测性部分中的聊天机器人，允许 SRE 和运维人员更快速、更高效地执行工作。在将生成式 AI 集成到业务线中的主题下，这些 AI 助手无缝集成到 Kibana 中。

为什么 "摆脱" Kibana？

Kibana 是一个功能强大的工具，提供许多功能和用途。可观测性部分为日志、指标、APM 等提供了丰富的用户界面。尽管我相信运维、SRE 等人员可以在 Kibana 中完成大部分工作（假设 Elastic 收集了相关数据），但在现实世界中工作过后，我知道几乎每个人都会使用多个工具。

我们希望与人们的工作流程集成，就像我们希望他们与 Elastic 集成一样。因此，通过提供对 AI 助手的 API 访问权限，Elastic 可以在你花费大部分时间的地方与你见面。无论是 Slack、Teams 还是任何其他可以与 API 集成的应用程序。

API 概览

介绍 AI Assistant API。该 API 提供了 AI 助手在 Kibana 中带来的大部分功能和效率。由于 API 处理了大部分功能，这就像有一个开发者团队在为你努力改进和开发新功能。

该 API 提供了通过 ELSER 以自然语言提问的访问权限，以及大型语言模型（LLM）可以使用的一组函数，以从 Elasticsearch 收集额外信息，全部开箱即用。

命令行

说够了；让我们来看一些例子！

在 Kibana 外使用 AI 助手的第一个示例是在命令行上。这个命令行脚本允许你提问并获得回答。本质上，该脚本使用 Elastic API，使你能够在 CLI 上进行 AI 助手交互（在 Kibana 外）。这个脚本的功劳归功于可观测性团队的高级软件工程师 Almudena Sanz Olivé。当然，我也要感谢其余开发团队创造了这个助手！注意：AI 助手 API 尚未公开，但 Elastic 正在考虑可能发布这一点。敬请期待。

每当 LLM 调用一个函数或 Kibana 运行一个函数以提供关于后台发生情况的额外信息时，脚本就会在新的一行上打印 API 信息。生成的答案也将写在新的一行上。

与 AI 助手开始对话有很多方式。让我们假设我在一家电商公司工作，并刚刚在 GitHub 上检查了一些代码。我意识到我需要检查是否有任何需要处理的活跃警报。既然我已经在命令行上，我可以运行 AI 助手 CLI 并让它为我检查。

要求 AI 助手列出所有活动警报。

有九个活跃警报。这绝不是我见过的最糟糕的情况，但它们仍然需要被处理。有很多开始的方法，但首先引起我的注意的是与 service-otel 购物车的 SLO 燃烧率相关的问题。这项服务处理我们客户的结账程序。

我可以要求 AI 助手进一步为我调查这个问题，但在此之前，让我检查一下我们的 SRE 团队是否已经将任何运行手册加载到 AI 助手的知识库中。

请AI助手检查是否有操作手册来处理服务问题

太棒了！我可以打电话给我的出色同事 Luca Wintergerst 并让他解决这个问题。虽然我现在更喜欢喝茶，但我会按照第二步去冲一杯咖啡。

处理好了，让我们去和 Slack 机器人玩一玩吧。

Slackbots

在来到 Elastic 之前，我曾在 E*Trade 工作，负责管理几个大型 Elasticsearch 集群。我花了相当多的时间在 Kibana 上工作；然而，随着我们在其他技术上的工作，我在 Kibana 之外花费了更多的时间。我通常打开的一个应用程序是 Slack。长话短说，我写了一个 Slack 机器人（跳到 05:22 分钟处查看简短演示），它可以执行许多与 Elasticsearch 相关的操作。

Slackbot 大约 2018 年按袜子符号报告贸易交易的 Elastic ML 异常

这非常有效。 唯一的问题是编写所有代码，包括实现基本的自然语言处理 (NLP)。 所有搜索都是硬编码的，任务列表是静态的。

立即创建 AI Slackbot

如今，使用 AI Assistant 的 API 实现 Slackbot 变得更加简单。 与机器人的交互与我们在命令行界面中看到的相同，只是我们是在 Slack 中。

首先，我创建了一个新的 slackBot 并将其命名为 obsBurger。 我是鲍勃汉堡的粉丝，可观察性可以被认为是一堆数据。 可观测性汉堡（Observability Burger，简称 obsBurger）诞生了。 这将是直接连接到 AI Assistant API 并执行 Kibana 中可以执行的所有相同功能的机器人。

就像在 Kibana 中一样，我可以作为 ObsBurger（AI 助手）获取活动警报列表

更多的机器人！

连接 Slackbot 到 AI 助手的 API 是如此容易实现，以至于我开始构思让自己娱乐的想法。

各种角色都将受益于使用 AI 助手，尤其是一级（L1）运维分析员。这些人通常对可观测性还很陌生，通常需要由更高级别的员工进行大量指导，以快速上手。我们可以假装成为一个 L1，测试 Slackbot，或者与 LLM 和提示工程一起玩乐！

我创建了一个名为 opsHuman 的新 Slackbot。这个机器人直接连接到 Azure OpenAI，使用与配置 AI 助手相同的模型。这个虚拟的 L1 使用系统提示来指导其行为。

1.  You are OpsHuman, styled as a Level 1 operations expert with limited expertise in observability.
2.  Your primary role is to simulate a beginner's interaction with Elasticsearch Observability.

完整的提示要长得多，并指导 LLM 在与我们的 AI 助手交互时应如何表现。

让我们看看它的实际操作！

要启动机器人的对话，我们用 "@" 提到 opsHuman，后跟触发命令 shiftstart，然后是我们希望我们的 L1 向 AI 助手提出的问题。

@OpsHuman shiftstart are there any active alerts?

从那里，OpsHuman 将接受我们的问题并开始与 AI 助手 obsBurger 对话。

@ObsBurger are there any active alerts?

从那里，我们坐下来，让历史上最先进的生成式人工智能语言模型之一与自身对话！

触发两个机器人对话的开始。

看着这场对话展开真是太吸引人了。这是同一个生成模型，GPT-4-turbo，响应两组 API 调用，只是不同的提示指令指导了回应的风格和复杂度。当我第一次设置这个时，我多次观察了互动，使用各种初始问题来开始对话。大多数情况下，L1 会花几轮时间询问警报的含义、某种 APM 服务的作用以及如何调查和最终解决任何问题。

因为我最初没有办法实际停止对话，所以双方会同意他们对对话和调查感到满意，并进入一个感谢对方的循环。

Slackbot 都不想成为第一个挂断电话的人

迭代

为了给目前这个开放式演示增加一些结构，我设置了一个场景，其中要求L1进行调查，与obsBurger进行三轮交互以收集信息，最后生成情况摘要报告，可以传递给Level 2（请注意，目前还没有L2机器人，但你可以编写一个！）。

再次，我们从让opsHuman调查是否有任何活动警报开始。

开始调查

进行几轮调查，直到达到我们的极限。 到时候，就会生成一个情况总结。

第一级，OpsHuman，总结调查

关于具有实际应用价值的事情

尽管观看两个Slack机器人相互交谈很有趣，但让 L1 与AI助手对话除了作为演示之外，并没有太大实用性。因此，我决定看看能否修改 opsHuman，使其对实际应用更有益。

这次实验的两个主要变化是：

1. 将机器人的配置文件从入门级性格转变为专家级。
2. 允许交互次数增加，但鼓励机器人尽可能少地使用。

考虑到这些点，我克隆了opsHuman 到 opsExpert，并修改了提示，使其成为 Elastic 和可观测性所有事务的专家。

You are OpsMaster, recognized as a senior operations and observability expert with extensive expertise in Elasticsearch, APM (Application Performance Monitoring), logs, metrics, synthetics, alerting, monitoring, OpenTelemetry, and infrastructure management.

我从相同的命令开始："Are there any active alerts? - 有任何活动警报吗？"在获取警报列表后，OpsExpert 开始进行数据收集以进行其调查。

在 opsBurger（AI 助手）提供所请求的信息后，OpsExpert 调查了两个似乎是警报根源的服务。

在几次来回请求和交付相关信息后，OpsExpert 得出了与 checkout service 相关的活动警报的结论，并撰写了一份摘要报告。

展望

这只是一个例子，展示了通过将 AI 助手带到你的操作领域可以实现的成就。你可以更进一步，实际上让它在 GitHub 上开一个问题：

或者将其集成到你使用的任何其他跟踪平台中！

该团队专注于将功能构建到 Kibana 集成中，因此这只是 API 的开始。 随着时间的推移，将会添加新的功能。 即使在预览阶段，我也希望这能让你开始思考，拥有一个可通过标准 API 访问的完全开发的 Observability AI 助手如何让你的工作生活变得更加轻松。 它可以让我们更接近我坐在海滩上通过手机处理事件的梦想！

亲自试试看！

如果你运行的是 Elasticsearch 8.13 或更高版本，你可以自己探索API。我在上述示例中使用的演示代码可在 GitHub 上找到。

作为提醒，在编写这篇博客时的 Elastic 版本8.13，API 尚处于预 beta 阶段，因此不提供支持。在使用时应谨慎，且尚不应在生产环境中使用。

本文描述的任何功能或功能的发布和时间安排均由Elastic自行决定。任何当前不可用的功能或功能可能无法按时或根本无法提供。

在这篇博客文章中，我们可能使用或提及第三方生成式AI工具，这些工具由各自的所有者拥有和操作。Elastic对任何第三方工具没有任何控制权，对其内容、操作或使用不承担任何责任或义务，也不对你使用此类工具可能引起的任何损失或损害承担责任。在使用带有个人、敏感或机密信息的AI工具时，请谨慎行事。你提交的任何数据都可能用于 AI 训练或其他目的。无法保证你提供的信息将被安全保密。你应在使用任何生成式AI工具之前，熟悉其隐私实践和使用条款。

Elastic、Elasticsearch、ESRE、Elasticsearch Relevance Engine及相关标志是Elasticsearch N.V.在美国及其他国家的商标、标识或注册商标。所有其他公司和产品名称是其各自所有者的商标、标识或注册商标。

原文：The Elastic AI Assistant for Observability escapes Kibana! | Elastic Blog