每个搜索团队都需要的三个 SLO：使用 OpenTelemetry 监控搜索延迟、可用性和质量

作者：来自 Elastic Matthew Adams

你的 OpenTelemetry 搜索 span 已经携带了用于 SLO、消耗速率告警、 异常检测 和事件响应的信号，这篇文章将介绍如何在 Elastic Observability 中构建这四项能力。

好奇想体验一下 Elastic Cloud？订阅 AWS Marketplace 或 Microsoft Azure Marketplace，即可获得最高 $1,000 的账单抵扣额度。

你的 API 处理的每个搜索请求都会自动生成一个 OpenTelemetry span，其中包含延迟、错误和结果数量数据。你最初构建这些检测是为了进行产品分析。结果证明，它们也可以免费为你提供搜索监控能力。本文将利用这些 span 构建三个 SLO（99% 的查询低于 250ms、99.9% 的可用性、零结果率低于 15%），然后在此基础上增加告警、异常检测和事件响应工作流，全部使用 Elastic Observability 内置的工具。如果你按照本系列第 2-4 篇博客为搜索 API 添加了检测，那么一个下午就可以完成这套配置。

你将了解到什么

在本文中，你将学习如何：

• 使用 Elastic APM 的内置视图探索搜索延迟和吞吐量，以及探索错误。

• 为搜索定义服务级别目标（SLO），包括延迟目标、可用性以及搜索质量。

• 在 Kibana 中创建 SLO，持续跟踪搜索健康状况，并配置消耗速率告警。

• 使用 Elasticsearch Query Language（ES|QL）构建运维仪表板，展示延迟百分位数、时间分解以及趋势。

• 针对延迟回归、错误激增以及零结果率上升设置告警。

• 建立用于搜索性能下降的事件响应模式。

你需要什么

• 来自 第 2-4 篇博客 的搜索检测（在 Elastic 中包含 search.* 属性的搜索 span）。

• 具有创建 SLO 和告警规则权限的 Kibana 访问权限。

• 对 SLO 有基本了解。（我们会解释搜索相关的部分。）

• 一个具有 Enterprise 订阅的 Elastic 集群、Elastic Cloud 试用版，或者已激活试用版的 本地部署。

为什么搜索监控的重要性超越了 集群 健康状况

搜索是大量访客的主要导航路径，而通过搜索发起的会话通常比浏览会话表现出更强的购买意愿。搜索中断是一个收入事件，而不是轻微的功能降级。从 100ms 增加到 500ms 的延迟回归，会在任何人提交工单之前就改变用户行为。

大多数平台团队都会在基础设施层面监控搜索，检查 Elasticsearch 集群是否健康以及节点是否正常响应。他们也会检查磁盘是否已满。这些都很有必要，但还不够。即使集群状态为绿色，搜索质量也可能在悄无声息地下降；例如，错误的索引 部署 导致查询返回过期数据，或者随着索引增长，延迟逐渐升高。还可能出现由于同义词列表没有更新而导致零结果率不断上升的情况。

缺失的部分就在于"搜索正常运行"和"搜索运行良好"之间。

关于示例的说明： 和本系列前面的文章一样，我们使用电商搜索作为具体示例，但这些可靠性模式同样适用于任何搜索应用，包括内容平台、内部知识库、招聘网站和支持门户。

OpenTelemetry 搜索 span 作为监控信号

如果你的团队按照本系列的第 2-4 篇博客进行操作，那么每个搜索请求都已经会生成一个包含 search.* 属性的 OTel span。这些属性包括查询文本、结果数量、Elasticsearch 执行时间和错误状态。这些 span 会进入 Elastic 中的 traces-generic.otel-default。

想跟着代码一起操作？ 参考项目包含了第 2-4 篇博客中的全部检测。生成流量，然后按照下面的 SLO 和仪表板配置步骤操作。参见 queries/blog6_reliability.esql，其中包含可以直接运行的查询。

搜索团队最初构建这些检测是为了_产品分析_，也就是了解用户搜索的内容，并衡量点击率（CTR）和转化率。他们一直将相关性工作放在优先位置，但这些相同的 span 中已经包含了进行运维监控所需的一切信息。span 时长提供了延迟信号，而 search.result_count == 0 的值反映了质量。span 错误则提供了可用性信号。

本文将展示如何利用这些运维价值，从你现在就可以在 Kibana 中看到的信息开始，然后在此基础上构建 SLO 和告警，并加入事件响应。

使用 Elastic APM 开箱即用地监控搜索

在构建任何新东西之前，我们先看看 Elastic APM 开箱即用地提供了什么。

如果你的搜索 API 使用 Elastic Distribution of OpenTelemetry（EDOT）进行了 instrumentation（如第 2 篇博客所示），它会自动作为一个服务出现在 Elastic APM UI 中。在 Kibana 中打开 Observability > APM > Services ，然后选择你的搜索服务（如果你使用参考项目，其名称为 search-analytics-demo）。你会立即看到以下内容：

Elastic APM 搜索服务概览

服务概览页面会显示随时间变化的延迟分布和吞吐量，以及错误率，无需进行任何配置。你可以一眼判断搜索是否健康，而时间序列图表会让回归问题非常明显。如果延迟在昨天的部署之后开始上升，你会在这里看到。

Trace waterfall：分解搜索请求延迟

点击任意 transaction，你会看到_trace waterfall_，它会以可视化方式展示请求中的每个 span。在搜索 API 调用中，通常会显示：

waterfall 让原本不可见的内容变得可见。你可以看到 503ms 的 API 响应由 HTTP 处理、241ms 的 query rules 查询、260ms 的 Elasticsearch 查询，以及自定义的 search span（36ms）组成，其中包含我们所有的 search.* 属性。点击任意 span，元数据浮层会准确显示捕获到的信息：search.query: "usb hub"、search.result_count: 33、search.took_ms: 43、索引名称、hit ID 以及更多信息。

第 2 篇博客讨论了 search.took_ms 与 span duration 之间的差异。waterfall 无需编写任何查询，就能准确显示这一差异发生在哪里。

使用 OpenTelemetry 自动捕获搜索错误

OTel 自动 instrumentation 提供的最有价值的功能之一就是_自动错误捕获_。当 Elasticsearch 查询因为熔断器触发或超时等问题失败，或者找不到索引时，span 会记录异常 类 型和消息，以及 stack trace。第 4 篇博客曾将其作为基于 span 的转化跟踪的一个附带好处进行介绍；在这里，它则成为运维工作中的生命线。

服务页面上的 Errors 标签页会自动聚合这些错误，并按照错误类型和出现频率进行分组。instrumentation 会为你捕获这些详细信息，因此你不需要自定义错误处理或日志记录。在事件发生期间，这通常是了解究竟什么出现故障的最快方式。

Service map：搜索 API 和 Elasticsearch 依赖关系

service map 展示搜索 API 与 Elasticsearch 之间的依赖关系，因此可以很容易地判断延迟问题出现在你的服务中，还是出现在它所依赖的集群中。

所有这些能力在你部署第 2 篇博客中的检测后就立即可用，无需构建任何仪表板或编写任何查询。这就是本文其他所有内容构建于其上的基础。

为搜索定义服务级别目标

SLO 使用可衡量的方式定义什么是_足够好_。你定义什么意味着_正常工作_，持续进行测量，并在错误预算消耗过快时发出告警，而不是等到出现故障后才做出反应。

Elastic Observability 提供内置的 SLO 框架，用于处理服务级别指标（SLI）的计算和预算跟踪。它还负责消耗速率告警。你可以直接在 Kibana 中创建 SLO。核心指标不需要 ES|QL 或自定义 pipeline。

每个搜索服务都需要的三个 SLO

在 Kibana 中进入 Observability > SLOs ，然后点击 Create SLO 。SLO 创建工作流会引导你完成三个步骤：定义 SLI（要测量什么）、设置目标（目标值）以及描述 SLO。

1. 搜索延迟 SLO：99% 的查询低于 250ms

指标类型：Elastic APM 延迟目标：99% 的搜索在 250ms 内完成。

Elastic APM 延迟指标就是专门为此设计的。选择你的搜索服务（search-analytics-demo），并将阈值设置为 250ms。Elastic 会处理其余工作，包括计算低于该阈值的 transaction 百分比，以及持续跟踪你的错误预算。

注意：Elastic APM 延迟指标会测量 search-analytics-demo 服务的所有 HTTP transaction，包括健康检查以及点击、购物车、结账端点，还有静态资源请求，而不仅仅是 POST /api/search 端点。对于仅针对搜索的延迟 SLO，可以在 traces-generic.otel-default 索引上使用自定义 Kibana Query Language（KQL）指标，并设置 name: "search" AND attributes.search.query: *。Elastic APM 指标对于衡量整个服务的健康状况仍然很有价值。为了实现完整覆盖，可以将两者结合使用。

这个指标衡量的是端到端的 span duration，也就是用户实际体验到的延迟。如果你的 Elasticsearch 查询耗时 50ms，但由于网络开销或应用逻辑缓慢，用户需要等待 300ms，那么这个 SLO 就能捕获到这种情况。当 SLO 开始消耗错误预算时，可以使用 Elastic APM waterfall 中的 search.took_ms 来诊断延迟究竟发生在哪里。

2. 搜索可用性 SLO：99.9% 的成功率

指标类型：Elastic APM 可用性

目标：99.9% 的搜索成功。

Elastic APM 可用性指标会计算你的服务中成功 transaction 所占的百分比。当 Elasticsearch 客户端抛出异常，或者搜索端点返回 5xx 时，span 的状态会记录错误，而这个 SLO 会将其计入。

注意：与延迟 SLO 一样，Elastic APM 可用性指标覆盖 search-analytics-demo 上的所有 HTTP transaction，而不仅仅是 POST /api/search。点击、购物车和结账错误都会消耗这一预算。对于仅针对搜索的可用性 SLO，可以使用自定义 KQL 指标，将 name: "search" AND attributes.search.query: * 作为 good events 查询，将 name: "search" 作为 total query。

对于每天 100,000 次搜索，0.1% 的错误预算意味着每天可以容忍 100 个错误。这个标准很严格，但搜索错误属于硬失败，用户什么都得不到。可用性 SLO 应该比延迟 SLO 更严格。

3. 搜索质量 SLO：跟踪零结果率

指标类型：自定义 KQL

目标：85% 的搜索至少返回一个结果（零结果率 < 15%）

索引：traces-generic.otel-default

good 查询： name: "search" AND attributes.search.result_count > 0

total 查询： name: "search" AND attributes.search.query: *

关于 KQL 与 ES|QL：SLO 框架使用 KQL 作为其指标过滤器，而不是 ES|QL。KQL 使用 field: value 语法，这与你在 Kibana 搜索栏中看到的语言相同。本系列中的 ES|QL 查询用于临时分析和仪表板；这里的 KQL 则是 SLO 指标的文档过滤器。两者查询的都是相同的 traces-generic.otel-default 索引。

这是最容易让团队感到意外的 SLO。返回空结果集的搜索并不是错误；HTTP 状态是 200，span 状态也是 OK。而且没有抛出异常。但从用户的角度来看，它失败了。他们搜索了某个内容，却什么都没有得到。

质量 SLO 使用自定义 KQL 指标类型，因为它依赖于我们自定义的 search.result_count 属性，而内置的 Elastic APM 指标并不知道这个属性。但除此之外，SLO 框架会处理所有工作，包括预算跟踪和消耗速率计算，以及告警。

零结果率突然激增，例如在一小时内从 12% 上升到 40%，几乎总是基础设施事件，例如索引部署失败，或者映射变更导致查询失效。也可能是同义词列表配置错误。这属于运维问题，而不是相关性问题。

在 SLO 概览中查看搜索健康状况

创建延迟、可用性和质量 SLO 后，SLO 概览页面会一目了然地展示你的搜索健康状况：

每个 SLO 都会显示当前值、目标值、剩余错误预算和消耗速率。绿色表示_健康_：搜索可用性为 100%，搜索质量刚好高于 85% 的目标值。红色表示_违反目标_：搜索延迟相对于 99% 的目标值仅达到 50%，并且消耗速率已经达到可持续速率的 200 倍，超过了阈值。当预算条开始以快于预期的速度缩短时，即使用户还没有抱怨，你也能知道一定有什么发生了变化。

点击进入 SLO 详情，可以查看多个时间窗口（1h、6h、24h、72h）内的消耗速率，以及历史 SLI 趋势。还可以查看剩余错误预算。对于延迟 SLO，Elastic APM 延迟指标会跟踪低于 250ms 阈值的 transaction 百分比。对于质量 SLO，自定义 KQL 指标使用 traces-generic.otel-default，并通过 good 查询过滤 attributes.search.result_count > 0。这正是第 2 篇博客中的自定义 search.* 属性发挥作用的地方，因为它们是构建有意义的 SLO 的基础。

搜索 SLO 的消耗速率告警

当你通过 Kibana UI 创建 SLO 时，系统会自动创建一个默认的消耗速率告警规则。这才是真正体现其运维价值的地方。

消耗速率告警相比阈值告警（"错误率 > 1%"）进行了改进，后者容易产生噪声，也容易漏掉缓慢的性能下降。消耗速率告警衡量的是相对于 SLO 时间窗口，你消耗错误预算的速度。

消耗速率为 1.0 表示你正好以可持续的速度消耗预算，而消耗速率为 10.0 则表示你的消耗速度快了 10 倍，这意味着你将在窗口的 1/10 时间内耗尽预算。

默认的消耗速率规则采用多时间窗口方式，并包含四个严重级别：

严重级别	消耗速率	长时间窗口	短时间窗口	含义
严重（页面告警）	> 14.4x	1 小时	5 分钟	约 50 小时内耗尽预算
高（工单）	> 6.0x	6 小时	30 分钟	约 5 天内耗尽预算
中（审核）	> 3.0x	24 小时	120 分钟	约 10 天内耗尽预算
低（关注）	> 1.0x	72 小时	360 分钟	呈现预算耗尽趋势

短时间窗口可以避免因短暂且能够自行恢复的峰值而触发告警，而长时间窗口则可以捕获持续的性能下降。两者结合，可以在响应速度和告警疲劳之间取得平衡。

将搜索告警路由到 PagerDuty、Slack 和 Jira

只有将告警发送给正确的人员和正确的工具，告警才有价值。Elastic 的告警框架开箱即用地支持广泛的 connector，包括：

• 事件管理： PagerDuty、Opsgenie、xMatters，用于 on-call 路由。

• 聊天： Slack、Microsoft Teams，用于团队通知。

• 案例管理： Jira、ServiceNow，用于在 SLO 违反目标时自动创建工单。

• 自定义： Webhook，通过 HTTP 与任何系统集成。

你还可以使用 Elastic 内置的 cases，直接在 Kibana 中跟踪事件，将告警和 trace 集中关联到一个位置，并记录调查笔记；如果需要升级，还可以推送到 Jira 或 ServiceNow。

一个典型的路由配置如下：

告警	严重级别	渠道
延迟 SLO 消耗速率 > 14.4	页面告警	PagerDuty
可用性 SLO 消耗速率 > 14.4	页面告警	PagerDuty + Slack
质量 SLO 消耗速率 > 6	工单	Jira（自动创建）+ Slack
CTR 异常（机器学习 ML 作业）	通知	Slack（搜索团队）

使用异常检测监控搜索质量

一些搜索性能下降是逐渐发生的变化，会漏过基于阈值的告警，而不是突然出现峰值。模型更新后的相关性回归可能会导致 CTR 在一周内下降 15%，而随着索引增长，延迟可能每天增加 5ms。这些都是真实的问题，但在触发消耗速率告警之前，往往已经为时过晚。

Elastic 的异常检测正是为此设计的。它会学习搜索指标中的正常模式，并自动标记偏差，而且你不需要配置任何阈值。

使用 ML 异常检测发现搜索质量下降

• 延迟异常：

Elastic APM 异常检测可以直接在 Elastic APM UI 中为你的搜索服务启用。它会学习典型的延迟分布，包括每天和每周的模式，并在行为出现偏差时发出告警。每天逐渐增加 5ms 的延迟最终会被识别为异常，而且会在达到 SLO 阈值之前就被发现。

• CTR 下降：

相关性回归对于传统监控来说是不可见的；延迟正常，错误为零，结果数量也正常，但排序发生了变化，用户不再点击。对每个查询的点击量进行异常检测是一种实用的代理指标：如果某个通常每小时获得 20 次首次点击的查询下降到 5 次，那么很可能发生了变化。

要进行设置：在 Kibana → Machine Learning → Anomaly Detection 中创建一个新的作业。使用 Multi-metric 向导，并选择 traces-generic.otel-default 作为索引。在 attributes.search.first_click 上配置一个 count 检测器，并按照 attributes.search.query 进行拆分。这会为每个查询建立点击量基线，并在单个查询的用户参与度下降到预期范围之外时发出告警。

注意：这个作业检测的是每个查询的点击量异常，而不是 CTR（CTR 需要将点击次数除以搜索次数）。点击量是一个有用的代理指标（CTR 回归通常会表现为绝对点击次数下降），但需要注意，如果流量激增而点击量保持不变，那么 CTR 会下降，却不会触发这个告警。对于真正的 CTR 异常检测，可以使用定时运行的 ES|QL transform，将每小时的 CTR 值物化，然后对计算出的比率运行异常检测。

将生成的 ML 告警规则路由到你的 Slack 搜索频道。

• 吞吐量变化：

搜索量突然下降或意外激增，可能表明上游出现问题（例如负载均衡器发生变化或流量发生转移），也可能是下游出现问题（例如搜索变得无响应或用户不断重试）。

配置 ML 异常告警规则，将这些告警路由到你的通知渠道。它们可以补充 SLO 消耗速率告警；消耗速率告警捕获预算消耗，而异常检测捕获模式变化。

使用 ES|QL 构建搜索监控仪表板

SLO 告诉你搜索是否健康。当它们发现问题时，你需要一个仪表板来告诉你问题为什么发生。

搜索团队和 on-call 团队需要从不同视角查看相同的数据。搜索工程师希望了解查询级别的详细信息，例如哪些查询 CTR 较低，以及哪些查询没有返回任何结果。他们还会关注应该在哪些方面投入精力来提升相关性。而 on-call SRE 更关注运维层面的整体情况，包括搜索是否足够快以及是否正常运行。他们还需要知道搜索是否正在恶化，以及这种情况从什么时候开始。

on-call 仪表板的搜索监控面板

使用 Kibana dashboards 构建仪表板，并使用 Kibana Lens 面板。Lens 支持将ES|QL 作为数据源，因此第 2-4 篇博客中的查询可以直接为仪表板面板提供数据。关键面板包括：

• 随时间变化的搜索吞吐量： 突然下降通常是出现问题的第一个信号。

• 随时间变化的延迟百分位数（p50、p95、p99）： 当它们出现分离时（p50 保持平稳，而 p99 出现峰值），说明有一部分查询速度很慢。

• 随时间变化的错误率： 这里出现峰值意味着发生了硬失败。

• 随时间变化的零结果率： 如果零结果率突然阶跃式上升，尤其是与某次部署相关联，则意味着索引或查询 pipeline 发生了变化。

每个面板使用的 ES|QL 都遵循前面博客中的模式。例如，一个延迟百分位数面板：

`

1.  FROM traces-generic.otel-default
2.  | WHERE name == "search"
3.      AND attributes.search.query IS NOT NULL
4.  | EVAL bucket = DATE_TRUNC(5 minutes, @timestamp)
5.  | STATS
6.      p50 = PERCENTILE(attributes.search.took_ms, 50),
7.      p95 = PERCENTILE(attributes.search.took_ms, 95),
8.      p99 = PERCENTILE(attributes.search.took_ms, 99)
9.  BY bucket
10.  | SORT bucket

`AI写代码![](https://csdnimg.cn/release/blogv2/dist/pc/img/runCode/icon-arrowwhite.png)

这个查询会在同一个图表中显示三条线。当它们出现分离时，例如 p50 保持平稳而 p99 出现峰值，很可能意味着有一部分查询速度很慢，而大多数查询仍然正常。这与所有查询都变慢的情况（集群级压力）属于不同的诊断结果。

深入分析面板：最慢的查询和零结果最多的查询

为了进行调查，可以添加一些详细信息面板，例如：

最慢的查询： 一个显示 p95 延迟最高的查询及其搜索量的表格。在事件发生期间，这可以将问题从"搜索很慢"缩小到"这些特定查询很慢"。

• 零结果最多的查询： 一个显示最频繁返回空结果的查询的表格。当零结果率激增时，这个面板可以立即显示是哪些查询导致了问题。

这些深入分析面板使用与博客 2 和 3 相同的 ES|QL 模式，只是将结果展示在持久化仪表板上，而不是临时运行查询。

使用 OpenTelemetry trace 进行搜索事件响应

举个例子，一个告警触发了，指出搜索延迟出现峰值。现在该怎么办？

博客 2 中 instrumentation 生成的 trace 数据为你提供了一条从症状到根因的结构化路径。

第 1 步：评估影响范围

从 on-call 仪表板开始，先回答一些基本问题：

• 什么时候开始的？ 将时间范围缩小到性能下降的时间窗口。

• 有多严重？ p50 是否受到影响（所有查询都变慢），还是只有 p99 受到影响（只有一部分查询变慢）？

• 只有搜索受到影响吗？ 查看 Elastic APM service map，确定 Elasticsearch 依赖是否也出现了性能下降。

第 2 步：找到有问题的查询

如果问题只影响一部分查询（p99 出现峰值，但 p50 正常），可以使用最慢查询面板，或者运行：

`

1.  FROM traces-generic.otel-default
2.  | WHERE name == "search"
3.      AND attributes.search.query IS NOT NULL
4.      AND attributes.search.took_ms > 100
5.  | STATS
6.      count = COUNT(*),
7.      avg_ms = ROUND(AVG(attributes.search.took_ms), 0),
8.      max_ms = MAX(attributes.search.took_ms)
9.  BY attributes.search.query
10.  | SORT count DESC
11.  | LIMIT 10

`AI写代码![](https://csdnimg.cn/release/blogv2/dist/pc/img/runCode/icon-arrowwhite.png)

根据你环境中的正常范围调整 100 ms 阈值。如果集群速度很快，可以设置得更低；如果你的数据量使得 100ms 属于正常水平，则可以设置得更高。这样可以将问题从"搜索很慢"缩小到"这些特定查询很慢"。这就是重启集群和调查特定查询模式之间的区别。

第 3 步：深入分析 trace waterfall

选择一个慢查询，然后在 Elastic APM trace 视图中打开它。waterfall 会准确显示时间花在哪里。（可以回看上面的 trace waterfall GIF，查看一个真实的 POST /api/search trace 是如何分解为各个组成 span 的。）

search.took_ms（Elasticsearch 时间）与 span duration（端到端时间）之间的开销差距就是你的诊断工具：

场景	search.took_ms	Span duration	诊断
Elasticsearch 慢	400ms	430ms	Elasticsearch 问题：检查 slow log、集群指标。
应用慢	50ms	350ms	应用 / 网络开销：检查序列化、网络。
两者都慢	400ms	700ms	多个问题：同时调查两者。

如果问题出在 Elasticsearch 中，可以深入分析 Search Profile API 或 集群监控。如果是应用开销，则查看 waterfall 中搜索 span 周围的其他 span。

第 4 步：与事件进行关联

检查性能下降是否与以下事件相关：

• 部署： 是否有人部署了新版本的搜索服务，或者推送了新的索引？

• 集群事件： Elasticsearch 是否承受内存压力，或者出现较长的垃圾回收暂停？又或者磁盘是否已经达到 I/O 饱和？

• 网络： 搜索服务与 Elasticsearch 之间的延迟是否有所升高？

Elastic Observability 的统一平台让这种关联变得非常简单，因为 trace、日志、指标和基础设施数据都位于同一个 Kibana 实例中。你可以在同一个界面中添加过滤条件，而不需要在不同工具之间切换。

进一步探索：基础设施指标和成本归因

本文重点介绍从 trace 数据中可以获得什么，也就是你的搜索 API 已经生成的 span。但随着搜索基础设施不断成熟，OTel 和 Elastic Observability 支持更广泛的 instrumentation，这些能力也会变得越来越有价值。

• 基础设施指标。 在 trace 旁边增加主机和容器指标（例如 CPU、内存、磁盘 I/O 和网络），可以让你将搜索性能与基础设施使用情况关联起来。当 p99 延迟出现峰值时，你可以立即看到 Elasticsearch 节点是否承受内存压力，以及垃圾回收暂停是否正在增加。你还可以检查磁盘 I/O 是否已经饱和，而且所有这些操作都可以在同一个 Kibana 界面中完成。Elastic Agent会自动为你的基础设施收集这些指标，而基础设施监控 UI则会将这些指标与 Elastic APM 数据一起展示。

• 总成本归因（TCA）。 当基础设施指标与 trace 一起流入后，你可以开始将基础设施成本归因到特定服务和操作。你的搜索服务消耗了多少计算资源？这与查询量有什么关系？如果新的排序模型使每次查询的 CPU 使用量翻倍，你可以直接看到其成本影响。这对于在云基础设施上运行搜索的团队尤其有价值，因为成本会随着资源消耗而增长；了解每次搜索的成本有助于证明基础设施投入的合理性，并发现优化机会。

• 日志关联。 OTel 自动 instrumentation 会将 trace 上下文（例如 trace ID 和 span ID）注入应用日志中。这意味着，当你在 trace waterfall 中调查一次缓慢的搜索时，可以直接跳转到该请求对应的确切日志行，包括 Elasticsearch slow log 条目和应用调试输出。其中还包含无法放入 span 属性的错误详细信息。日志关联功能会自动将它们关联起来。

一旦 trace 正常运行，这些都是很自然的下一步。每一项能力都扩展了同一个统一平台，而不需要引入新工具或单独的 pipeline。

搜索分析和搜索监控如何共享同一条数据 pipeline

下面展示了它们是如何结合在一起的：

这些数据来自你在第 2 篇博客中构建的 instrumentation。这一项投入可以同时服务两类用户：搜索团队获得产品分析能力（第 2-5 篇博客），SRE 团队获得运维监控能力（本文）。两个团队都不需要单独的数据 pipeline。

开始使用 Elastic 进行搜索监控

这是本系列的最后一篇文章，也让整个系列形成了闭环。第 1 篇博客描述了整体愿景：使用 OTel 对搜索进行一次 instrumentation，然后将 span 发送到 Elastic。接着使用 ES|QL 回答有关搜索行为的任何问题。第 2-4 篇博客构建了 instrumentation 和分析能力，而第 5 篇博客展示了如何将这些数据反馈到相关性改进中。本文则展示了相同的数据如何支持运维监控，包括 SLO、告警、异常检测和事件响应。

对于搜索工程师来说，最重要的结论是：你为分析而构建的 instrumentation 已经生成了所需的信号。SLO 和告警是 Elastic Observability 的内置能力，仪表板也是如此。你距离生产级搜索监控可能比想象中更近。Observability 并不是一门你需要从头开始学习的独立学科。

如果你一直跟随本系列，并且已经按照第 2-4 篇博客构建了 instrumentation，可以从这里开始：

1. 打开 Elastic APM： 查看你的搜索服务，并探索一个 trace waterfall。你也可以检查 Errors 标签页。

2. 创建三个 SLO： 延迟（Elastic APM 延迟）、可用性（Elastic APM 可用性）和质量（针对零结果的自定义 KQL）。

3. 启用异常检测： 在 Elastic APM UI 中点击一次即可启用延迟异常检测。

4. 构建 on-call 仪表板： 使用本文中的查询创建四个 Lens 面板。

经过一个下午的工作，你的搜索服务就可以拥有与其他关键生产系统相同级别的 Observability 覆盖范围。

开始使用

可运行的代码

• 参考项目：整个博客系列的可运行代码；克隆、配置并运行。

Elastic APM 和 trace

• Elastic APM 概览：Elastic APM 概念和 trace 分析。

• Elastic APM UI：服务概览、transaction、依赖关系和错误。

• Service Maps：依赖关系可视化和健康状况。

• OpenTelemetry Integration：在 Elastic 中摄取 OTel 数据。

SLO 和告警

• Elastic Observability 中的 SLO：创建和管理 SLO。

• 创建 SLO：SLI 类型（例如 Elastic APM 延迟、Elastic APM 可用性或自定义 KQL）、时间窗口和预算。

• SLO 消耗速率告警：多时间窗口消耗速率告警。

• 告警 Connector：Slack、PagerDuty、Webhook、电子邮件集成。

• 告警框架：规则类型和配置。

• Jira Connector：从告警自动创建工单。

• ServiceNow Connector：ITSM 集成。

• Elastic Cases：内置事件跟踪，并支持推送到外部系统。

异常检测

• 异常检测概览：无监督时间序列异常检测。

• Elastic APM 异常检测：为延迟、吞吐量和错误率启用 ML。

• ML 异常告警规则：针对检测到的异常进行告警。

仪表板和 ES|QL

• Kibana dashboards：构建运维仪表板。

• Lens：可视化编辑器。

• Lens 中的 ES|QL：由 ES|QL 驱动的仪表板面板。

• ES|QL 概览：语言参考。

Elasticsearch 运维

• Slow Log 配置：基于阈值的查询慢日志记录。

• Search Profiling：用于查询执行分析的 Profile API。

• 监控 Elasticsearch：集群统计信息、搜索速率和延迟。

本系列文章

• 使用 OpenTelemetry 实现现代搜索分析：整体愿景。

• 为你的搜索 API 添加 instrumentation：搜索 span 和 search.* 属性。

• 衡量搜索质量：CTR、MRR、点击分布。

• 从点击到转化：转化跟踪和收入归因。

• 根据行为实现搜索个性化：判断列表、排序特征、Learning To Rank（LTR）。

这是一个关于使用 OpenTelemetry 和 Elastic 进行搜索分析的六篇系列文章中的最后一篇。可以从头开始阅读： 使用 OpenTelemetry 实现现代搜索分析， 或者，如果想直接开始构建，可以跳转到 为你的搜索 API 添加 instrumentation。

原文：Search monitoring with OpenTelemetry: SLOs and alerting | Elasticsearch Labs