一、核心问题

在运维场景中，使用智能体（LLM）进行日志根因分析面临一个根本性挑战：

日志数据量巨大（GB级），而智能体的处理能力有限（Token 限制、成本、时延）

直接将海量日志输入智能体不可行，而简单截断或采样又会丢失关键信息。

问题本质：如何在大幅压缩日志数据的同时，保留定位问题所需的关键线索？

---

二、解决思路：日志模板 + 智能体

2.1 核心思想

利用传统日志模板技术对海量日志进行压缩和结构化，再由智能体进行语义理解和根因推理。技术实现上采用 Agent + Tools 架构，将日志分析能力封装为工具，由智能体动态决策调用。

流程说明：

1. 智能体决策

   ：接收告警后，智能体根据告警内容动态决定查询的时间范围和过滤条件，从海量日志中精准定位相关数据

2. 双路径处理

   ：

   • 模板匹配统计

     ：按时间窗口统计各日志模板的命中次数，将海量日志压缩为结构化摘要，快速了解这段时间发生了什么，同时不丢失任何关键信息

   • 关键字搜索

     ：根据告警中的关键实体（如任务ID、IP等）搜索相关日志片段

3. 模板摘要/合并

   ：将两条路径的结果整合，形成结构化的日志摘要

4. 语义查询

   ：从模板库中查询各模板的业务含义和异常标注，让摘要具备语义信息

5. 智能体分析

   ：结合日志摘要、模板语义及其它上下文信息（如应用拓扑），进行综合推理

6. 输出根因报告

   ：给出问题的根本原因和处置建议

2.2 架构优势

传统方式	Agent + Tools 架构
固定流程，一次性处理	动态决策，按需调用
可能获取大量无关信息	精准获取所需信息
无法根据中间结果调整	可迭代深入分析
分析路径单一	灵活应对各类告警

2.3 为什么有效

智能体通过工具获取的是压缩后的结构化信息，而非原始日志：

原始数据	工具返回
数百万行日志	模板 + 命中次数
散落的关键信息	聚焦的日志片段
GB 级数据	KB 级摘要

---

三、工具定义

3.1 核心工具

日志查询 (query_logs)

用途：根据各种条件查询日志，支持时间范围、关键字、告警属性等多种过滤方式

参数	说明
start_time	开始时间
end_time	结束时间
keyword	关键字（可选，支持正则）
service	服务名（可选）
host	主机名（可选）
ip	IP地址（可选）
log_level	日志级别（可选）
max_results	最大返回条数

返回：匹配的日志列表及上下文

模板匹配统计 (template_match_stats)

用途：对日志进行模板匹配并按时间窗口统计，将海量日志压缩为结构化摘要

参数	说明
start_time	开始时间
end_time	结束时间
service	服务名（可选）
host	主机名（可选）
window_size	时间窗口大小（如 "1m", "5m"）

内部流程：查询日志 → 逐条匹配模板 → 按时间窗口统计

返回：按时间窗口分组的模板命中统计

语义查询 (get_template_semantics)

用途：查询模板的业务含义和异常标注

参数	说明
template_ids	需要查询的模板ID列表

返回：各模板的业务含义、类型（正常/异常）、严重程度

3.2 辅助工具

工具	用途
get_log_context	获取特定日志的前后上下文，用于深入分析
compare_time_periods	对比两个时间段的模板命中差异，用于变化分析

---

四、场景示例

智能体根据不同类型的告警，灵活组合工具进行分析：

告警类型	分析策略
特定实体告警 如：任务[1001]执行失败	先用关键字搜索追踪实体轨迹，再用模板匹配了解整体情况
性能类告警 如：响应时间上升	先用模板匹配查看整体趋势，发现异常模板后用关键字搜索获取详情
未知异常告警 如：监控检测到异常	先用模板匹配查看所有异常模板，按严重程度逐一分析

关键点：无论哪种场景，核心流程不变——通过模板匹配和关键字搜索获取压缩后的日志信息，再由智能体进行语义理解和根因推理。

---

五、完整示例

5.1 告警输入

告警：任务执行失败率超过阈值（当前 15%，阈值 5%）
时间：2025-01-1310:23:00

5.2 分析过程（按流程步骤）

步骤1：智能体决策

智能体分析告警内容，决定：

• 时间范围：10:15 - 10:25（告警前后各5分钟）

• 过滤条件：任务相关日志

步骤2：双路径处理

路径A - 模板匹配统计：

时间窗口 10:20-10:21:
T1 (任务入队成功): 1500 次
T2 (任务开始执行): 1450 次

时间窗口 10:21-10:22:
T1 (任务入队成功): 3200 次
T3 (并发超阈值): 85 次 ⚠️
T4 (任务执行失败): 12 次 🔴

时间窗口 10:22-10:23:
T1 (任务入队成功): 4100 次
T3 (并发超阈值): 200 次 ⚠️
T4 (任务执行失败): 150 次 🔴

路径B - 关键字搜索（关键字："execution failed"）：

[10:21:07]task[1001]execution failed, error code: -11
  上文: concurrent count 58 exceeded threshold50

[10:21:15]task[1008]execution failed, error code: -11
  上文: concurrent count 65 exceeded threshold 50

步骤3：模板摘要/合并

整合两条路径结果，形成结构化摘要：

• 模板统计显示：10:21 开始出现异常模板 T3、T4

• 关键字搜索显示：失败前均有"并发超阈值"日志

步骤4：语义查询

查询命中模板的语义标注：

模板ID	含义	类型
T1	任务入队成功	正常
T3	并发数超过阈值	异常-警告
T4	任务执行失败	异常-错误

步骤5：智能体分析

结合日志摘要和模板语义，智能体推理：

1. T1 命中量激增（1500→4100），说明任务入队量突增

2. T3 从无到有，说明并发压力超出阈值

3. T4 紧随 T3 出现，说明并发超限导致任务失败

4. 关键字搜索证实：每次失败前都有并发超阈值日志

5.3 输出根因报告

【根因分析】
10:21 开始任务入队量激增（+173%），导致并发数超过阈值(50)，进而引发任务执行失败。

【根本原因】
上游系统数据量突增，超出当前系统处理能力

【建议措施】
1. 短期：提高并发阈值或增加处理资源
2. 长期：增加流量控制机制，防止上游突发流量

---

六、核心价值

6.1 数据压缩

压缩前	压缩后
GB 级原始日志	KB 级工具返回结果
智能体无法处理	智能体可快速分析
信息淹没在噪声中	关键信息精准呈现

6.2 动态决策

• 智能体根据告警类型选择合适的工具组合

• 可根据中间结果调整分析策略

• 支持迭代深入，逐步逼近根因

6.3 能力扩展

工具集可按需扩展，如：

• 添加指标查询工具

• 添加拓扑关系查询工具

• 添加历史案例匹配工具

---

七、总结

本方案通过日志模板 + 智能体的组合，解决了 LLM 处理海量日志的核心难题：

问题	解决方案
日志量太大，LLM 无法处理	通过模板匹配将 GB 级日志压缩为 KB 级摘要
压缩后丢失关键信息	模板保留完整的事件类型和频次，关键字搜索补充具体细节
LLM 不理解日志含义	通过语义查询为模板添加业务含义和异常标注

核心价值：让智能体能够高效处理原本无法处理的海量日志数据，同时保留定位问题所需的全部关键信息。