说到服务器日志管理，我不得不提那次因为日志爆满导致系统崩溃的惨痛经历。凌晨三点收到报警短信，整个服务器因为/var/log被塞满而挂掉，那种绝望感至今记忆犹新。从那以后，我才真正明白日志管理不是简单的记录和保存，而是一门需要精心设计的艺术。特别是在高并发环境下，一个不合理的日志策略可能比没有日志更可怕。
日志轮转：别让日志变成”硬盘杀手”
还记得我第一次配置logrotate时的天真想法——”日志嘛，当然是保留越多越好”。结果一个月后发现100GB的硬盘被日志吃掉了80GB！现在我会根据不同日志的重要性设置不同的轮转策略：核心应用的错误日志保留30天，访问日志保留7天，调试日志只保留1天。使用logrotate时有个细节特别重要：copytruncate和create的区别，前者适合持续写入的日志文件，后者则可能导致日志丢失。
日志分级：从噪音中识别真正重要的信号
我曾经犯过一个典型错误——把所有日志都设置成DEBUG级别。天真的以为信息越详细越好，结果在排查问题时反而被海量的日志淹没了。现在的经验是：生产环境应该主要使用INFO及以上级别，DEBUG日志只在必要时开启。对于不同的服务组件，我通常会这样分级：Nginx访问日志用INFO，错误日志用WARN，核心业务逻辑用ERROR，调试信息用DEBUG。别忘了还要统一团队的日志级别标准，否则”重要”和”不重要”就全凭开发人员个人喜好了。
集中化管理：当你有超过三台服务器时
我的转折点是从手动登录每台服务器查日志，到搭建ELK(Elasticsearch+Logstash+Kibana)栈的那天。虽然初期配置费了些功夫，但之后排查跨服务器问题的效率提升了至少10倍。对于中小规模部署，我推荐使用Filebeat+ELK的组合；如果是云环境，AWS CloudWatch Logs或阿里云日志服务也是不错的选择。但要注意：集中化日志一定要考虑网络带宽和存储成本，我曾见过一个团队因为把所有DEBUG日志都发到中心服务器，导致每月产生上万元的云服务账单！
监控与告警：别等用户告诉你系统出问题了
最尴尬的情况莫过于：客户投诉系统异常，而你完全不知道发生了什么，因为相关日志已经被轮转覆盖了。现在我给所有关键业务日志都配置了监控规则：错误日志超过阈值触发告警，关键操作日志缺失触发告警，甚至日志体积异常增长也要告警。Prometheus+Grafana是经典组合，但新兴的方案如Loki也值得关注。记住一个原则：重要的不是收集多少日志，而是能从日志中发现多少有价值的信息。
日志管理看似简单，实则处处是坑。但当你经历过几次”没有日志可用”的绝望，就会明白这些实践的价值了。你有什么独特的日志管理经验？欢迎在评论区分享那些让你又爱又恨的日志故事。
评论