从传统日志平台到 AI Agent 自动排障
一、日志分析大体有三种形态
我们先不谈具体技术实现。
如果从“运维如何排查线上问题”这个角度来看，日志分析大概经历了三种形态：
第一种：自己搭建日志分析平台
↓
第二种：使用第三方 / 云厂商日志服务
↓
第三种：AI Agent 自动分析和排障
三种方案解决的问题其实越来越高阶：
第一种
自己解决“日志怎么收、怎么存、怎么查”
第二种
把“日志基础设施”交给专业厂商
第三种
进一步把“怎么分析、怎么定位问题”
交给 AI Agent
所以它实际上是一个演进过程：
自己维护基础设施
↓
购买基础设施能力
↓
购买 / 构建智能排障能力
二、第一种：自己搭建日志分析平台
这是比较传统的一种方案。
我们自己负责从日志采集，到日志存储，再到日志查询和分析。
整体架构大概是：
业务服务
│
▼
日志采集
│
▼
Kafka
│日志高吞吐、削峰、缓冲和系统解耦
▼
Flink
│
├── 日志解析
├── 清洗
├── 脱敏
├── 字段标准化
└── 实时计算
│
▼
ES / OpenSearch
│全文检索
│时间范围
│服务过滤
│错误级别
│关键词
│聚合统计
▼
自己开发的日志平台
2.1 日志采集
首先需要在业务服务器上部署日志 Agent。
例如业务服务不断产生：
/var/log/order-service/app.log
Agent 负责：
- 读取日志
- 增量采集
- 保存 offset
- 断点续传
- 批量发送
- 失败重试
然后发送到 Kafka。
2.2 Kafka
Kafka 主要解决：
日志高吞吐、削峰、缓冲和系统解耦。
不建议业务服务直接：
业务服务 → ES
而是：
业务服务
↓
Kafka
↓
日志处理系统
这样日志系统出现问题的时候，不会直接影响业务服务。
2.3 Flink
Kafka 后面可以使用 Flink 进行实时处理：
Kafka
↓
解析
↓
清洗
↓
标准化
↓
脱敏
↓
统计
↓
告警
↓
ES
比如把原始日志：
2026-09-19 14:32:21 ERROR
orderId=123
Redis timeout
处理成结构化数据：
{
"timestamp": "2026-09-19 14:32:21",
"level": "ERROR",
"service": "order-service",
"orderId": "123",
"message": "Redis timeout"
}
2.4 ES / OpenSearch
最终把日志存储到 ES / OpenSearch。
这样就可以支持：
全文检索
时间范围
服务过滤
错误级别
关键词
聚合统计
例如：
service = order-service
level = ERROR
time = 14:30 ~ 15:00
message contains "timeout"
2.5 自己开发日志平台
最后再做一个 Web 平台：
日志查询
日志搜索
聚合分析
Dashboard
告警
日志上下文
这种方案的问题
最大的问题就是：
重。
你不仅要开发日志平台，还要维护：
Agent
Kafka
Flink
ES
监控
告警
扩容
容灾
数据生命周期
权限
所以如果不是特别大的企业，自己完整维护这一套，成本其实比较高。
三、第二种：直接使用第三方 / 云厂商日志服务
所以很多企业不会自己搭完整的日志基础设施。
而是直接使用成熟的日志服务。
例如：
业务服务
↓
日志 Agent
↓
第三方日志服务
↓
查询 / 分析 / Dashboard / 告警
比如：
阿里云 SLS
腾讯云 CLS
AWS CloudWatch
Datadog
Splunk
Elastic Cloud
3.1 它解决了什么问题？
原来自己维护：
Kafka
Flink
ES
存储
扩容
监控
告警
现在这些基础设施由厂商提供。
我们只需要：
业务
↓
Agent
↓
日志服务
然后直接使用：
日志搜索
SQL 查询
Dashboard
聚合
告警
3.2 这种方案的优势
最大的优势就是：
把日志基础设施交给专业厂商。
我们不用自己考虑：
ES 集群怎么扩容？
磁盘满了怎么办？
Kafka 堆积怎么办？
日志怎么做高可用？
冷热数据怎么管理？
这些能力基本都由厂商解决。
3.3 但是它依然有一个问题
不管是：
自己搭日志平台
还是：
使用第三方日志服务
本质上解决的还是：
“怎么更方便地找到日志。”
例如线上出现：
“订单服务为什么突然变慢？”
传统运维还是要自己：
查监控
↓
查日志
↓
查 Trace
↓
查 Redis
↓
查数据库
↓
查发布记录
↓
查代码
↓
人工分析
↓
定位根因
真正耗时间的其实不是：
“搜索日志。”
而是：
“在不同系统之间不断切换，然后自己建立因果关系。”
这就引出了第三种方案。
四、第三种：AI Agent 自动分析和排障
AI 时代，我们可以换一种思路：
不让运维自己一个一个系统去查，而是让 Agent 自己去调查。
例如运维在飞书里面直接问：
订单服务今天下午为什么大量超时？
然后后面的事情交给 Agent。
整体架构：
运维，运营
│
▼
飞书，企业微信机器人
│
▼
Agent Bridge / Gateway
│
▼
Agent Runtime
│
▼
Model
│
┌────────┴────────┐
│ MCP │
└────────┬────────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
日志工具 指标工具 业务工具
│ │ │
▼ ▼ ▼
TlS SLSLogs 业务Metrics Business
│ │ │
└───────────┼───────────┘
│
更多工具
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Jenkins 源码 发布记录 数据库状态
这里最重要的变化是：
日志不再是整个系统，而只是 Agent 可以调用的一个工具。
4.1 Agent 可以调用什么？
这个时候就不能只设计一个：
Log MCP
而应该把企业内部各种能力都通过 MCP 暴露给 Agent。
例如：
日志
search_logs
get_log_context
search_error_logs
可以查看：
应用日志
错误日志
调用链上下文
指标
query_qps
query_latency
query_error_rate
query_cpu
query_memory
可以查看：
QPS
P99
错误率
CPU
内存
数据库指标
Redis 指标
源码
这个地方其实也非常重要。
比如我们每次通过 Jenkins 发布服务的时候：
代码仓库
↓
Jenkins
↓
构建
↓
部署
在发布过程中，可以把对应版本的：
源码
Commit
版本号
发布记录
同步到一个统一的代码存储 / 索引系统。
于是 Agent 就可以通过 MCP：
search_code
get_file
get_commit
compare_version
直接查看：
当前线上版本
最近修改
某个方法
某段代码
版本差异
这样 Agent 就不只是：
“知道系统报错了。”
而是可以进一步：
“看看最近是不是代码改了什么。”
发布 / Jenkins
同样可以提供：
get_deployment
get_release
get_build
get_recent_deployments
Agent 就可以知道：
什么时候发布？
发布了什么版本？
谁发布的？
发布前后有什么变化？
业务数据
还可以通过 MCP 查询业务系统：
订单
支付
用户
库存
商品
数据库
例如：
query_order
query_payment
query_user
于是 Agent 可以把：
日志
+
指标
+
源码
+
发布
+
业务数据
+
数据库
+
配置
+
其他企业内部系统
全部结合起来。
五、最终的产品形态：一个真正的 AI Investigation Agent
所以我们最终想做的其实已经不是：
“AI 日志查询工具。”
甚至也不只是：
“AI 日志分析平台。”
而是：
一个能够自主调用企业内部 MCP 工具，完成故障调查和问题定位的 Agent。
5.1 运维只需要提出问题
例如：
订单服务今天为什么突然大量超时？
运维不需要告诉 Agent：
先查日志
再查 Redis
再查 Jenkins
再查源码
这些都应该由 Agent 自己决定。
5.2 Agent 自己做 ReAct 循环
核心就是：
Reason
↓
Action
↓
Observation
↓
Reason
↓
Action
↓
Observation
↓
......
也就是：
提出假设
↓
调用 MCP 工具
↓
拿到结果
↓
分析结果
↓
决定下一步查什么
↓
继续调用工具
↓
验证 / 排除假设
↓
最终得到结论
5.3 举一个完整例子
用户：
订单服务今天为什么突然大量超时？
Agent：
第一步：查指标
query_latency(order-service)
发现：
P99
200ms → 3.2s
于是知道：
14:32 左右开始出现明显异常。
第二步：查日志
search_logs(
service="order-service",
time="14:32~14:40"
)
发现：
Redis timeout
于是提出假设：
Redis 可能存在异常。
第三步：查 Redis 指标
query_redis_metrics()
发现：
connection usage +300%
timeout 大量增加
进一步支持这个假设。
第四步：查发布记录
get_recent_deployments(
service="order-service"
)
发现：
14:30
order-service v2.8
于是又产生一个新的关联：
14:30 发布
↓
14:32 开始异常
第五步：查源码
search_code(
service="order-service",
keyword="redis pool"
)
发现：
v2.7：
maxTotal = 200
v2.8：
maxTotal = 20
第六步：形成完整因果链
v2.8 发布
↓
Redis 连接池配置变化
↓
连接数量不足
↓
Redis timeout
↓
订单服务响应时间增加
↓
大量接口超时
↓
错误率上升
5.4 最后给运维的不是“日志”，而是结论
例如：
🔴 订单服务异常
异常时间：
14:32 ~ 14:47
影响：
P99 从 200ms 上升至 3.2s
错误率从 0.3% 上升至 12%
初步根因：
order-service v2.8 发布后，
Redis 连接池配置发生变化，
导致 Redis 连接不足，
产生大量 timeout。
关键证据：
✓ 14:32 Redis timeout 开始增加
✓ Redis connection usage +300%
✓ 14:30 发布 order-service v2.8
✓ v2.8 修改 Redis 连接池配置
✓ 数据库指标正常
建议：
1. 回滚 v2.8
2. 恢复 Redis 连接池配置
3. 持续观察 P99 和错误率
置信度：92%
这时候：
日志只是证据之一。
Agent 真正完成的是：
Evidence
↓
Hypothesis
↓
Verification
↓
Root Cause
↓
Recommendation
六、总结：日志平台正在从“查询工具”变成“AI 排障入口”
整个演进可以总结成：
第一阶段
自己搭日志平台
↓
解决日志的采集、存储、查询
第二阶段
使用第三方日志服务
↓
把日志基础设施交给专业厂商
第三阶段
AI Agent 自动排障
↓
Agent 自主调用企业内部各种 MCP
↓
日志 / 指标 / 源码 / 发布 / 业务 / DB / 配置 / ...
↓
自主分析
↓
自主验证
↓
定位根因
所以我们最终做的产品，不应该简单理解成：
AI + 日志
而应该理解成：
AI 运维 Agent
│
▼
MCP Tool Ecosystem
│
┌────────────┼────────────┐
▼ ▼ ▼
日志 指标 源码
│ │ │
▼ ▼ ▼
发布 业务 DB
│ │ │
└────────────┼────────────┘
▼
Agent ReAct
│
▼
自动故障调查
│
▼
Root Cause
│
▼
修复建议 / 执行
最终目标不是让运维更快地“查日志”，而是让运维只需要告诉 Agent“哪里出问题了”，剩下的调查、取证、分析、验证和定位工作，都由 Agent 自己完成。
这就是从 Log Search → AI Investigation → AIOps 的演进。
这个结构就比较适合视频：第一部分建立认知，第二/三/四部分分别讲三种方案，第五部分把你们现在的产品形态拔高。尤其最后一定要强调：“日志只是 MCP 工具之一，我们真正做的是企业内部 Tool + Agent 自循环的智能故障调查。”