日志采集工具装好那天，控制台上一排绿点，谁看了都觉得这事办成了。过了两三周再问一句“上次那个报错查出来没”，办公室里安静得有点尴尬。工具在跑，数据在进，就是没人打开看。这毛病不是工具不好，是上线那一刻就没想清楚采集来的东西最终给谁用。
日志采集工具最容易犯的错，是“先全收再说”
我自己干过这事。手一抖，把整台机器的系统日志、应用日志、访问日志全勾上了，一天下来几十上百 G，磁盘进度条肉眼可见地往下走。当时还挺得意，觉得数据全就是安全。真出事那天，我要找一条支付回调失败的记录，在几百万行里翻了半个多小时，关键词换着花样试，翻到眼睛发涩还没定位到。全收等于没收，这话听着糙，但真就是这么回事。
后来我把采集范围砍了一大半。只留几类：应用抛出来的异常、慢查询、认证失败、对外接口的非 2xx 返回。剩下的先进冷存储，需要时再捞。范围一收窄，日志采集工具里能翻的东西少了，反而有人愿意点进去看了。
日志采集工具不响，多半是阈值定得太松
告警这块是重灾区。刚上线怕漏报，阈值调得极低，一点风吹草动就发消息。头两天大家还认真看，第三天开始群里那条机器人消息就没人回了。再往后，真正的故障通知混在一堆“连接数略高”的提醒里，直接沉底。这事儿跟狼来了没区别，只是主角换成了告警机器人。
我后来的做法是把告警分两层。第一层只留会直接影响用户的那几种：站点打不开、下单接口连续报错、证书到期前多少天。第二层是观察类，攒着，每天固定时间出一份摘要，不进即时消息。别小看这个动作，通知一少，人就会看，人一看，工具才算真上线。
日志采集工具采回来的东西，得有人认领
这条最实在。日志这东西不像监控大盘，大盘红了所有人都会抬头，日志得有人主动去翻。上线前不妨先问一句：这条日志采回来，谁会看？如果答不上来，那基本就是白采。
我的做法比较土，在运维群里挂了个简单的轮值表，一周一个人，负责看昨天的错误汇总和周同比。不用多深，扫一眼就行。有人认领之后，日志采集工具里那些原本没人点开的曲线，慢慢就有人拿它说话了——比如“这周这个接口报错比上周多”这种话，只有真看过才说得出来。
格式统一，比采多少重要得多
还有个坑是格式。同一台机器上，PHP 的错误日志、Nginx 的访问日志、应用自己打的业务日志，时间格式三种写法，时区还不一致。日志采集工具收进去以后，按时间排序出来的顺序是乱的，看着更晕。
统一到 UTC 或者统一到本地时间都行，关键是全站一致，时间戳格式用一种。应用日志尽量走 JSON，字段名固定下来，别今天叫 user_id 明天叫 uid。这些事在写代码的时候顺手做，成本很低，等采了几十 G 再回头梳理，那就要按批处理重刷，谁也不想干。
顺便说一句，日志里别塞敏感信息。手机号、身份证、完整的请求头 cookie，这些该脱敏就脱敏，用掩码或者哈希。日志库往往权限管得松，一旦泄露，日志本身就成了事故源头。这块以各自服务商和监管口径的说明为准，别自己拍脑袋。
日志采集工具的价值，在“能回答什么问题”
我现在判断一套日志有没有用，只看它能不能回答几个具体问题：昨天这个接口失败率多少、哪个 IP 打得最凶、这次发布之后报错有没有变多、上次那个慢查询还在不在。能回答，就留着；回答不了，那就是在存数据，不是在用数据。
按这个标准回头清一遍，很多采集规则是可以删的。删掉的不是能力，是噪音。留白之后，真正重要的那几条反而更容易被翻出来。
所以别急着在上线那天开香槟。先定采集范围，再定告警门槛，然后给日志找个认领的人，最后把格式和脱敏这两件事顺手做了。四步都不难，难的是肯在上线前多花这一两个钟头。工具跑起来不等于事情办完了，有人看、有人用、有人拿它做判断，那才算真的上线。
【版权声明】：本站内容若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
