凌晨两点半，手机震了一下。值班群里蹦出一行字：下单接口全挂了。然后没人说话。
登机器，tail -f，grep。三台应用服务器，四个小时，日志文件滚了七个G。最后定位到上游一个返回空字段的服务。查出来花了十分钟，找出来花了四个小时。
这就是日志分析最真实的模样。多数团队不缺日志，缺的是能用的日志。
先问自己要回答什么问题
见过太多团队，第一步就走错了——直接选型。ELK、Loki、ClickHouse、商业 APM，方案书比业务需求还厚。
选型不产生价值。真正决定这套东西好不好用的，是你打算拿它回答什么问题。
排障要上下文，要能把一次请求在五个服务里的日志串成一条线；审计要的是不可篡改和长期留存；业务分析要的是字段能聚合，能 group by；合规检查盯着留存周期和访问控制。这几个目标对底层的要求差得很远。硬塞进一套系统，最后什么都沾一点，什么都查不动。
说白了，日志分析的第一步不是买工具，是写清楚你要查什么。
字段这事在打日志那天就定了
我见过最典型的写法：
log.info(“下单失败 ” + userId)
方便。省事。三个月后线上出问题，你想按用户维度捞一条完整的失败链路——做不到。userId 混在字符串里，跟错误信息粘在一块，正则写三版都不一定对。
结构化日志没那么玄。JSON 或者 key=value，把几样东西固定下来就行：时间戳、服务名、实例、trace id、日志级别、错误码、关键业务 id。
麻烦在于，写业务代码的人不愿意多敲这几行。你让他加字段，他嫌烦；你让他统一 trace id 透传，他要改五层调用。所以这事靠喊口号没用，得靠 SDK 封装、代码模板、CR 卡点。能让工具解决的，绝不指望自觉。
还有个容易漏的点：日志级别。生产环境开着 debug，等于每天往磁盘里倒垃圾。真要临时排查，动态调整级别比预埋一堆 debug 强得多。
存储成本迟早会找上门
日志量的增长曲线不太讲道理。业务量翻一倍，日志量往往涨两三倍——因为报错多了，重试也多了。
Elasticsearch 那一套用起来爽，但索引和内存开销会让不少团队在半年后开始算账单。等算完账单才想起来做冷热分层、做采样，往往已经积了一堆没人查的索引。
采集端也是事故高发区。容器环境里 pod 一重建，写在容器里的日志跟着没了；有人用 sidecar，有人直接读 stdout，两条路各有各的坑。还有重复采集——两个 agent 同时盯一个目录，查询结果里每条日志出现两遍，排查的人能原地崩溃。
几个取舍摆在面前。debug 日志生产环境默认关掉。访问日志能聚合就别全量落。业务日志按重要性分级，错误全留，正常流转抽样。Loki 那类只索引标签的方案，写入和存储便宜得多，代价是全文检索弱——你要是习惯了大范围模糊匹配，会不适应。ClickHouse 查得快，可写入链路和查询层得自己搭。
没有银弹。只有你愿意为哪一头付钱。
查不动的日志等于没有
一个很朴素的判断标准：工程师遇到问题，第一反应是不是去查日志。
如果查一次要等三十秒，或者要先翻文档回忆查询语法，他一定退回到 SSH 加 grep。不是他保守，是路径成本太高。
所以查询体验本身就是功能。常用查询存成模板，报错页面直接带上跳转链接，trace id 点一下就能串出全链路。这些活儿不性感，但它决定了这套系统有没有人用。
告警是另一个坑。我见过一个团队，日志告警配了两百多条，每天响几百次，最后全员静音——比不配还危险。
基于日志的告警，适合干的其实就几件事：错误率突增、特定错误码首次出现、关键业务日志突然断流。拿它去做性能监控，是拿错了工具。
采样这件事也值得单独说一句。很多人以为采样就是丢日志，其实不是。保留全部错误、保留慢请求、对正常请求按比例抽——不同路径不同策略，这样既能压住量，又不至于事故现场被抽没了。代价是采样规则本身要有人维护，规则写错一次，可能连着几周都在盲区里跑。
最后是个很土的问题
日志分析这套东西，技术栈大概占一半，另一半是团队习惯。
出事之后，有没有人把定位过程写成一条查询语句存下来？新加的错误码，有没有人补进规范文档？那些三个月没人看的采集规则，有没有人定期清掉？
跑得顺的团队，工具往往挺朴素。但他们有条规矩：每次线上复盘，至少产出一条新查询或者一条新告警规则。一年下来，这套东西就长成了肌肉记忆。
反过来，买了最贵的一整套，半年后没人登录——这种故事我听过太多次了。
日志分析从来不缺技术。缺的是有人愿意把它当成一件事，长期地做下去。