日志规范没定好，两年后排查一个问题要两小时

做日志这件事，前期怎么省事，后期就怎么痛苦。我们一个服务上线两年，日志一直是能打就打，想打什么打什么，结果排查问题时发现三件事同时不成立：一是找不到，同一个请求的日志散在五个文件里，没有关联 id；二是看不懂，有的打对象有的打字符串，字段名前后不一致；三是查不动，一天的日志两百多 G，grep 一次要等很久。后来重做了一遍日志规范，把这三件事分别解决。第一解决关联，在请求入口生成一个 trace id，写进上下文，全链路所有日志自动带上，排查时用一个 id 就能串起整个请求路径。第二解决字段，定义固定的字段集，服务名、级别、时间、trace id、用户标识、耗时、错误码，其余业务字段统一放一个 extras 里，不允许平铺。这样日志能被程序解析，不再是给人猜的文本。第三解决检索，把日志按天分区，热数据留七天支持即时查询，冷数据归档到对象存储，需要时再拉。同时把高频排查场景做成固定的查询模板，比如按错误码聚合、按耗时排序取慢请求、按用户查全链路。规范落地时有两条约束起了关键作用。一是日志内容必须能被单独理解，不允许出现详见上文这类跨行引用，因为日志聚合后行与行之间没有顺序保证。二是不允许在循环里打日志，必须聚合成一条，否则一次批量操作能刷出几十万行。做完之后最直观的变化是排查时间，原来查一个问题平均两小时，现在十分钟以内。