日志清洗实战:把杂乱日志清理成排查时真正能看的关键行

线上出问题的时候,我第一件事往往是去翻日志。可真正打开一看,屏幕上滚过来的常常是几千行带时间戳、带颜色控制符、还夹着大段 JSON payload 的输出。要在这种东西里找到那一行真正的报错,眼睛先就花了。日志清洗做的就是把这些噪音剥掉,只留下能帮你定位问题的部分。

下面我把平时整理日志的几个步骤拆开讲清楚,也给一个真实的清理前后对比。

杂乱日志到底乱在哪

一段从终端或 CI 复制出来的日志,通常有四类干扰:

每行开头的时间戳前缀,比如 2026-06-13T08:21:04.331Z 或者方括号包起来的 [08:21:04],占掉行首一大块宽度。
ANSI 颜色控制符。终端里看是彩色,复制成纯文本后就变成 \x1b[31m、\x1b[0m 这种转义码,夹在每个词中间。
空行。很多框架喜欢在日志块之间插空行,粘进工单后行数翻倍。
超长行。一条带完整请求体的日志可能有两千个字符,横向拉满,把真正的报错挤到看不见的地方。

把这四类去掉,日志的可读性立刻就不一样了。

去时间戳和 ANSI 转义码

这两步是收益最高的。时间戳前缀对排查当下这次问题其实没多大用,你关心的是事件顺序而不是毫秒级时刻,去掉前缀后每行都从有意义的内容开始,扫起来快很多。

ANSI 转义码更要清理。一个 \x1b[31m 出现在词和词之间,会让搜索 error 这个关键词时漏掉本来该匹配的行,因为字符串被颜色码切断了。去掉颜色控制符之后,关键词过滤才靠得住。我自己的习惯是先去颜色、再去时间戳,最后才决定要不要只保留错误行,顺序反过来容易把有用的上下文连带删掉。

真实例子:一段 CI 失败日志的清理前后

清理前,直接从 CI 复制出来是这样:

[08:21:03] \x1b[90mInstalling dependencies...\x1b[0m
[08:21:04]
[08:21:05] \x1b[32m✓ packages linked\x1b[0m
[08:21:09] \x1b[31mERROR\x1b[0m TypeError: cannot read property 'id' of undefined
[08:21:09]     at handleUser (/app/src/user.ts:42:13)
[08:21:10] \x1b[90mdebug: cache miss for key user:8831...(后面还有 1800 字)\x1b[0m

去掉时间戳前缀、ANSI 颜色码、空行,再开启只保留错误行并对超长行截断,结果是:

ERROR TypeError: cannot read property 'id' of undefined
    at handleUser (/app/src/user.ts:42:13)

六行变两行,而且这两行正是要发给同事或者贴进工单的内容。工具还会顺手统计:原始 6 行、输出 2 行、删除 1 个空行、疑似错误行 1 条、截断 1 行,这样你能说清楚日志是怎么被压到这么短的,不是黑盒裁剪。

按关键词过滤,聚焦关键段落

只保留错误行是启发式规则,它会留下含 ERROR、fatal、exception、panic、failed、traceback 这类词的行。CI 日志动辄几千行的时候,这一步能把失败段直接捞出来。

不过我要提醒一句:真正的根因有时藏在报错前面的 WARN 或 INFO 行里,比如一条 "connection pool exhausted" 的警告才是后面一连串 error 的源头。所以错误行模式适合先定位,真要排查清楚,记得回头看看报错前后那几行。如果你想更精细地按自己的规则匹配,可以配合正则测试工具先把过滤表达式调好再用。

本地处理,日志不出浏览器

日志里常常带着 token、密码、客户数据这些不该外传的东西,所以处理过程在哪里跑很关键。这个工具的清理逻辑全部在浏览器内用 JavaScript 完成,日志不会上传到任何服务器。

要注意的是,如果你主动分享带状态的链接,URL 里可能包含你粘进去的紧凑文本,所以含密钥或用户隐私的日志不要分享生成链接。同样,即便清理掉了颜色和时间戳,只要原始内容里还有敏感字段,就不要直接把结果贴出去。

整理好的日志可以直接拿去做下一步:想把每行结构化成 JSON 方便检索,可以接 JSON Lines 格式化工具;想把杂乱日志清成可读的关键行,就用日志行清理工具这一道把噪音先剥干净。

Made by Toolora · Updated 2026-06-13