作者来自 Elastic Jeffrey Rengifo一个结账服务的 p95 延迟为 582 毫秒而 SLO 目标为 350 毫秒。在 Kibana 的 Discover 中使用一个 KQL 查询即可找到它。要确定哪个团队负责该服务则需要使用一个 ES|QL 查询通过 LOOKUP JOIN 将指标文档与一个小型服务目录索引进行连接。下面将按顺序进行这项调查。一个 数据视图 可以缩小范围而 过滤条件标签 会让这些条件保持可见。当需要其他人重新还原你搜索过的内容时这一点比听起来更加重要。KQL 完成了大部分工作。Lucene 查询语法用于处理唯一一个需要正则表达式的情况而一旦过滤无法继续回答问题就由 ES|QL 接手。前提条件要跟随本文进行操作你需要一个配有 Kibana 的 Elasticsearch 集群。从这里到 ES|QL 部分的所有内容都可以在任何较新的版本上运行LOOKUP JOIN在 Elasticsearch 9.1 中正式发布在 9.0 中属于技术预览因此最后一部分需要使用 9.1 或更高版本。不需要特殊的许可证层级。本文中的所有内容包括LOOKUP JOIN都可以在免费的基础许可证下运行。下一部分创建的两个小型示例索引。为什么生产环境中的结账延迟增加了示例从一个常见的运维问题开始为什么生产环境中的结账延迟增加了以及哪个团队负责这个服务指标索引包含三个区域中四个服务的 15 分钟服务测量数据。其中一个服务checkout-api在调查时间窗口内的us-central1中具有更高的 p95 延迟。目标是从所有指标中找到能够解释这个问题的少量文档。整个操作按照以下步骤进行选择正确的数据视图和时间范围。使用界面过滤条件进行包含、排除、停用和固定条件。使用 KQL 进行主要字段和范围搜索。当正则表达式语法有用时切换到 Lucene。使用带有LOOKUP JOIN的 ES|QL 模式将指标与服务目录数据进行丰富。设置示例指标索引本操作会搜索名为o11y-labs-discover-service-metrics的指标索引。创建该索引时为服务维度使用关键词字段为测量值使用数值字段PUT o11y-labs-discover-service-metrics { mappings: { properties: { timestamp: { type: date }, service: { properties: { name: { type: keyword }, environment: { type: keyword }, version: { type: keyword } } }, cloud: { properties: { region: { type: keyword } } }, host: { properties: { name: { type: keyword } } }, metrics: { properties: { latency: { properties: { p95_ms: { type: float } } }, cpu: { properties: { pct: { type: float } } }, error: { properties: { rate: { type: float } } } } } } } }每个文档代表一个服务在一个区域中的一次 15 分钟测量POST o11y-labs-discover-service-metrics/_bulk { index: {} } { timestamp: 2026-06-30T16:15:00.000Z, service: { name: checkout-api, environment: production, version: 2026.06.30-1 }, cloud: { region: us-central1 }, host: { name: checkout-api-us-central1-01 }, metrics: { latency: { p95_ms: 582.6 }, cpu: { pct: 0.81 }, error: { rate: 0.041 } } } { index: {} } { timestamp: 2026-06-30T16:15:00.000Z, service: { name: payments-api, environment: production, version: 2026.06.29-7 }, cloud: { region: us-central1 }, host: { name: payments-api-us-central1-01 }, metrics: { latency: { p95_ms: 231.4 }, cpu: { pct: 0.31 }, error: { rate: 0.008 } } }为了复现截图请针对每个服务、区域和 15 分钟时间间隔建立一个文档服务checkout-api、checkout-worker、payments-api、inventory-api区域us-central1、us-east4、europe-west1时间窗口2026 年 6 月 30 日 14:00 至 19:45 UTC共 24 个 15 分钟时间间隔每个时间间隔的文档数12 个生产环境文档另外加上两个staging文档checkout-api和payments-api两者都位于us-central1总计24 个时间间隔 × 14 个文档 336 个文档具体数值并不重要只要us-central1中的checkout-api在 15:45 至 18:45 UTC 期间报告的metrics.latency.p95_ms高于 500并且在其他所有时间都稳定低于 500 毫秒即可。你不需要手动建立所有文档可以运行 配套笔记本它会生成完整的 336 个文档数据集创建两个索引并验证最终的 ES|QL 查询。ES|QL 部分还会使用第二个包含四个文档的查找索引用于存储服务目录数据。我们将在进行到那里时创建它。在 Kibana Discover 中选择数据视图数据视图是 Discover 中的第一个过滤条件。它决定要搜索哪些 Elasticsearch 索引、哪个时间字段用于驱动直方图以及左侧字段列表中有哪些可用字段。在本操作中Discover 数据视图指向o11y-labs-discover-service-metrics时间字段是timestamp。这一点很重要因为时间选择器会在你添加查询、过滤条件标签或选择字段之前就先限制文档范围。在条件允许的情况下使用范围较窄的数据视图。例如当你已经知道问题与指标有关时只针对服务指标的数据视图比使用范围较广的logs-*、metrics-*数据视图更容易在 Discover 中快速浏览。选择数据视图后添加支持调查的字段service.nameservice.environmentcloud.regionmetrics.latency.p95_msmetrics.cpu.pctmetrics.error.rateDiscover 中的过滤条件标签包含、排除、停用和固定当你希望看到一个清晰、可编辑的条件列表时界面过滤条件非常有用。当你从文档表格中探索字段并希望 Discover 自动为你生成字段语法时它们也很有帮助。在文档表格中使用字段操作将鼠标悬停在某个值上时出现的 /- 图标来包含或排除该值。例如service.environment: production NOT cloud.region: us-east4 service.version: 2026.06.29-7 (disabled)这三个过滤条件展示了主要的过滤控制方式当你只需要匹配的文档时包含某个值。当某个维度与问题无关时排除某个值。当你想暂时保留某个过滤条件但将其从当前查询中移除时可以暂时停用该过滤条件。当你在不同 Kibana 应用之间切换时如果某个过滤条件应该始终保持生效可以将其固定。固定的过滤条件对于跨应用进行调查非常有用。例如在从 Discover 转到 仪表板、Lens 或其他视图之前你可以固定service.environment: production。停用过滤条件则适合用于验证某个假设同时又不删除引导你进行到这一步的上下文。关键习惯是让过滤条件保持可读。如果一个查询包含很长的搜索表达式以及许多隐藏的假设其他工程师就需要重新推断你的思路。过滤条件标签可以让主要的范围决策清晰可见。用于字段、范围和布尔搜索的 KQL 查询语法KQL即 Kibana 查询语言是 Discover 搜索的一个很好的默认选择。它以易读的形式支持字段名称、精确值、范围、通配符和布尔逻辑。对于结账延迟示例下面这个 KQL 查询会将视图缩小到一个服务、一个区域以及较高的 p95 延迟service.name : checkout-api and cloud.region : us-central1 and metrics.latency.p95_ms 500从左到右阅读service.name : checkout-api保留一个服务。cloud.region : us-central1保留一个云区域。metrics.latency.p95_ms 500保留大于或等于 500 毫秒的延迟样本。你可以在 KQL 中添加环境条件service.environment : production and service.name : checkout-api and cloud.region : us-central1 and metrics.latency.p95_ms 500或者你也可以将service.environment: production保留为界面过滤条件。两种方式都有效。对于需要共享的调查我们更倾向于将稳定的范围条件例如环境和服务作为过滤条件标签而将当前假设例如延迟阈值放在搜索栏中。KQL 也非常适合组合多个字段service.environment : production and (service.name : checkout-api or service.name : payments-api) and metrics.error.rate 0.02当一个面向用户的流程跨越多个服务时这非常有用。你可以在不切换数据视图或先创建仪表板的情况下对一小组服务进行比较。Kibana 中的 Lucene 查询语法使用正则表达式进行搜索Lucene 查询语法是 Kibana 中支持正则表达式的选项。KQL 不支持正则表达式因此当你需要在搜索栏中使用正则表达式时打开搜索栏右侧的查询菜单并将语言切换为Lucene。例如下面这个 Lucene 查询会搜索生产环境中名称以checkout-开头且 p95 延迟高于 500 毫秒的服务service.name:/checkout-.*/ AND service.environment:production AND metrics.latency.p95_ms:500Lucene 语法更加简洁但也更容易被误读。当它能够表达一些你无法用 KQL 清晰表达的内容时可以使用它例如针对某个字段使用正则表达式模式。对于日常的字段、值和范围过滤KQL 通常更容易让团队成员进行审查。如何在 Discover 中使用 ES|QL 的 LOOKUP JOIN 连接两个索引经典的 Discover 模式适合用于搜索、过滤、检查字段以及查看原始文档。Discover 中的 ES|QL 更适合那些需要先进行转换才能让结果变得有用的问题。使用 Discover 工具栏中的使用 ES|QL 查询按钮即可切换模式。在这个示例中原始指标告诉我们checkout-api的延迟很高。但它们无法告诉我们哪个团队负责该服务也无法告诉我们该服务需要达到什么延迟目标。这些数据存储在一个小型的服务目录查找索引中。创建用于服务目录数据的查找索引PUT o11y-labs-service-catalog-lookup { settings: { index.mode: lookup }, mappings: { properties: { service: { properties: { name: { type: keyword } } }, owner: { properties: { team: { type: keyword } } }, slo: { properties: { latency_target_ms: { type: long } } }, runbook: { properties: { url: { type: keyword } } } } } }一个目录文档可以为服务关联负责人信息和 SLO 目标POST o11y-labs-service-catalog-lookup/_doc/checkout-api { service: { name: checkout-api }, owner: { team: checkout-platform }, slo: { latency_target_ms: 350 }, runbook: { url: https://runbooks.example.com/checkout-api/latency } }运行LOOKUP JOIN查询现在Discover 可以使用 ES|QL 查询通过LOOKUP JOIN将指标文档与该目录元数据进行连接。请记住该命令需要 Elasticsearch 9.1 或更高版本查找索引必须使用index.mode: lookup创建并且连接字段这里是service.name必须在查找索引中映射为keyword。FROM o11y-labs-discover-service-metrics | WHERE timestamp 2026-06-30T15:00:00.000Z AND timestamp 2026-06-30T18:45:00.000Z | WHERE service.environment production | LOOKUP JOIN o11y-labs-service-catalog-lookup ON service.name | WHERE owner.team checkout-platform AND metrics.latency.p95_ms slo.latency_target_ms | KEEP timestamp, service.name, cloud.region, metrics.latency.p95_ms, slo.latency_target_ms, owner.team | SORT timestamp DESC这正是经典模式无法覆盖的部分。经典 Discover 可以过滤指标文档但 ES|QL 可以在显示结果之前使用另一个索引中的数据丰富这些行。结果表回答的是一个比最初搜索更加偏向运维的问题。它在一个视图中展示了受影响的服务、区域、延迟值、目标值以及负责该服务的团队。这种模式不仅适用于确定负责人。你可以为服务层级、部署环、升级渠道、业务能力或运行手册 URL 保留小型查找索引。然后在调查时将这些上下文连接到指标搜索中。如何选择正确的 Discover 搜索方式最有用的工作流程并不是对所有内容都使用一种搜索语言而是从宽泛的范围逐步缩小到具体证据。使用场景Discover 功能作用限制可搜索的数据数据视图和时间选择器在查询运行之前移除无关索引和旧文档保持范围可见界面过滤条件让包含、排除、停用和固定的条件易于查看搜索精确字段和值范围KQL让常见的指标搜索保持可读使用正则表达式匹配字段值Lucene 模式当搜索需要正则表达式时提供正则表达式语法丰富或重新组织结果ESQL 模式对于实际调查从仍然包含所需数据的最小数据视图开始。为稳定的范围条件添加过滤条件标签。使用 KQL 进行当前搜索。只有当正则表达式语法值得增加额外复杂度时才切换到 Lucene。当问题需要数据丰富、聚合或重新组织结果时再转向 ES|QL。让指标更容易搜索的字段命名约定当字段名称能够提供足够的上下文时指标搜索效果最佳。上面的示例尽可能使用 Elastic 通用模式 风格的字段service.name用于标识受监控的服务。service.environment用于标识生产、预发布或开发环境。cloud.region用于标识部署区域。host.name用于深入查看主机级别的信息。数值型指标字段位于metrics.*下。你不需要使用完全相同的模式才能使用 Discover但一致且可预测的字段名称会让搜索栏和过滤条件标签更容易使用。它们也能让已保存的搜索和截图在交接过程中更容易理解。对于服务目录数据应保持查找索引小型且稳定。服务负责人、服务层级、SLO 目标和运行手册 URL 等字段的变化频率低于原始指标。这使它们非常适合在分析期间使用LOOKUP JOIN。在你自己的集群上运行整个操作将 Discover 用作深入分析的路径而不仅仅是一个文档表格。在这个操作中我们在编写任何查询之前通过较窄的数据视图和时间选择器限定搜索范围。使用包含、排除、停用和固定的过滤条件标签让调查范围保持可见且易于共享。使用 KQL 进行易读的字段、范围和布尔搜索。只有在 KQL 无法表达正则表达式的情况下才切换到 Lucene。使用 ES|QL 的LOOKUP JOIN从查找索引中获取负责人和 SLO 数据对指标文档进行丰富。如果想在自己的集群上尝试完整流程可以运行配套笔记本它会创建两个索引以及所有示例中使用的故障事件数据。相关文档Discover数据视图过滤KQLLucene 查询语法Discover 中的 ES|QLLOOKUP JOIN相关 Observability Labs 文章在 Discover 中探索新时间序列数据流中的指标在 Elastic Observability 中轻松探索和分析指标在 Discover 中查看追踪数据以深入了解 Elastic Observability 中的应用串联信息使用 ES|QL 连接获得更丰富的可观测性洞察用于 Kubernetes 监控的常见 ES|QL 查询原文Kibana Discover search: KQL, Lucene query syntax, and ES|QL | Elastic Observability Labs
从 582 毫秒的延迟峰值追踪到负责该服务的团队：使用 Kibana Discover
作者来自 Elastic Jeffrey Rengifo一个结账服务的 p95 延迟为 582 毫秒而 SLO 目标为 350 毫秒。在 Kibana 的 Discover 中使用一个 KQL 查询即可找到它。要确定哪个团队负责该服务则需要使用一个 ES|QL 查询通过 LOOKUP JOIN 将指标文档与一个小型服务目录索引进行连接。下面将按顺序进行这项调查。一个 数据视图 可以缩小范围而 过滤条件标签 会让这些条件保持可见。当需要其他人重新还原你搜索过的内容时这一点比听起来更加重要。KQL 完成了大部分工作。Lucene 查询语法用于处理唯一一个需要正则表达式的情况而一旦过滤无法继续回答问题就由 ES|QL 接手。前提条件要跟随本文进行操作你需要一个配有 Kibana 的 Elasticsearch 集群。从这里到 ES|QL 部分的所有内容都可以在任何较新的版本上运行LOOKUP JOIN在 Elasticsearch 9.1 中正式发布在 9.0 中属于技术预览因此最后一部分需要使用 9.1 或更高版本。不需要特殊的许可证层级。本文中的所有内容包括LOOKUP JOIN都可以在免费的基础许可证下运行。下一部分创建的两个小型示例索引。为什么生产环境中的结账延迟增加了示例从一个常见的运维问题开始为什么生产环境中的结账延迟增加了以及哪个团队负责这个服务指标索引包含三个区域中四个服务的 15 分钟服务测量数据。其中一个服务checkout-api在调查时间窗口内的us-central1中具有更高的 p95 延迟。目标是从所有指标中找到能够解释这个问题的少量文档。整个操作按照以下步骤进行选择正确的数据视图和时间范围。使用界面过滤条件进行包含、排除、停用和固定条件。使用 KQL 进行主要字段和范围搜索。当正则表达式语法有用时切换到 Lucene。使用带有LOOKUP JOIN的 ES|QL 模式将指标与服务目录数据进行丰富。设置示例指标索引本操作会搜索名为o11y-labs-discover-service-metrics的指标索引。创建该索引时为服务维度使用关键词字段为测量值使用数值字段PUT o11y-labs-discover-service-metrics { mappings: { properties: { timestamp: { type: date }, service: { properties: { name: { type: keyword }, environment: { type: keyword }, version: { type: keyword } } }, cloud: { properties: { region: { type: keyword } } }, host: { properties: { name: { type: keyword } } }, metrics: { properties: { latency: { properties: { p95_ms: { type: float } } }, cpu: { properties: { pct: { type: float } } }, error: { properties: { rate: { type: float } } } } } } } }每个文档代表一个服务在一个区域中的一次 15 分钟测量POST o11y-labs-discover-service-metrics/_bulk { index: {} } { timestamp: 2026-06-30T16:15:00.000Z, service: { name: checkout-api, environment: production, version: 2026.06.30-1 }, cloud: { region: us-central1 }, host: { name: checkout-api-us-central1-01 }, metrics: { latency: { p95_ms: 582.6 }, cpu: { pct: 0.81 }, error: { rate: 0.041 } } } { index: {} } { timestamp: 2026-06-30T16:15:00.000Z, service: { name: payments-api, environment: production, version: 2026.06.29-7 }, cloud: { region: us-central1 }, host: { name: payments-api-us-central1-01 }, metrics: { latency: { p95_ms: 231.4 }, cpu: { pct: 0.31 }, error: { rate: 0.008 } } }为了复现截图请针对每个服务、区域和 15 分钟时间间隔建立一个文档服务checkout-api、checkout-worker、payments-api、inventory-api区域us-central1、us-east4、europe-west1时间窗口2026 年 6 月 30 日 14:00 至 19:45 UTC共 24 个 15 分钟时间间隔每个时间间隔的文档数12 个生产环境文档另外加上两个staging文档checkout-api和payments-api两者都位于us-central1总计24 个时间间隔 × 14 个文档 336 个文档具体数值并不重要只要us-central1中的checkout-api在 15:45 至 18:45 UTC 期间报告的metrics.latency.p95_ms高于 500并且在其他所有时间都稳定低于 500 毫秒即可。你不需要手动建立所有文档可以运行 配套笔记本它会生成完整的 336 个文档数据集创建两个索引并验证最终的 ES|QL 查询。ES|QL 部分还会使用第二个包含四个文档的查找索引用于存储服务目录数据。我们将在进行到那里时创建它。在 Kibana Discover 中选择数据视图数据视图是 Discover 中的第一个过滤条件。它决定要搜索哪些 Elasticsearch 索引、哪个时间字段用于驱动直方图以及左侧字段列表中有哪些可用字段。在本操作中Discover 数据视图指向o11y-labs-discover-service-metrics时间字段是timestamp。这一点很重要因为时间选择器会在你添加查询、过滤条件标签或选择字段之前就先限制文档范围。在条件允许的情况下使用范围较窄的数据视图。例如当你已经知道问题与指标有关时只针对服务指标的数据视图比使用范围较广的logs-*、metrics-*数据视图更容易在 Discover 中快速浏览。选择数据视图后添加支持调查的字段service.nameservice.environmentcloud.regionmetrics.latency.p95_msmetrics.cpu.pctmetrics.error.rateDiscover 中的过滤条件标签包含、排除、停用和固定当你希望看到一个清晰、可编辑的条件列表时界面过滤条件非常有用。当你从文档表格中探索字段并希望 Discover 自动为你生成字段语法时它们也很有帮助。在文档表格中使用字段操作将鼠标悬停在某个值上时出现的 /- 图标来包含或排除该值。例如service.environment: production NOT cloud.region: us-east4 service.version: 2026.06.29-7 (disabled)这三个过滤条件展示了主要的过滤控制方式当你只需要匹配的文档时包含某个值。当某个维度与问题无关时排除某个值。当你想暂时保留某个过滤条件但将其从当前查询中移除时可以暂时停用该过滤条件。当你在不同 Kibana 应用之间切换时如果某个过滤条件应该始终保持生效可以将其固定。固定的过滤条件对于跨应用进行调查非常有用。例如在从 Discover 转到 仪表板、Lens 或其他视图之前你可以固定service.environment: production。停用过滤条件则适合用于验证某个假设同时又不删除引导你进行到这一步的上下文。关键习惯是让过滤条件保持可读。如果一个查询包含很长的搜索表达式以及许多隐藏的假设其他工程师就需要重新推断你的思路。过滤条件标签可以让主要的范围决策清晰可见。用于字段、范围和布尔搜索的 KQL 查询语法KQL即 Kibana 查询语言是 Discover 搜索的一个很好的默认选择。它以易读的形式支持字段名称、精确值、范围、通配符和布尔逻辑。对于结账延迟示例下面这个 KQL 查询会将视图缩小到一个服务、一个区域以及较高的 p95 延迟service.name : checkout-api and cloud.region : us-central1 and metrics.latency.p95_ms 500从左到右阅读service.name : checkout-api保留一个服务。cloud.region : us-central1保留一个云区域。metrics.latency.p95_ms 500保留大于或等于 500 毫秒的延迟样本。你可以在 KQL 中添加环境条件service.environment : production and service.name : checkout-api and cloud.region : us-central1 and metrics.latency.p95_ms 500或者你也可以将service.environment: production保留为界面过滤条件。两种方式都有效。对于需要共享的调查我们更倾向于将稳定的范围条件例如环境和服务作为过滤条件标签而将当前假设例如延迟阈值放在搜索栏中。KQL 也非常适合组合多个字段service.environment : production and (service.name : checkout-api or service.name : payments-api) and metrics.error.rate 0.02当一个面向用户的流程跨越多个服务时这非常有用。你可以在不切换数据视图或先创建仪表板的情况下对一小组服务进行比较。Kibana 中的 Lucene 查询语法使用正则表达式进行搜索Lucene 查询语法是 Kibana 中支持正则表达式的选项。KQL 不支持正则表达式因此当你需要在搜索栏中使用正则表达式时打开搜索栏右侧的查询菜单并将语言切换为Lucene。例如下面这个 Lucene 查询会搜索生产环境中名称以checkout-开头且 p95 延迟高于 500 毫秒的服务service.name:/checkout-.*/ AND service.environment:production AND metrics.latency.p95_ms:500Lucene 语法更加简洁但也更容易被误读。当它能够表达一些你无法用 KQL 清晰表达的内容时可以使用它例如针对某个字段使用正则表达式模式。对于日常的字段、值和范围过滤KQL 通常更容易让团队成员进行审查。如何在 Discover 中使用 ES|QL 的 LOOKUP JOIN 连接两个索引经典的 Discover 模式适合用于搜索、过滤、检查字段以及查看原始文档。Discover 中的 ES|QL 更适合那些需要先进行转换才能让结果变得有用的问题。使用 Discover 工具栏中的使用 ES|QL 查询按钮即可切换模式。在这个示例中原始指标告诉我们checkout-api的延迟很高。但它们无法告诉我们哪个团队负责该服务也无法告诉我们该服务需要达到什么延迟目标。这些数据存储在一个小型的服务目录查找索引中。创建用于服务目录数据的查找索引PUT o11y-labs-service-catalog-lookup { settings: { index.mode: lookup }, mappings: { properties: { service: { properties: { name: { type: keyword } } }, owner: { properties: { team: { type: keyword } } }, slo: { properties: { latency_target_ms: { type: long } } }, runbook: { properties: { url: { type: keyword } } } } } }一个目录文档可以为服务关联负责人信息和 SLO 目标POST o11y-labs-service-catalog-lookup/_doc/checkout-api { service: { name: checkout-api }, owner: { team: checkout-platform }, slo: { latency_target_ms: 350 }, runbook: { url: https://runbooks.example.com/checkout-api/latency } }运行LOOKUP JOIN查询现在Discover 可以使用 ES|QL 查询通过LOOKUP JOIN将指标文档与该目录元数据进行连接。请记住该命令需要 Elasticsearch 9.1 或更高版本查找索引必须使用index.mode: lookup创建并且连接字段这里是service.name必须在查找索引中映射为keyword。FROM o11y-labs-discover-service-metrics | WHERE timestamp 2026-06-30T15:00:00.000Z AND timestamp 2026-06-30T18:45:00.000Z | WHERE service.environment production | LOOKUP JOIN o11y-labs-service-catalog-lookup ON service.name | WHERE owner.team checkout-platform AND metrics.latency.p95_ms slo.latency_target_ms | KEEP timestamp, service.name, cloud.region, metrics.latency.p95_ms, slo.latency_target_ms, owner.team | SORT timestamp DESC这正是经典模式无法覆盖的部分。经典 Discover 可以过滤指标文档但 ES|QL 可以在显示结果之前使用另一个索引中的数据丰富这些行。结果表回答的是一个比最初搜索更加偏向运维的问题。它在一个视图中展示了受影响的服务、区域、延迟值、目标值以及负责该服务的团队。这种模式不仅适用于确定负责人。你可以为服务层级、部署环、升级渠道、业务能力或运行手册 URL 保留小型查找索引。然后在调查时将这些上下文连接到指标搜索中。如何选择正确的 Discover 搜索方式最有用的工作流程并不是对所有内容都使用一种搜索语言而是从宽泛的范围逐步缩小到具体证据。使用场景Discover 功能作用限制可搜索的数据数据视图和时间选择器在查询运行之前移除无关索引和旧文档保持范围可见界面过滤条件让包含、排除、停用和固定的条件易于查看搜索精确字段和值范围KQL让常见的指标搜索保持可读使用正则表达式匹配字段值Lucene 模式当搜索需要正则表达式时提供正则表达式语法丰富或重新组织结果ESQL 模式对于实际调查从仍然包含所需数据的最小数据视图开始。为稳定的范围条件添加过滤条件标签。使用 KQL 进行当前搜索。只有当正则表达式语法值得增加额外复杂度时才切换到 Lucene。当问题需要数据丰富、聚合或重新组织结果时再转向 ES|QL。让指标更容易搜索的字段命名约定当字段名称能够提供足够的上下文时指标搜索效果最佳。上面的示例尽可能使用 Elastic 通用模式 风格的字段service.name用于标识受监控的服务。service.environment用于标识生产、预发布或开发环境。cloud.region用于标识部署区域。host.name用于深入查看主机级别的信息。数值型指标字段位于metrics.*下。你不需要使用完全相同的模式才能使用 Discover但一致且可预测的字段名称会让搜索栏和过滤条件标签更容易使用。它们也能让已保存的搜索和截图在交接过程中更容易理解。对于服务目录数据应保持查找索引小型且稳定。服务负责人、服务层级、SLO 目标和运行手册 URL 等字段的变化频率低于原始指标。这使它们非常适合在分析期间使用LOOKUP JOIN。在你自己的集群上运行整个操作将 Discover 用作深入分析的路径而不仅仅是一个文档表格。在这个操作中我们在编写任何查询之前通过较窄的数据视图和时间选择器限定搜索范围。使用包含、排除、停用和固定的过滤条件标签让调查范围保持可见且易于共享。使用 KQL 进行易读的字段、范围和布尔搜索。只有在 KQL 无法表达正则表达式的情况下才切换到 Lucene。使用 ES|QL 的LOOKUP JOIN从查找索引中获取负责人和 SLO 数据对指标文档进行丰富。如果想在自己的集群上尝试完整流程可以运行配套笔记本它会创建两个索引以及所有示例中使用的故障事件数据。相关文档Discover数据视图过滤KQLLucene 查询语法Discover 中的 ES|QLLOOKUP JOIN相关 Observability Labs 文章在 Discover 中探索新时间序列数据流中的指标在 Elastic Observability 中轻松探索和分析指标在 Discover 中查看追踪数据以深入了解 Elastic Observability 中的应用串联信息使用 ES|QL 连接获得更丰富的可观测性洞察用于 Kubernetes 监控的常见 ES|QL 查询原文Kibana Discover search: KQL, Lucene query syntax, and ES|QL | Elastic Observability Labs
