从原始日志到系统知识：补齐 AI 可观测性的“上下文层“

👍：你的监控系统"看见"了一切，却"理解"得很少。我们能否让系统自己阅读日志、自动构建知识，从而让 AI 代理在排查故障时不再从零开始？

第一章： AI 代理总在"冷启动"

1.1 监控看见了，但没看懂

今天的可观测性工具存在一个根本性矛盾：它们采集了海量数据，却缺乏对数据的语义理解。

当一条告警触发时，值班工程师的典型工作流是这样的：

收到告警通知
打开日志流，开始阅读原始日志
前 5-10 分钟：纯手动重建基础事实------这到底是什么服务？它依赖谁？什么错误模式是正常的？该查哪些指标？
最后才开始真正的根因分析

这个"冷启动"问题，人类工程师在每次排障时都要经历一次。而 AI 代理面临的是完全相同的困境：如果没有对系统架构的预先了解，它也必须从数百行日志中逐行推断基础上下文。

1.2 空白画板的代价

大多数可观测性平台的默认状态是一张空白画板------你只知道你明确配置过的东西：

场景	现状
新服务上线并开始写日志	没有规则监控它，直到有人手动配置
架构依赖关系发生变化	拓扑图默默过时，除非你做了极致的埋点
某种错误模式每天发生	没人写特定规则，它就保持"不可见"

本质矛盾：工程师被迫"教"工具自己的系统长什么样，而不是工具自己学会理解。
传统可观测性
原始日志流
工程师手动配置
规则/告警/拓扑
AI代理/值班人员
每次从零重建上下文
知识指标 KI
原始日志流
自动提取知识指标
自更新知识库
AI代理/值班人员
自带上下文开始排查

第二章：Knowledge Indicators

2.1 知识指标（KI）

Knowledge Indicators（知识指标，简称 KI） 是 Elastic 提出的解决方案：对日志流运行提取作业后，系统自动分析原始数据，返回关于你环境的结构化事实。

它能识别：

哪些服务正在运行
底层基础设施是什么（Kubernetes、云平台、操作系统）
服务间如何依赖
使用的日志 Schema（ECS、OTel、自定义格式）
值得关注的查询条件（自动生成 ES|QL 查询）

这不是静态配置，而是一个自更新、自过期的知识库，直接为下游能力（规则、拓扑图、AI 代理排查、仪表板）提供燃料。

2.2 从日志中读出的架构图

以下是一个由依赖型 KI 自动生成的拓扑图示例：
HTTP 200
查询请求
POST /api/v2/claims
调用上游
数据存取
查询
📝 claim-intake

索赔受理服务
🔍 fraud-check

欺诈检测服务
📋 policy-lookup

保单查询服务
🐘 claim-intake-db

PostgreSQL
🍃 fraud-check-db

MongoDB
🐘 policy-lookup-db

PostgreSQL
💳 payment-processor

支付处理
📨 kafka

消息队列
📧 notification-dispatch

通知分发
☸️ kubernetes

基础设施

这张图完全从日志推断，不依赖分布式追踪，也不需要人工维护服务目录。

第三章：提取流水线------零配置的知识发现

3.1 设计哲学：像新人工程师一样阅读日志

设计这个系统时，核心目标是消除对先验上下文的需求：

没有强制 Schema
没有绑定特定属性的服务目录
没有需要维护的预定义静态资产

我们问自己一个简单问题：如果你把一份原始日志样本交给一个从未见过这个系统的工程师，他仅凭阅读能推断出什么？

这个思想实验成了系统的核心方法。

3.2 流水线工作原理

想象你雇了一屋子的初级 SRE，只给他们一个任务：阅读这些日志行并报告观察结果------不是修复问题，也不是触发告警，只是注意到事情：

"这看起来像是 nginx 服务器"
"这个数据库是 PostgreSQL"
"服务 A 正在通过 HTTP 调用服务 B"

这就是提取作业在你的日志流上持续做的事情。

示例 1：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	字段结构

示例 2：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

从日志流中抽取 20 行这样的记录，你就能快速构建出系统架构的准确画像。

3.3 提取流水线架构

📦 输出存储
🔄 合并与去重
⚙️ 并行处理
🎲 三池偏置采样
输入层
📄 原始日志流
实体过滤采样

聚焦已知服务
多样性采样

发现新内容
随机采样

保证覆盖
🤖 LLM 分析

finalize_features
🔢 统计摘要生成器
📊 日志样本聚类
🔍 模式识别引擎
⚠️ 错误特征提取器
合并 LLM + 计算结果
去重：已知 KI 复用 UUID
排除用户标记的误报
新发现分配新 UUID
84 个 KI 存入知识库
设置 7 天过期时间
状态：active

3.4 关键设计细节

不阻塞写入：提取完全作为后台任务运行。你可以按需触发，但目标是默认自动运行、无需关注。

多轮迭代发现：

每轮获取少量文档样本
混合使用随机采样和"已排除"文档，确保发现系统的完整范围
上一轮发现的 KI 会作为排除项反馈到下一轮，确保安静、代表性低的服务不会被噪音大的服务淹没

LLM 与确定性计算并行：

分析路径	处理方式	置信度
LLM 分析	识别实体、基础设施、技术栈、依赖、Schema	0-100（基于证据质量）
统计生成器	统计摘要	100（确定性计算）
日志聚类	模式聚类	100
错误提取器	错误特定特征	100

置信度机制：LLM 为每个 KI 分配 0-100 的置信度分数，下游使用者可以据此判断信任程度。确定性计算的 KI 始终为 100 分。

第四章：KI 的内部结构------它到底包含什么

4.1 两大类别

知识指标分为两类：
Knowledge Indicators

知识指标
Feature KIs

描述型
Query KIs

行动型
实体：服务、应用、任务
基础设施：K8s、云厂商、OS
技术栈：语言、框架、数据库
依赖关系：组件间连接
Schema：日志格式约定
可执行的 ES|QL 查询
严重程度评分 0-100
可提升为自动告警规则

4.2 Feature KI 完整数据模型

每个描述型 KI 携带完整的数据结构：

字段	说明
`type / subtype`	事实类别（实体、基础设施、技术、依赖、Schema）
`title / description`	人类可读的摘要
`properties`	稳定的键值对，用于多轮运行间去重
`confidence`	0-100。LLM 识别的基于证据质量；确定性计算始终为 100
`evidence`	2-5 条支持性日志摘录，证明 KI 的存在
`filter`	可选的 StreamLang 条件，限定 KI 适用的文档范围
`status`	当前状态（active）
`expires_at`	7 天后过期时间

依赖型 KI 示例

json 复制代码

{
  "type": "dependency",
  "subtype": "service_dependency",
  "title": "api_gateway → inference_service",
  "description": "服务间 HTTP 依赖，从 api_gateway 到 inference_service，在请求日志中观察到",
  "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"
}

properties 字段是稳定性的关键。api_gateway → inference_service 的依赖关系记录了 source、target、protocol 作为固定键值对。下次提取运行时，Elastic 会识别这是已有关系，只更新 last_seen 时间戳，而不会创建重复项。

4.3 Query KI 结构

查询型 KI 更精简，聚焦可执行性：

json 复制代码

{
  "kind": "query",
  "title": "PostgreSQL 连接槽耗尽",
  "description": "当 Postgres 耗尽可用连接槽时触发",
  "severity_score": 90,
  "esql": {
    "query": "FROM logs-* | WHERE service.name == "postgres" AND message : "remaining connection slots""
  }
}

第五章：智能可观测性的基石------KI 能做什么

5.1 自动生成告警规则

从提取的 KI 中，系统可以自动生成活跃的规则来呈现有趣信号------无需人类工程师写一行配置。
自动转换
84 个 KI

知识指标
85 条自动规则
🔴 Critical

严重
🟠 High

高优先级
🟡 Medium

中优先级
事件频率趋势图
事件频率趋势图

5.2 自动构建基础设施拓扑图

依赖型 KI 自动构建基础设施图------完全从日志数据推断，不依赖分布式追踪或任何手动配置。

在事故期间，这张图对评估爆炸半径 invaluable：

如果特定数据库宕机，拓扑图立即显示哪些上游服务即将失败
无需维护手动服务目录

💥 爆炸半径分析示例
连接槽耗尽
查询超时
数据不可读
级联失败
级联失败
级联失败
🐘 PostgreSQL

主数据库
📋 policy-lookup

保单查询
🔍 fraud-check

欺诈检测
📝 claim-intake

索赔受理
🌐 api_gateway

网关

5.3 AI 代理的上下文革命

这是 KI 改变游戏规则的地方。没有 KI 时，AI 代理的调查流程是：
✅ 有 KI：自带上下文
告警触发
读取预构建知识库
已知：api_gateway 依赖 inference_service
已知：连接槽耗尽是高危失败模式
已知：相关日志流和查询
直接提出精准假设
❌ 没有 KI：每次从零开始
告警触发
阅读数百行日志
推断服务名称
推断依赖关系
推断错误模式
构建查询
提出假设

关键差异：

AI 代理不再从空白画板开始
它使用系统的实际拓扑和已知失败模式启动调查
基于 KI，它识别相关流、运行适用查询、制定具体假设
即使 KI 偶尔不完全准确（LLM 固有非确定性），代理也可以对照实时日志交叉验证并自我纠正

真正的好处：在关键故障期间，不必再花时间重建基础事实。

5.4 其他下游应用

AI 生成仪表板建议：基于 KI 自动推荐监控面板布局
Grok 模式生成：引入新日志流时，自动生成解析模式

第六章：自清洁与可扩展性------无人值守的知识维护

6.1 自动过期机制

维护这个知识库完全是免手动的：
误报处理
用户标记误报
加入排除列表
未来运行自动跳过
KI 生命周期
再次发现
7天未出现
服务重新上线
发现
激活

7天有效期
持续观察
🗑️ 自动过期

场景	系统行为
服务下线超过 7 天	相关 KI 自动过期，无需手动清理
服务重新上线	KI 被重新提取，自动恢复
用户标记误报	系统记住排除项，未来运行不再识别
架构关系变化	旧关系过期，新关系自动发现

6.2 成本与性能优化

因为我们将 KI 提取限定为特定的分类任务（看约 20 个日志样本来识别服务、基础设施和依赖），它不需要大型前沿模型来运行：

使用快速、经济型模型即可处理
无需多步推理
作为后台任务，对日志写入零影响

第七章：你不应该告诉工具该看什么

7.1 可观测性的本质承诺

可观测性的根本承诺是帮助你理解系统。但长期以来，"教会工具系统实际如何工作"的负担一直落在操作它们的工程师身上。

Knowledge Indicators 翻转了这个等式：

传统模式	KI 模式
人教工具	工具自己学
静态配置	动态知识库
手动维护拓扑	自动推断拓扑
每次排障重建上下文	上下文始终就绪
新服务 = 盲区	新服务 = 自动发现

总结

Knowledge Indicators 代表了可观测性领域的一次范式转移：从"人类配置驱动"走向"系统自动理解"。通过让日志自己"说话"，我们构建了一个自更新、自清洁的知识层，为 AI 代理和人类工程师提供始终在线的上下文------让排障从"考古发掘"变成"精准手术"。