作者来自 Elastic Luca Wintergerst一个从你的日志构建的自更新知识库服务、依赖关系和故障模式因此你的 AI Agent 始终知道它们正在查看什么。你的监控系统能看到一切但几乎什么都不理解。在你能够依赖大多数工具触发有意义的告警之前你必须先完成繁重的配置工作明确告诉它们应该监控什么。你必须编写规则、指定“正常”基线应该是什么样子并手动定义你的服务目录。我们正在 Elastic 改变这种局面而第一个重要的基础构建模块现在已经到位一个能够简单地读取你的日志并自行判断其中内容的系统。想想如今告警触发时会发生什么。值班工程师打开调查后前几分钟几乎总是浪费在重建基础事实之上。他们必须弄清楚涉及哪些服务、这些服务之间如何连接、哪些错误模式是典型的以及他们实际上需要运行哪些查询才能进一步深入分析。 AI Agent 也面临完全相同的冷启动问题。如果事先不了解你的系统架构 Agent 必须阅读数百行日志才能建立本应已经存在的基础上下文。这种空白状态是大多数可观测性系统的默认状态。你只知道那些被你显式配置过的内容。当新的服务启动并开始写入日志时它们会一直处于没有规则的状态直到有人花时间去编写规则。当架构依赖关系发生变化时除非你对所有服务都做了极其出色的埋点否则你的拓扑图会悄悄过时。如果某种错误模式每天都在发生但没人编写专门的规则去捕获它那么它将始终不可见。Knowledge Indicators KI 是我们用来弥合这一缺口的方法。当你对日志流运行提取时 Elastic 会分析原始数据并返回关于你环境的结构化事实。它能够识别正在运行的服务、它们依赖的底层基础设施、服务之间的依赖关系以及它们正在使用的日志 Schema 。它甚至会为那些值得告警的条件自动生成一组 ES|QL 查询。与静态配置不同这些知识会随着时间不断积累在服务消失时自动过期并直接提供给下游能力例如 Rules 、拓扑图、 AI Agent 调查以及 Dashboard 。从依赖关系 KI 生成的拓扑图服务节点、依赖边以及检测到的错误条件。提取流水线在设计这个系统时我们的首要目标是消除对先验上下文的需求。不应该存在强制性的 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 latency142ms status200在这里提取过程识别出了实体 fraud-check一个 Spring Boot 服务依赖关系 fraud-check → policy-lookup通过一次出站 HTTP 调用技术 Java 、 Spring Boot从你的日志流中抽取二十条类似这样的日志你很快就能构建出一幅关于系统架构的有效且准确的图景。为了确保这一过程绝不会阻塞数据摄取提取过程完全以后台任务的形式运行。你可以从日志流详情视图或 Significant Events Discovery UI 中按需触发它但我们的目标是让它默认持续运行而无需人工关注。流水线本身会运行多轮迭代每一轮都会获取一小部分文档样本。我们结合使用随机文档与已经被排除的文档以确保能够发现系统的完整范围。在某一轮中发现的 KI 会作为排除条件反馈到下一轮因此每一轮都会专注于前一轮遗漏的内容 —— 从而确保那些更安静、代表性较弱的服务不会被噪声更大的服务淹没。提取流水线带偏置的文档采样输入到一个并行的 LLM 处理流程和四个确定性生成器中。结果在存储前会被合并并去重。一旦完成采样这些文档会被送入一个 LLM 。我们使用一个 system prompt 来指示模型识别几类特定的特征并计划随着时间逐步扩展这些类型类型捕获内容实体独立系统组件服务、应用程序、任务基础设施环境上下文Kubernetes、云提供商、操作系统技术编程语言、框架、库、数据库依赖关系组件之间的关系Schema日志格式规范ECS、OTel、自定义LLM 会返回其发现结果在给出新识别出的特征的同时也会包含被有意忽略的内容例如用户排除的误报。为了被采纳每个 feature 都必须包含稳定的标识属性并引用来自采样日志的直接证据。LLM 还会为每个 KI 分配一个 0–100 的置信度分数以便下游使用该 KI 时能够判断其可信程度。并行地一组基于确定性代码的生成器会独立分析数据生成统计摘要、日志样本、模式聚类以及与错误相关的特征。由于这些结果是通过计算而非推断得到的它们始终被赋予 100 的置信度分数。最后LLM 的结果与计算得到的特征会被合并并去重。已知的 KI 会复用其现有 UUID 新的发现会分配新的 UUID 而用户排除的特征则会在服务端被静默丢弃。最终存活的 KI 会被保存为 active 状态并设置为 7 天后的过期时间。知识指标选项卡显示84个知识指标跨数据流包括类型、置信度1–5星以及数据流列。知识指标包含的内容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用于在多次运行中去重的稳定键值对confidence0–100。由 LLM 识别的 KI 基于证据质量评分确定性 KI 始终为 100evidence2–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.nameapi_gateway http.url/v1/inference peer.serviceinference_service, upstreaminference_service:8080 requestPOST /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 详情面板显示一个服务依赖的 type、subtype、properties、confidence、evidence 和 expiry date。智能可观测性的基础那么我们可以用这些做什么这些 KI 为 Elastic 更高级的能力提供了上下文基础。仅通过这些已提取的 KI我们就可以自动生成活跃的 Rules 来暴露有价值的信号而无需人工工程师编写任何一行配置。关于这一具体能力的更多内容将在本系列的下一篇文章中介绍。由 84 个 KI 自动生成的 85 条 Rules 带有影响评分和事件发生的趋势微图sparkline。作为用户或 Agent 依赖 KI 会自动构建一个基础设施图谱 —— 完全基于日志数据推断而不是依赖分布式追踪或任何手动配置。在发生事故时这个图谱对于评估影响范围blast radius非常关键。如果某个数据库发生故障拓扑图会立即显示哪些上游服务即将受到影响而无需维护手动服务目录。从 KI 中提取的服务依赖图展示服务、数据库以及基础设施组件。这种上下文会改变 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 IndicatorsKnowledge IndicatorsKI是从原始日志流中抽取的结构化事实服务名称、基础设施组件、服务之间的依赖关系以及技术栈信息。Elastic 通过对日志行采样并结合 LLM 推理与确定性生成器自动提取这些信息无需 schema、服务目录或手动配置。Elastic 如何仅通过日志构建服务拓扑图提取流水线会采样日志行并识别依赖关系例如一个服务对另一个服务的 outbound HTTP 调用。这些 dependency KI 被用于构建拓扑图从而展示服务之间的依赖关系完全基于日志推断不依赖分布式追踪或任何人工输入。为什么 AI Agent 在事故调查前需要 Knowledge Indicators如果没有 KIAI 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