服务器半夜出问题翻不到记录？云日志得先集中、再留够

服务器半夜告警，第二天想查昨晚到底发生了什么，却发现系统日志早被滚动覆盖了；想比对几台机器的时间线，得一台台登录去翻文件；想搞清用户反馈的「支付失败」，要在应用日志里grep半天还没结果——这些问题不是出在排查能力上，而是日志从一开始就没规划。

日志散落的三种典型症状

• 被覆盖：日志写在本机磁盘，容量有限，滚动策略把昨天的记录冲掉了，最关键的故障时段恰恰没留下证据。
• 分散：Web日志在服务器A、应用日志在服务器B、数据库慢查询在数据库自己那里，出了问题要拼凑三四个来源，时间戳格式还不一样。
• 没结构：全是自由文本，想统计「昨天的失败请求有多少」只能逐条肉眼看，告警也只能靠人盯。

第一步：先集中，再谈别的

云日志服务解决的就是「集中」：各台服务器、容器、应用把日志实时投递到统一的日志库，检索、统计、告警都在一个界面里完成。接入方式通常是装一个采集代理，把指定路径的日志自动采走，成本主要是按存储量和索引量计费。集中之后，原来「登录机器翻文件」的排查，变成「一个查询语句拉出所有相关日志」，多台机器的时间线可以合并对照，故障定位从小时级缩短到分钟级。

第二步：保留策略要按排查需求定

日志不是存得越久越好，存储费用会悄悄膨胀。合理的做法是分层：访问日志、错误日志这类排查高频使用的，保留一到三个月；审计类、安全类日志按合规要求保留（有些等保场景要求半年以上）；调试级别的日志保留几天就够。同时给日志库设置自动清理和容量告警，避免某天日志暴增把预算打穿。另外，日志里别记敏感信息——用户的手机号、密码、支付凭证明文进日志，既是合规风险，也是泄露入口。

第三步：把常用查询固化下来

日志集中后的最大红利，是把「出了事临时想查什么」变成「平时就备好的查询」：错误率Top接口、慢请求分布、支付失败的原因码统计，都可以存成固定的查询或报表，再配几条阈值告警——错误量突增、日志量异常、关键接口超时，第一时间有人收到通知。故障排查拼的不是半夜的反应速度，而是日志平时就躺在那里等着被查。服务器可以半夜出问题，但证据不该跟着一起消失。