从原始日志到系统知识： AI 上下文层可观测性正在缺失

作者：来自 Elastic Luca Wintergerst

一个从你的日志构建的自更新知识库：服务、依赖关系和故障模式，因此你的 AI Agent 始终知道它们正在查看什么。

你的监控系统能看到一切，但几乎什么都不理解。

在你能够依赖大多数工具触发有意义的告警之前，你必须先完成繁重的配置工作，明确告诉它们应该监控什么。你必须编写规则、指定“正常”基线应该是什么样子，并手动定义你的服务目录。我们正在 Elastic 改变这种局面，而第一个重要的基础构建模块现在已经到位：一个能够简单地读取你的日志，并自行判断其中内容的系统。

想想如今告警触发时会发生什么。值班工程师打开调查后，前几分钟几乎总是浪费在重建基础事实之上。他们必须弄清楚涉及哪些服务、这些服务之间如何连接、哪些错误模式是典型的，以及他们实际上需要运行哪些查询才能进一步深入分析。 AI Agent 也面临完全相同的冷启动问题。如果事先不了解你的系统架构， Agent 必须阅读数百行日志，才能建立本应已经存在的基础上下文。

这种空白状态是大多数可观测性系统的默认状态。你只知道那些被你显式配置过的内容。当新的服务启动并开始写入日志时，它们会一直处于没有规则的状态，直到有人花时间去编写规则。当架构依赖关系发生变化时，除非你对所有服务都做了极其出色的埋点，否则你的拓扑图会悄悄过时。如果某种错误模式每天都在发生，但没人编写专门的规则去捕获它，那么它将始终不可见。

Knowledge Indicators（ KI ）是我们用来弥合这一缺口的方法。当你对日志流运行提取时， Elastic 会分析原始数据，并返回关于你环境的结构化事实。它能够识别正在运行的服务、它们依赖的底层基础设施、服务之间的依赖关系，以及它们正在使用的日志 Schema 。它甚至会为那些值得告警的条件自动生成一组 ES|QL 查询。与静态配置不同，这些知识会随着时间不断积累，在服务消失时自动过期，并直接提供给下游能力，例如 Rules 、拓扑图、 AI Agent 调查以及 Dashboard 。

提取流水线

在设计这个系统时，我们的首要目标是消除对先验上下文的需求。不应该存在强制性的 Schema 、与特定属性绑定的服务目录，或任何需要维护的预定义静态资产。我们问了自己一个简单的问题：如果你把一份原始日志样本交给一个从未见过该系统的工程师，他们仅仅通过查看日志，能够推断出什么？

这个思想实验最终成为了我们的核心方法。系统会从日志流中抽取一小批日志，通过 LLM 分析与确定性代码生成器的组合进行处理，并在多轮处理中持续累积发现结果，整个过程完全无需配置。

想象一下，你雇佣了一屋子的初级 SRE ，他们只有一个明确任务：阅读这些日志行并汇报他们的观察结果，而不是修复问题或触发告警，只是去 “注意到” 一些事情。“这看起来像是一个 nginx 服务器”，或者 “这个数据库是 PostgreSQL ”，又或者 “服务 A 正在通过 HTTP 调用服务 B ”。本质上，我们的提取任务就是在你的日志流中持续执行这样的工作。

为了看看它在实践中如何工作，来看下面这条来自 nginx 访问日志的单行记录：

192.168.1.45 - - [31/Mar/2026:14:23:01 +0000] "POST /api/v2/claims HTTP/1.1" 200 1247 "-" "claim-intake/1.4.2"

仅仅从这条字符串中，流水线就能提取出三个不同的事实：

• 实体：claim-intake（可从 User-Agent 识别为一个服务）
• 版本： 1.4.2（从 User-Agent 字符串中提取）
• 技术： nginx（处理该请求的 Web 服务器）
• Schema： Combined Log Format

类似地，再来看下面这条 Java 服务日志：

2026-03-31T14:23:03.412Z INFO fraud-check --- [nio-8080-exec-3] c.e.FraudCheckService : Calling upstream POST http://policy-lookup:8081/v1/policy latency=142ms status=200

在这里，提取过程识别出了：

• 实体： fraud-check（一个 Spring Boot 服务）
• 依赖关系： fraud-check → policy-lookup（通过一次出站 HTTP 调用）
• 技术： Java 、 Spring Boot

从你的日志流中抽取二十条类似这样的日志，你很快就能构建出一幅关于系统架构的有效且准确的图景。

为了确保这一过程绝不会阻塞数据摄取，提取过程完全以后台任务的形式运行。你可以从日志流详情视图或 Significant Events Discovery UI 中按需触发它，但我们的目标是让它默认持续运行，而无需人工关注。

流水线本身会运行多轮迭代，每一轮都会获取一小部分文档样本。我们结合使用随机文档与已经被排除的文档，以确保能够发现系统的完整范围。在某一轮中发现的 KI 会作为排除条件反馈到下一轮，因此每一轮都会专注于前一轮遗漏的内容 —— 从而确保那些更安静、代表性较弱的服务不会被噪声更大的服务淹没。

一旦完成采样，这些文档会被送入一个 LLM 。我们使用一个 system prompt 来指示模型识别几类特定的特征，并计划随着时间逐步扩展这些类型：

LLM 会返回其发现结果，在给出新识别出的特征的同时，也会包含被有意忽略的内容（例如用户排除的误报）。为了被采纳，每个 feature 都必须包含稳定的标识属性，并引用来自采样日志的直接证据。LLM 还会为每个 KI 分配一个 0–100 的置信度分数，以便下游使用该 KI 时能够判断其可信程度。

并行地，一组基于确定性代码的生成器会独立分析数据，生成统计摘要、日志样本、模式聚类以及与错误相关的特征。由于这些结果是通过计算而非推断得到的，它们始终被赋予 100 的置信度分数。

最后，LLM 的结果与计算得到的特征会被合并并去重。已知的 KI 会复用其现有 UUID ，新的发现会分配新的 UUID ，而用户排除的特征则会在服务端被静默丢弃。最终存活的 KI 会被保存为 active 状态，并设置为 7 天后的过期时间。

知识指标包含的内容

Knowledge Indicators 分为两类：Feature KI和Query KI。

Feature KI 是描述性的。它用于解释数据流的内容：有哪些服务在运行、它们所在的基础设施、它们之间的依赖关系，以及当前使用的技术栈。

Query KI 是可执行的。它们是已经准备好的 ES|QL 查询，用于定位显著条件，例如连接耗尽、内存不足（ out-of-memory ）错误或致命异常。每个 Query KI 都带有 0 到 100 的严重性分数，当它被提升为 Rules 时，就会触发 Event 。

Feature KI 包含完整的数据模型：

• type / subtype：事实类别（ Entity、Infrastructure、Technology、Dependency、Schema ）
• title / description：人类可读的摘要
• properties：用于在多次运行中去重的稳定键值对
• confidence：0–100。由 LLM 识别的 KI 基于证据质量评分；确定性 KI 始终为 100
• evidence：2–5 条支持该 KI 的日志片段，用于证明其存在
• filter：可选的 StreamLang 条件，用于将 KI 限定在特定文档范围内

一个 dependency KI 看起来如下：

{ "type": "dependency", "subtype": "service_dependency", "title": "api_gateway → inference_service", "description": "Service-to-service HTTP dependency from api_gateway to inference_service, observed in request logs", "properties": { "source": "api_gateway", "target": "inference_service", "protocol": "http" }, "confidence": 85, "evidence": [ "service.name=api_gateway http.url=/v1/inference peer.service=inference_service", "upstream=inference_service:8080 request=POST /v1/inference 200" ], "filter": { "field": "service.name", "eq": "api_gateway" }, "status": "active", "expires_at": "2026-04-09T00:00:00Z" }

Query KI 采用更简单的结构，只包含标题、严重性分数以及可执行查询：

{ "kind": "query", "title": "PostgreSQL connection slot exhaustion", "description": "Fires when Postgres runs out of available connection slots", "severity_score": 90, "esql": { "query": "FROM logs-* | WHERE service.name == \"postgres\" AND message : \"remaining connection slots\"" } }

properties 字段是保证 Feature KIs 在多次流水线运行中保持稳定的关键。对于 api_gateway → inference_service 的 dependency KI，它会将 source、target 和 protocol 记录为固定的键值对。下一次提取运行时，Elastic 会识别出这条已存在的关系，并更新该 KI 的 last_seen 时间戳，而不是创建重复项。

智能可观测性的基础

那么，我们可以用这些做什么？

这些 KI 为 Elastic 更高级的能力提供了上下文基础。仅通过这些已提取的 KI，我们就可以自动生成活跃的 Rules 来暴露有价值的信号，而无需人工工程师编写任何一行配置。关于这一具体能力的更多内容，将在本系列的下一篇文章中介绍。

作为用户或 Agent ，依赖 KI 会自动构建一个基础设施图谱 —— 完全基于日志数据推断，而不是依赖分布式追踪或任何手动配置。在发生事故时，这个图谱对于评估影响范围（blast radius）非常关键。如果某个数据库发生故障，拓扑图会立即显示哪些上游服务即将受到影响，而无需维护手动服务目录。

这种上下文会改变 AI Agent 处理事故的方式。Agent 不再从零开始，而是基于系统的真实拓扑结构和已知故障模式来启动调查。借助 KI，它能够识别相关的数据流，运行适用的查询，并形成具体假设。在我们的例子中，它已经知道 api_gateway 依赖 inference_service，并且知道连接槽耗尽是你的 Postgres 实例中的一种高严重性故障模式。

这种抽取出的知识并不需要完美也依然有用。由于 LLM 本身具有非确定性，一个 KI 偶尔可能略有偏差，但它仍然能为 Agent 提供显著的起点优势。Agent 可以将 KI 与实时日志进行交叉验证，并在运行过程中自我修正。真正的价值在于，在关键故障期间无需重新构建基础事实。KI 还会驱动 AI 生成的仪表盘建议，并在引入新数据流时影响 Grok 模式生成。

自清理与可扩展性

维护这个知识库是完全无需人工干预的。如果某个 KI 在后续提取运行中未被再次观测到，它会在 7 天后自动过期。如果你下线某个服务，其相关 KI 会自然消失，无需手动清理；当服务重新上线时，KI 会再次被重新提取。用户也可以将单个 Feature KI 标记为误报，系统会将这些排除条件带入未来运行，避免再次识别。

由于我们将 KI 提取限定为一个特定的分类任务（通过约 20 条日志样本识别服务、基础设施和依赖关系），它并不需要大型前沿模型即可运行。一个快速且成本友好的模型就能完成，而不需要多步推理。

你不应该被迫去告诉工具“应该监控什么”。

可观测性的根本承诺，是帮助你理解你的系统。而在过去很长一段时间里，把系统真实运行方式 “教给工具” 的负担，一直落在了运维工程师身上。

本系列的下一篇文章将讨论 Agent 如何使用这些上下文：为什么每一个在没有 KI 的情况下调查系统的 Agent，都会在每次事故中从头重新学习同样的东西，以及当它不再需要这样做时会发生什么变化。

注意：这些能力在 Serverless Observability 项目中通过 feature flag 提供。在 Kibana 的 advanced settings 页面中搜索 observability:streamsEnableSignificantEvents 即可开启。

常见问题

什么是 Elasticsearch Streams 中的 Knowledge Indicators？
Knowledge Indicators（KI）是从原始日志流中抽取的结构化事实：服务名称、基础设施组件、服务之间的依赖关系以及技术栈信息。Elastic 通过对日志行采样，并结合 LLM 推理与确定性生成器自动提取这些信息，无需 schema、服务目录或手动配置。

Elastic 如何仅通过日志构建服务拓扑图？
提取流水线会采样日志行，并识别依赖关系，例如一个服务对另一个服务的 outbound HTTP 调用。这些 dependency KI 被用于构建拓扑图，从而展示服务之间的依赖关系，完全基于日志推断，不依赖分布式追踪或任何人工输入。

为什么 AI Agent 在事故调查前需要 Knowledge Indicators？
如果没有 KI，AI Agent 每次调查都必须从零开始：读取数百行日志才能搞清楚有哪些服务以及它们之间如何关联。而 KI 提供了一个预构建的系统地图，包括服务、已知故障模式和相关查询，使 Agent 可以立即开始针对实际事故进行推理。

我需要配置什么才能让 KI 提取生效吗？
不需要。整个流水线不依赖 schema 定义、服务目录或预定义规则。它从日志流中采样少量数据，通过 LLM 推理和确定性生成器分析，并自动累积结果。

LLM 提取的 KI 和计算生成的 KI 准确性如何？
计算（确定性）KI 的置信度始终为 100，因为它基于统计分析而非推断。LLM 提取的 KI 会根据日志证据质量给出 0–100 的置信度分数。Rules、Agent 调查以及拓扑图都会使用该分数进行加权判断。

当服务下线时会发生什么？
KI 的有效期为 7 天。如果某个服务在后续提取运行中不再出现，其 KI 会自动过期并删除，无需人工清理。如果服务重新上线，KI 会在下一次运行中重新被提取。

它和分布式追踪的服务发现有什么区别？
分布式追踪依赖已埋点的服务和 trace collector。而 KI 提取不需要任何 SDK、agent 或 schema，仅依赖现有日志流。在没有或部分缺失 tracing 的环境中，KI 仍然可以提供拓扑与依赖信息，而 tracing 则无法覆盖这些场景。

原文：https://www.elastic.co/observability-labs/blog/elastic-knowledge-indicators-log-extraction