业务日志与系统日志分开放的好处

排查问题时在 /var/log/messages 里翻业务报错，是日志混放的典型症状。业务日志和系统日志分开存放，改造成本几乎为零，好处却很实在。 轮转策略各自独立 系统日志一天几 MB，业务日志高峰时一小时就能涨几百 MB，混在一起没法用同一套轮转参数。分开后，业务日志单独写配置：应用日志固定写到 /data/logs/app/，用 logrotate（Linux 日志轮转工具）单独管理，在 /etc/logrotate.d/myapp 里配： /data/logs/app/*.log { daily rotate 14 compress missingok notifempty copytruncate } 系统日志继续交给 rsyslog（系统日志服务）按默认规则管理，互不牵扯。业务日志量再大，也不会把系统日志的历史记录挤掉。应用自身也建议先分文件：访问日志写 access.log，错误日志写 error.log，两者的量级和轮转参数本来就不同，混在一个文件里，tail 的时候全是噪音。错误日志单独一份，告警脚本只盯它，访问日志留给统计分析，各干各的。 清理互不影响 磁盘紧张时能精确下手：df -h 看到是 /data 满了，直接去业务日志目录归档旧文件，/var/log 里需要留存的记录一份不动。反过来清系统日志时，也不会误伤正在写入的应用文件。混放时这种精确性不存在，只能一刀切，容易把要留的证据一起删掉。条件允许的话给日志单独划一个分区或配额，业务日志写爆了也不影响系统盘。 排查与审计路径更短 分工明确后，看内核和登录问题只查 /var/log/secure、dmesg，看业务错误直接 tail -f /data/logs/app/error.log，两边不用互相过滤噪音。从审计角度说也有分工：系统日志反映登录和权限变化，业务日志反映用户行为，安全事件排查要的是前者，业务纠纷排查要的是后者，分开存放，提取时互不干扰。字段格式顺手统一，一行一条结构化记录，日志采集器接起来省很多事。 Ubuntu 上用 journald 的注意一点：journal 默认可能不持久化，把 /etc/systemd/journald.conf 里的 Storage 设为 persistent，否则重启后日志会丢。建议应用上线那天就把日志路径规划进目录结构，事后迁移要改配置重启服务，不如一开始就分好。