上周帮一个做电商的朋友排障，他说服务半夜挂了三次，监控面板一片全绿，找了两小时没头绪。我上去先grep了下网关的错误日志，五分钟就定位到是第三方支付的回调接口超时没做熔断。他愣了，说平时都只看监控曲线，从来没翻过硬日志。后来他给我转了个红包，说之前找外包搭的智能日志平台花了十几万，天天弹没用的告警，还不如我这五分钟的grep好用。
别把日志当监控的附属品
很多团队现在有个误区，觉得上了APM、搭了监控大盘，日志就是可有可无的冗余数据。反正监控告警会响，到时候再翻日志就行。
根本不是那么回事。监控是给你看宏观趋势的，是把大量数据压缩成曲线、百分比，它天然会丢失细节。比如某个核心接口的响应时间从100ms慢慢爬到480ms，离你设的500ms告警阈值还差20ms，监控不会响，但这个变化背后可能是数据库索引失效、可能是依赖的第三方接口变慢、可能是服务器磁盘快满了。这些细节，只有翻日志才能看到。
我见过太多团队，平时从来没人主动刷日志，等告警响的时候，故障已经扩散到用户端了。说白了，日志分析从来不是故障发生后的救火工具，是你日常用来提前发现隐患的探照灯。
别让烂日志把分析路堵死
很多人说日志分析难，其实难的根本不是分析工具，是你手里的日志根本没法用。
上次去一个做中小企服务的团队交流，他们的日志全是“系统错误”“操作失败”这种没头没尾的话，没有错误码，没有请求参数，没有用户标识，连是哪个服务打出来的都没标。出了问题翻日志，满屏都是一样的报错，根本分不清是哪里出的问题。
结构化日志是解决这个问题的最低成本方案。别再写那种纯文本的、靠正则表达式去匹配字段的日志了，直接用JSON格式输出，每一行带上时间戳、服务名、traceID、接口路径、错误码这些固定字段。分析的时候直接按字段过滤，不用靠瞎猜关键词，效率能提至少十倍。
真的，我每次碰到那种满屏无意义字符串的日志，都想直接把写日志的工程师拉过来现场改。你写日志的时候多花十秒钟加几个字段，后面排障的人能少花两小时找问题。
别上来就堆大模型当万能药
现在好多厂商吹大模型日志分析，说能自动识别异常、自动定位根因，卖得死贵。
说实话，大部分团队根本用不上。
你想啊，大模型要做好日志分析，前提是你得有足够规范的日志数据喂给它。要是你连基础的日志字段都没统一，连traceID都没打通全链路，大模型给你的分析结果全是瞎编的——它可能把正常的业务日志当成异常报给你，也可能把真正的报错当成噪声过滤掉。这种不可靠的结果，你敢直接拿来排障吗？
traceID全链路贯通才是真正能解决80%排障问题的基础能力。从用户请求进网关开始，到应用服务、缓存、数据库，每一层的日志都带上同一个traceID，出了问题直接搜这个ID，整条请求链路的日志全出来，哪一步超时、哪一步报错一眼就能看到。根本不需要什么大模型来帮你分析。
当然也不是说大模型完全没用。等你把日志规范、链路追踪这些基础工作都做扎实了，拿大模型来做个相似报错聚类，把一天里几百条重复的“支付回调超时”归成一类，不用你天天对着重复告警刷屏，那还是能省点事的。但你要是基础都没打牢就跟风上大模型，那纯属是给厂商送钱。
还有个很多人忽略的点，日志不是打越多越好。我见过最夸张的团队，把用户的手机号、身份证号全打在日志里，存储成本翻了好几倍不说，最后还因为数据合规问题被罚了一笔。写日志的时候要想清楚，哪些信息是排障必须的，哪些是多余的，别什么都往日志里塞。
说白了，日志分析这事没那么玄。你不用追什么最新的技术，先把日志写规范，把链路打通，平时没事多翻两下日志，大部分问题都能解决。