[Paper] LLM‑SrcLog：通过大语言模型实现主动且统一的日志模板提取

Source: arXiv - 2512.04474v1

概览

本文提出了 LLM‑SrcLog，一种利用大语言模型（LLM）直接从系统源代码中提取日志模板的新框架。通过将静态代码分析与数据驱动的解析相结合，该方法在保持运行时开销足够低以用于生产的前提下，提供了高精度的日志模板。

主要贡献

• 主动模板提取：在软件部署前从源代码生成日志模板，降低对事后日志挖掘的依赖。
• 统一流水线：将白盒 LLM‑基提取器（代码驱动）与黑盒数据驱动提取器相融合，以处理缺少可访问源代码的日志。
• 跨函数静态分析：在函数和模块之间重建日志上下文，使 LLM 能区分常量文本和变量占位符。
• 性能提升：相较于仅使用 LLM 的基线提升 2–17 % 的 F1 分数，较传统解析器提升 8–35 %，并将在线解析延迟降低约 1,000 倍（相较于每条日志的 LLM 推理）。
• 真实场景验证：在公共基准（Hadoop、Zookeeper）和大规模工业系统（Sunfire‑Compute）上展示了有效性，并在生产环境中进行案例研究。

方法论

1. 静态代码分析器 – 遍历代码库，跟踪日志 API 调用，构建捕获周围语句、变量名和控制流信息的 日志上下文图。
2. 白盒 LLM 提取器 – 将重建的上下文输入预训练 LLM（如 GPT‑4），提示其输出 模板 并标记每个 token 为常量或变量。后处理会清理输出（例如合并相邻常量）。
3. 黑盒数据驱动提取器 – 对于源代码不可用或不完整的日志，系统回退到基于聚类的解析器（如 Drain），对相似日志行进行分组并推断模板。
4. 融合层 – 合并两套模板，解决冲突，构建可在运行时以微乎其微的延迟使用的最终查找表。

整个流水线离线运行（每次发布一次），因此昂贵的 LLM 推理仅在开发阶段进行，而不在生产日志管道中执行。

结果与发现

• 延迟：每条日志的平均解析时间从约 150 ms（每条日志 LLM）降至约 0.15 ms，达到传统解析器的水平。
• 覆盖率：>95 % 的日志被代码驱动提取器匹配；其余日志由聚类回退处理。
• 案例研究：在生产 AIOps 流水线中，LLM‑SrcLog 将误报异常警报降低了 22 %，并将故障诊断时间从 30 分钟缩短至不足 5 分钟。

实际意义

• 加速 AIOps 流水线 – 精准的模板为下游异常检测和根因分析工具提供更干净、结构化的数据，降低噪声和警报疲劳。
• 降低运营成本 – 将昂贵的 LLM 推理转移到构建阶段，团队无需在生产环境中使用高成本 GPU 资源。
• 新服务快速上手 – 开发者可在 CI/CD 中自动生成日志模板，确保微服务之间的一致性，无需手动维护模板。
• 提升遗留代码可观测性 – 混合设计意味着即使是没有源码访问权限的系统（如第三方二进制）也能受益于数据驱动解析，而任何可用的代码都会被用于提升精度。
• 安全与合规 – 结构化日志更易于实现脱敏、保留策略和审计追踪，对受监管行业尤为重要。

局限性与未来工作

• 依赖日志约定 – 静态分析器假设日志 API 较为统一；高度定制或动态生成的日志语句可能被遗漏。
• LLM 提示工程 – 提取模板的质量依赖于提示设计；适配不同编程语言或框架可能需要额外调优。
• 代码分析的可扩展性 – 对于极大的单体仓库，静态分析步骤可能成为瓶颈；未来计划采用增量分析技术。
• 扩展到多模态日志 – 未来工作包括处理嵌入 JSON 或 protobuf 负载的结构化日志，并将运行时解析错误的反馈回路集成进来，以自动优化模板集合。

作者

• Jiaqi Sun
• Wei Li
• Heng Zhang
• Chutong Ding
• Shiyou Qian
• Jian Cao
• Guangtao Xue

论文信息

• arXiv ID: 2512.04474v1
• 分类: cs.SE
• 发布日期: 2025 年 12 月 4 日
• PDF: Download PDF