日志太多，服务器先崩了
做过电商促销系统的人都懂，双十一零点一过，订单量瞬间翻几十倍。这时候最怕什么？不是数据库扛不住，而是日志把磁盘写爆了。
我们之前有个项目，每笔请求都打一条 DEBUG 级别的日志，还带着完整的请求体和响应体。高峰期一小时生成 80GB 日志，磁盘 IO 直接拉满，服务开始超时。最后发现，不是业务逻辑慢，是写日志太猛。
别让日志成为性能瓶颈
高并发下，日志本身就成了流量的一部分。如果处理不当，它会消耗大量 CPU、内存和磁盘资源。尤其是同步写日志、频繁刷盘、未分级记录这些操作，最容易出问题。
解决方案其实不复杂。第一，异步写入。用独立线程或队列处理日志输出，主流程只负责投递消息。比如用 Logback 的 AsyncAppender：
<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
<appender-ref ref="FILE" />
<queueSize>1024</queueSize>
<includeCallerData>false</includeCallerData>
</appender>按需记录，别啥都留
不是所有请求都需要完整记录。日常运行用 INFO 级别就够了，ERROR 和 WARNING 必须保留。DEBUG 日志可以只在特定条件下开启，比如通过动态配置中心临时打开某个模块的调试模式。
另外，采样记录也是个好办法。比如每 100 条请求只记录 1 条，既能保留现场，又不会压垮系统。像阿里内部很多服务就用这种策略做链路追踪采样。
集中收集，别散落各处
几百台机器各自写本地文件，查日志得登录每一台，这显然不行。得用统一的日志管道，比如 Filebeat 把日志发到 Kafka，再由 Logstash 解析存入 Elasticsearch。
这样做的好处不只是方便检索。当某台机器负载过高时，你可以快速判断是不是日志写得太猛，也能通过 Kibana 看到整体流量趋势，甚至结合监控告警自动触发限流。
冷热分离，备份要聪明
最近三天的日志访问频繁，放 SSD；超过一周的移到便宜存储，比如对象存储 OSS 或 HDFS。既控制成本，又保证可追溯性。
备份策略也得分级。核心交易日志保留 180 天，普通访问日志 30 天自动归档删除。用生命周期管理工具自动处理，避免人为遗漏。
高并发系统里，日志不是越多越好，而是越有效越好。管好了，它是排错利器；管不好，它就是压垮系统的最后一根稻草。