Elastic 可观测性 AI 助手逃离了 Kibana！

注意：下面描述的 API 目前正在开发中，未记录，因此不受支持。请将其视为前瞻性博客。功能不保证发布。

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

如果说 2023 年是研究生成式 AI 和检索增强生成 (RAG) 的一年，那么 2024 年将是生产化生成式 AI RAG 应用的一年。各公司开始发布参考和架构，企业正在将生成式应用程序集成到其业务线中。

Elastic 也紧随其后，在 Kibana 中集成了两个 AI 助手：一个在可观测性中，一个在安全中。今天，我们将使用前者。

Elastic 可观测性 AI 助手

什么是可观测性 AI 助手？请允许我引用文档

AI 助手使用生成式 AI 来提供

• _ 情境化见解： _ 在整个可观测性中打开提示，解释错误和消息，并提出补救措施。这包括您自己的 GitHub 问题、操作手册、架构图像等。本质上，任何内部对 SRE 有用并存储在 Elastic 中的内容都可以用于提出解决方案。 Elastic 可观测性 AI 助手使用 RAG 获取最相关的内部信息。

• _ 聊天： _ 与 AI 助手进行对话。聊天使用函数调用来请求、分析和可视化您的数据。

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

为什么要“逃离”Kibana？

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

我们希望尽可能多地与人们的工作流程集成，就像我们希望他们与 Elastic 集成一样。因此，提供对 AI 助手的 API 访问允许 Elastic 在您花费最多时间的地方与您会面。无论是 Slack、Teams 还是任何其他可以与 API 集成的应用程序。

API 概述

进入 AI 助手 API。该 API 提供了 AI 助手在 Kibana 中带来的大部分功能和效率。由于 API 处理大部分功能，因此它就像一个开发人员团队在为您改进和开发新功能。

该 API 允许通过 ELSER 和一组大型语言模型 (LLM) 可以使用的函数来以自然语言提问，以便从 Elasticsearch 中收集更多信息，所有这些都是开箱即用的。

命令行

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

在 Kibana 之外使用 AI 助手的第一个示例是在命令行上。此命令行脚本允许您提问并获得答复。本质上，该脚本使用 Elastic API 使您能够在 CLI 上（在 Kibana 之外）进行 AI 助手交互。此脚本的功劳归于可观测性团队的高级软件工程师 Almudena Sanz Olivé。当然，我还想感谢开发团队的其他成员创建了助手！注意：AI 助手 API 尚未公开，但 Elastic 正在努力争取发布。请继续关注。

每次 LLM 调用函数或 Kibana 运行函数以提供有关幕后发生情况的更多信息时，该脚本都会在新行上打印 API 信息。生成的答案也将写在新行上。

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

有九个活动警报。这绝不是我见过的最糟糕的计数，但仍然应该解决。有很多方法可以从这里开始，但首先引起我注意的是与 service-otel cart 上的 SLO 燃烧率相关的警报。此服务处理我们客户的结帐流程。

我可以要求 AI 助手为我进行更多调查，但首先，让我检查一下我们的 SRE 团队是否已将任何操作手册加载到 AI 助手的知识库中。

太棒了！我可以打电话给我的出色同事 Luca Wintergerst 并让他修复它。虽然这些天我更喜欢茶，但我会按照第二步，喝一杯咖啡。

处理完这些之后，让我们在 SlackBots 上玩得开心吧。

Slackbots

在加入 Elastic 之前，我在 E*Trade 工作，我所在的团队负责管理多个大型 Elasticsearch 集群。我花了很多时间在 Kibana 中工作；但是，随着我们研究其他技术，我花在 Kibana 之外的时间更多。我通常打开的一个应用程序是 Slack。长话短说，我写了一个 Slackbot（跳到 05:22 标记处以查看其简短演示），它可以执行许多 Elasticsearch 操作。

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

今天创建一个 AI Slackbot

今天使用 AI 助手的 API 实施 Slackbot 要简单得多。与机器人的交互与我们在命令行界面中看到的相同，只是我们现在是在 Slack 中。

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

更多机器人！

通过 Slackbot 连接到 AI 助手的 API 是如此容易实现，以至于我开始集思广益，想出娱乐自己的主意。

各种角色都可以从使用 AI 助手获益，尤其是 一级 (L1) 运维分析师。这些人通常是可观测性领域的新手，通常需要更资深的员工进行大量指导才能快速上手。我们可以假装自己是 L1，测试 Slack 机器人，或者尝试使用 LLM 和提示工程，从中获得乐趣！

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

您是 OpsHuman，定位为在可观测性方面经验有限的 1 级运维专家。
您的主要角色是模拟初学者与 Elasticsearch 可观测性的交互。

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

让我们看看它的实际效果！

为了启动机器人的对话，我们使用“@”提及 opsHuman，并使用触发命令 shiftstart，然后是我们希望 L1 向 AI 助手提出的问题。

@OpsHuman shiftstart 是否有任何活动警报？

接下来，OpsHuman 将接收我们的问题，并开始与 obsBurger（AI 助手）进行对话。

@ObsBurger 是否有任何活动警报？

之后，我们就可以坐下来，观看历史上最先进的生成式 AI 语言模型自己进行对话！

观看这个对话的展开过程非常有趣。这是相同的生成模型 GPT-4-turbo，它响应两组 API 调用，只有不同的提示指令来指导响应的风格和复杂性。当我第一次设置这个时，我多次观看了交互过程，使用各种初始问题来开始对话。大多数情况下，L1 会花费几轮时间询问有关警报含义、APM 服务类型的作用以及如何调查并最终解决任何问题。

由于我最初没有实际停止对话的方法，双方会同意他们对对话和调查感到满意，然后陷入互相感谢的循环。

迭代

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

再次，我们首先让 opsHuman 调查是否有任何活动警报。

执行几轮调查，直到达到我们的限制。届时，它将生成一份情况摘要。

试试看一些具有实际应用的东西

虽然观看两个 Slack 机器人互相交谈很有趣，但让 L1 与 AI 助手对话除了演示之外并没有什么用处。因此，我决定看看是否可以修改 opsHuman，使其在实际应用中更有益。

此实验的两个主要更改是

1. 将机器人的配置文件从入门级人格转变为专家级人格。

2. 允许交互次数增加，但鼓励机器人尽可能少地使用交互次数。

考虑到这些要点，我将 opsHuman 克隆到 opsExpert 中，并修改了提示，使其成为 Elastic 和可观测性方面的专家。

您是 OpsMaster，被公认为在 Elasticsearch、APM (应用程序性能监控)、日志、指标、合成数据、警报、监控、OpenTelemetry 和基础设施管理方面具有丰富专业知识的高级运维和可观测性专家。

我从相同的命令开始：是否有任何活动警报？在获取警报列表后，OpsExpert 深入研究了其调查的数据收集。

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

经过几次来回请求和交付相关信息后，OpsExpert 针对与结账服务相关的活动警报得出了结论，并撰写了一份摘要报告。

展望未来

这只是将 AI 助手引入您的操作环境中所能实现的一个示例。您可以更进一步，让它实际在 GitHub 上打开一个问题。

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

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

自己尝试一下！

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

提醒一下，截至 Elastic 8.13 版本（撰写此博客时），由于 API 处于预测试阶段，因此不支持该 API。使用时应谨慎，并且尚不应在生产环境中使用。

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

在本博文中，我们可能使用了或引用了第三方生成式 AI 工具，这些工具由其各自的所有者拥有和运营。Elastic 对第三方工具没有任何控制权，并且我们对其内容、操作或使用概不负责，也不对您使用此类工具可能造成的任何损失或损害负责。在使用带有个人、敏感或机密信息的 AI 工具时请务必谨慎。您提交的任何数据都可能用于 AI 训练或其他目的。不能保证您提供的信息会被安全或保密地保存。您应在使用之前熟悉任何生成式 AI 工具的隐私惯例和使用条款。

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