日志错误分析:从上千行里抓出高频错误并按类型统计频次

线上服务出问题时,最常见的卡点不是没有日志,而是日志太多。一个失败部署可能吐出几千行,容器重启会把同一条堆栈刷屏几十次,真正有用的那几类错误被淹没在重复信息里。这篇文章讲一套我自己在排查时用的归纳方法:先抓出所有 ERROR 和 WARN 行,再按错误消息聚合统计每类出现多少次,最后只盯频次最高的几条往下查。

为什么不直接 grep

很多人第一反应是 grep -i error app.log。问题是 grep 只能筛行,不能聚合。筛完你还是面对几百行长得几乎一样的输出,得自己用眼睛数哪条最多。如果错误消息里嵌了时间戳、请求 ID、UUID、内存地址这类每次都变的字段,同一类错误在 grep 看来就是几百条不同的行,根本无法统计频次。

要按错误类型统计次数,得先把这些波动字段抹掉,再做归一化。手敲 grep | sed | sort | uniq -c | sort -rn 这一长串管道能凑合实现,但参数难记,改一次过滤条件就得重写,生产排查时没人愿意现场调正则。

核心思路:归一化后再聚合

聚合的关键一步叫归一化。把每条错误行里的可变部分换成占位符,剩下的骨架就是这类错误的签名。具体要抹掉的:时间戳、大数字、UUID、十六进制值、引号里的字符串。这样 user 8821 not found 和 user 4490 not found 会被归到同一个签名,统计时算作两次,而不是两条互不相干的记录。

归一化之后再按签名分组计数,频次自然就出来了。哪类错误重复最多一目了然,这正是排查时最想先知道的那个数字。

一个真实的输入输出例子

假设手头有这样一段抽样日志:

2026-06-13 09:14:02 ERROR db connection timeout to 10.0.3.21
2026-06-13 09:14:05 WARN slow query took 1840ms
2026-06-13 09:14:09 ERROR db connection timeout to 10.0.3.44
2026-06-13 09:14:12 ERROR user 8821 not found
2026-06-13 09:14:15 ERROR db connection timeout to 10.0.3.7
2026-06-13 09:14:20 WARN slow query took 2210ms
2026-06-13 09:14:22 ERROR user 4490 not found

按错误消息聚合统计出现次数后,得到的结果是:

3  ERROR  db connection timeout to <IP>
2  ERROR  user <NUM> not found
2  WARN   slow query took <NUM>ms

七行原始日志压成三类。结论很直接:数据库连接超时是主要矛盾,出现三次且都指向同一网段,该先查数据库连接池或网络;用户查询失败和慢查询各两次,次要。这个判断不用你逐行看,聚合表直接给出来了。

排查线上问题时怎么用这套结果

我处理过一次凌晨告警,Slack 里被贴了大约六百行容器日志。直接读是读不完的,我把它整段粘进日志错误分析器,几秒钟出来一张签名频次表:某条 connection reset by peer 重复了一百四十多次,占了全部 ERROR 的七成,其余都是个位数。问题瞬间收窄到一个上游依赖,不用再一行行翻。如果当时去敲 grep 管道,光调正则抹 IP 和端口就得花掉好几分钟,而告警时间最宝贵。

实际排查里,聚合表通常配合几个附加维度一起看更有用:HTTP 状态码分布能告诉你是不是有大批 5xx;接口路径模式能指出哪个 endpoint 在反复失败;堆栈行计数能估出异常深度;有时间戳时还能算出这批错误集中在哪个时间窗,判断是突发还是持续。这些维度合起来,一段乱日志就被压成一份能直接贴进事故记录的摘要。

把日志当结构化数据继续处理

聚合出签名只是第一步。如果你的日志本身是 JSON Lines 格式,每行一个对象,那在分析之前可以先用 JSON Lines 格式化工具把它展开校验一遍,确认没有截断的脏行再喂给分析器,聚合结果会更干净。两步配合,从原始流水到可行动结论的路径就完整了。

几个使用上的提醒

归一化有代价:消息过于相似的不同错误可能被合并成一类。看到某个签名频次异常高时,展开它的原始样本核对一下,别被合并误导。另外日志即使抹掉了 ID,仍可能残留路径、用户名甚至密钥,处理在本地完成不上传,但你把报告分享给同事前还是要自己脱敏一遍。这套方法定位的是高频模式,不是替代完整可观测平台,它的价值在于排查的最开始那五分钟,帮你少复制粘贴、少手工数行,把注意力直接放到重复最多的那类故障上。

Made by Toolora · Updated 2026-06-13