当前位置：首页 > news >正文

Elasticsearch：使用 Elastic Workflows 构建自动化

news 2026/5/12 4:18:03

作者：来自 Elastic Tinsae Erkailo, Tal Borenstein 及 Shahar Glazner

Elastic 中工作流自动化的实用入门。了解 workflows 的形式、它们如何工作，以及如何构建一个。

测试 Elastic 领先的开箱即用能力。深入体验我们的示例 notebooks，开启免费的 cloud 试用，或现在就在你的本地机器上试用 Elastic。

Elastic Workflows 是内置于 Elasticsearch 平台中的自动化引擎。你使用 YAML 定义 workflows：是什么触发（启动）它们、它们包含哪些步骤、执行哪些操作，其余的执行由平台负责。一个 workflow 可以查询 Elasticsearch、转换数据、基于条件进行分支、调用外部 APIs，并通过你已配置的 connectors 与 Slack、Jira、PagerDuty 等服务集成。

在这篇博客中，我们将介绍 Workflows 的核心概念，并一起构建一个示例 workflow。

Workflows 是声明式的，并使用 YAML 定义

Workflows 是可组合的。你只需定义应该发生什么，平台会处理执行、错误恢复和日志记录。每个 workflow 都以 YAML 形式定义，并存在于 Kibana 中。

一个 workflow 由几个关键部分组成：triggers、inputs 和 steps。

Triggers决定 workflow 何时运行。alert trigger 会在 Kibana 告警规则触发时运行，并可完全访问告警上下文。scheduled trigger 按时间间隔或 cron 模式运行。manual trigger 可通过 UI 或 API 按需运行。一个 workflow 可以有多个 triggers。

Inputs定义在运行时传入 workflow 的参数。这让你可以创建可复用的 workflows，并根据不同的调用方式接收不同的值。

Steps是 workflow 执行的动作。它们按顺序执行，每个 step 都可以引用前一步的输出。step 类型包括：

用于在 Elasticsearch 和 Kibana 内执行操作的内部操作，例如查询索引、运行 ES|QL 查询、创建 case 或更新 alert。
用于在外部系统上执行操作的外部操作，例如发送 Slack 消息或创建 Jira 工单。你可以使用已在 Elastic 中配置的任何 connector，并通过 HTTP steps 灵活调用任意 API 或内部服务。
用于定义 workflow 逻辑的流程控制，包括条件判断、循环和并行执行。
AI，用于从向 large language model ( LLM ) 发送提示，到将 agents 作为 workflow steps 启用，从而解锁 agentic workflow 用例。

动手实践：你的第一个 workflow

让我们构建一个 workflow，演示核心能力：操作 Elasticsearch 索引、条件逻辑，以及 steps 之间的数据流。我们将创建一个简单的 demo，用来设置 National Parks 索引、加载示例数据并进行搜索。

启用 Workflows

Workflows 在 Elastic 9.3 中可用（Technical Preview）。前往Stack Management→Advanced Settings，并启用Elastic Workflows：

创建一个 workflow

在 Kibana 中导航到 Workflows。如果这是你第一次进入，你将看到 Get Started 界面：

点击Create a new workflow打开编辑器。你也可以探索Example workflows，查看 Elastic Workflow Library —— 一个为搜索、可观测性和安全用例提供的即用型 workflows 集合。

Workflow 编辑器

编辑器提供带有自动补全和校验的 YAML 编辑体验。开始输入一个 step 类型时，会出现建议。使用快速操作菜单（ Cmd+K / Ctrl+K ）按类别浏览可用的 triggers、steps 和 actions：

构建 workflow

这是我们的 National Parks 示例 workflow：

name: National Parks Demo description: Creates an Elasticsearch index, loads sample national park data, searches for parks, and displays the results. enabled: true consts: indexName: national-parks triggers: - type: manual steps: - name: get_index type: elasticsearch.indices.exists with: index: '{{ consts.indexName }}' - name: check_if_index_exists type: if condition: 'steps.get_index.output: true' steps: - name: index_already_exists type: console with: message: 'index: {{ consts.indexName }} already exists. Will proceed to delete it and re-create' - name: delete_index type: elasticsearch.indices.delete with: index: '{{ consts.indexName }}' else: - name: no_index_found type: console with: message: 'index: {{ consts.indexName }} not found. Will proceed to create' - name: create_parks_index type: elasticsearch.indices.create with: index: '{{ consts.indexName }}' mappings: properties: name: type: text category: type: keyword description: type: text - name: index_park_data type: elasticsearch.index with: index: '{{ consts.indexName }}' id: yellowstone document: name: Yellowstone National Park category: geothermal description: "America's first national park, established in 1872, famous for Old Faithful geyser and diverse wildlife including grizzly bears, wolves, and herds of bison and elk." refresh: wait_for - name: search_park_data type: elasticsearch.search with: index: '{{ consts.indexName }}' query: term: _id: yellowstone - name: log_results type: console with: message: 'Found {{ steps.search_park_data.output.hits.total.value }} park with doc id of yellowstone.'

这个 workflow 演示了多项能力：

Constants：定义可复用的值，例如 indexName，并可在整个 workflow 中引用。
Elasticsearch 操作：检查索引是否存在、删除索引、使用 mappings 创建索引、索引一个文档，以及执行搜索。
使用 branches 的条件逻辑：如果索引存在，则记录一条消息并删除它；如果不存在，则记录未找到的消息；无论哪种情况，都会继续创建索引。
数据流：每个 step 都通过 steps..output 引用前一个 step 的输出。

请注意文中多次出现的 {{ }} 语法。这是 Liquid 模板，用于在 steps 之间传递数据。consts 包含 workflow 常量，steps..output 用于引用前一个 step 的输出。

运行 workflow

保存 workflow 后，点击保存按钮旁的播放（Play）按钮来执行它。

Workflow 开始执行后，你会看到执行视图。每个 step 在侧边面板中依次显示，展示其状态和执行时间：

点击任意 step 可以查看它的输入和输出。侧边面板会精确显示 workflow 在每一步接收了什么数据、输出了什么数据。这让调试非常直观：你能看到输入、输出，以及如果 step 失败，问题出在哪里。

扩展 workflow

我们可以给这个 workflow 增加 AI 和外部通知功能。比如，在log_results之后增加一个 step，用 LLM 生成关于公园的诗歌，然后发送到 Slack。

在log_results之后添加这些 steps：

- name: generate_poem type: ai.prompt with: prompt: > Write a short, fun poem about {{ steps.search_park_data.output.hits.hits[0]._source | json }}. Include something about its famous features. No other formatting. - name: share_poem type: slack connector-id: my-slack-connector with: message: | 🏔️ *Poem of the Day about Yellowstone* {{ steps.generate_poem.output.content }}

现在，这个 workflow 会创建索引、加载数据、执行搜索、用 AI 生成诗歌，并分享到 Slack。整个流程的模式是一致的：添加 steps、引用它们的输出，让 workflow 处理执行。

这是一个简单示例，但同样的方法可以扩展到真实用例。把 national parks 替换为安全告警、可观测性指标，或 Elasticsearch 中的任意数据；把诗歌替换为 AI 摘要或评估；把 Slack 替换为 Jira、PagerDuty 或你已配置的任何连接器。

Workflows 与 Elastic Agent Builder

National Parks 示例展示了 Workflows 的核心组件：触发器、steps、条件逻辑、数据流、AI prompts 和外部通知。这些组件可以组合起来构建自动化，在 Elasticsearch、Kibana、外部系统和 AI 中协调执行结果。

这些覆盖的是步骤已知的流程。但如果流程步骤未知，正确操作依赖于你发现的内容，而你发现的内容又依赖于数据来源呢？

这时，Agent Builder 就能扩展可自动化的范围。一个基于你运维上下文的 agent 可以执行分析师或开发者通常手动完成的初步分析或调查。它可以探索、跨数据源推理、提供发现，然后 workflow 继续执行后续的结构化步骤。

Workflows 可以与 Agent Builder 集成，并且这种集成是双向的。

将 Agents 用作 workflow steps

使用ai.agentstep 类型，可以在 workflow 内调用 agent：

- name: analyze type: ai.agent with: agent_id: my-analyst-agent message: 'Analyze this data and recommend next steps: {{ steps.search.output | json }}'

这个 agent 使用它配置的工具来查询索引、关联数据，并对结果进行推理。工作流会等待 agent 的发现，然后继续执行后续步骤。

工作流作为 agent 工具

工作流也可以暴露给 Agent Builder 作为工具，让 agent 在需要采取操作时调用它们。

当 agent 决定需要采取什么行动时，这种模式非常有用，而具体的执行方式应该遵循已知且可重复的流程。Agent 擅长推理、探索和判断，尤其是在信息不完整或不断变化时。工作流则擅长执行包含多个步骤、涉及外部系统以及会改变状态的既定程序。

通过将工作流暴露为工具，你可以将决策与执行分离。Agent 可以判断需要达成特定结果，例如声明一个事件或启动响应，然后将执行委托给编码了正确操作顺序的工作流。该工作流负责跨系统协调，每次都应用相同的逻辑，并确保结果可观测和可审计。

这也使得复用和一致性成为可能。相同的工作流可以由不同的 agent 调用，也可以手动运行，同时强制执行共享的流程和控制集。无需教每个 agent 如何安全且正确地执行复杂操作，这一职责集中在一个地方。

结合起来，这就形成了一个清晰的契约：Agent 决定何时需要采取行动，工作流确保每次行动都遵循正确的流程。

展望未来

这一技术预览确立了工作流作为 Elasticsearch 平台核心能力的基础：触发器、步骤、数据流、AI 集成，以及与 Agent Builder 的双向连接。

接下来将在此基础上扩展工作流的编写方式和呈现方式。除了新增的步骤类型和更广泛的连接器支持外，工作流将支持多种编写模式，包括自然语言意图模式，AI 帮助将你的目标转化为可执行工作流，以及可视化拖拽式构建器。随着这些能力直接嵌入 Elastic 的特定解决方案体验中，它们不仅改变了工作流的构建方式，也改变了实际工作的执行方式。

对于开发者而言，这意味着 AI 助手不再仅仅是对话工具。Agent 可以真正执行操作：查询系统、更新记录、触发流程并返回结果。推理能力有可靠执行作支撑。

在可观测性（Observability）领域，这意味着可以关联日志、指标和追踪信号，识别可能的根本原因，协调修复步骤，实现检测与解决之间的闭环，而无需等待人工干预。

在安全（Security）领域，这意味着调查从警报触发的那一刻就开始，用内部和外部来源的上下文丰富发现，协调跨工具的响应操作，更新案例并通知合适的人。以前需要人工完成的工作，现在可以自动处理。

你今天学到的模式可以直接应用于这些场景。工作流是使这些自动化成为可能的关键层。