适用场景

日志分析失败的原因通常不是算法不够好，而是日志本身太乱：格式不统一、级别乱用、关键字段缺失。先把日志规范做扎实，再上算法，效果会完全不同。

配置步骤（日志规范与采集链路）

# 1) 应用侧输出 JSON 日志（示例：PHP）
# {"ts":"2026-09-26T10:00:00+08:00","level":"error","svc":"order",
#  "trace_id":"abc123","module":"pay","msg":"callback timeout","cost_ms":3000}

# 2) 采集端：Filebeat / Vector 配置要点
#   - 多行日志合并（Java 堆栈）
#   - 字段解析与类型转换
#   - 本地磁盘缓冲，远端不可用时不丢日志

# 3) 存储：日志与指标分离
#   - 日志走 ES/Loki，指标走 Prometheus
#   - trace_id 贯穿应用日志与链路追踪

# 4) 校验：trace_id 能否串起一次请求的全部日志

关键参数与建议

  • 日志规范：统一 JSON 结构（时间、级别、服务、trace_id、模块、消息、耗时）
  • 采集链路：Agent 采集 → 缓冲队列 → 存储，避免业务直接写远端日志服务
  • 分级策略：ERROR 要真错误，业务异常走 WARN，别把正常分支打成 ERROR
  • 字段化：把可变内容（订单号、IP）抽成字段，便于聚类
  • 采样与保留：热数据 7-15 天，冷数据归档，避免存储费用失控
  • 异常检测：先用阈值与统计，再上模型，能解释的告警才有人信
  • 结果落地：异常检测输出必须能关联到服务与变更记录，才叫根因提示

容易踩的坑

  • 日志格式随时改，采集解析规则全部失效
  • 多行堆栈没合并，一条异常拆成几十行
  • 缓冲队列积压后直接丢弃，故障时正好没有日志
  • 把敏感信息（手机号、身份证）打进日志，合规风险
  • 全部日志按 ERROR 级别输出，告警无法分级
  • 日志保留策略缺失，磁盘写满导致服务异常

验证与巡检

# 采集健康
du -sh /var/log/app
filebeat test config -c /etc/filebeat/filebeat.yml

# 字段完整性抽查：最近 100 条日志缺 trace_id 的比例
  • 巡检：采集无丢弃、字段完整率 > 99%、敏感字段已脱敏、磁盘水位正常

小结

AI 日志分析验收：一次故障能在 5 分钟内定位到具体服务与错误类型，并给出关联的变更或依赖，而不是给出一堆相似日志。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。