日志监控需有选择地捕获关键信号，核心是服务问题定位与系统健康判断。应按服务类型分级设置日志级别：系统日志用*.warn；web服务错误日志保留error级；数据库仅开slow_query_log并设阈值；统一用logrotate按大小轮转、压缩、限保留14天，并监控日志系统自身健康状态。
日志监控不是记流水账，而是有选择地捕获关键信号。核心在于让日志真正服务于问题定位和系统健康判断，而不是拖慢系统或填满磁盘。
按服务类型分级设置日志级别
不同组件对日志的敏感度和开销差异很大，统一设为 debug 或 info 往往得不偿失。
-
系统日志（rsyslog）：生产环境建议用
*.warn;authpriv.*，避免 info 级别泛滥；调试阶段可临时切到*.info，但需配合轮转策略 -
Web 服务（Nginx/Apache）：错误日志保留
error级别足够；访问日志若非必要分析，可关闭或只记录异常状态码（如 4xx/5xx） -
数据库（MySQL/PostgreSQL）：关闭 general_log，仅开启 slow_query_log 并设合理阈值（如 >1s），错误日志保持
error或warning
用 logrotate 控制日志体积与生命周期
再合理的日志级别，长期不清理也会撑爆磁盘或拖慢 I/O。logrotate 不是“开了就行”，关键在参数取舍。
-
按大小而非时间轮转：对高吞吐服务（如 API 网关），用
size 100M比daily更可靠，避免单日产生数十个大文件 -
压缩旧日志：启用
compress和delaycompress，既节省空间又保留最新一份未压缩便于快速查看 -
限制保留数量：
rotate 14比rotate 90更务实，多数故障回溯 rarely 超过两周 -
避免中断写入：加上
copytruncate（适用于无法 reload 的进程），防止轮转时丢失日志
把日志当指标源，而非仅靠人工翻查
高频日志本身就能反映性能趋势，主动提取比事后排查更高效。
-
统计关键错误频率：例如用
grep "Connection refused" /var/log/nginx/error.log | wc -l配合 cron 每小时汇总，突增即告警 -
关联性能数据：将
dmesg中的 OOM 或硬件报错，与vmstat 1的so（swap out）或cs（上下文切换）峰值对齐，确认是否真由内存或调度引发 - 过滤敏感字段再入库：若用 ELK 或 Loki 做集中分析，预处理阶段移除 IP、token、密码等，既保安全又减索引体积
监控日志自身的健康状态
日志系统出问题常被忽略，直到故障发生才发觉无迹可寻。
-
检查 rsyslog 进程存活：
systemctl is-active rsyslog加入基础巡检脚本 -
验证写入权限与磁盘空间：定期运行
df -h /var/log和ls -l /var/log/syslog*，确保日志文件可写且未被误删 -
留意内核缓冲区溢出：
dmesg -T | grep -i "buffer overrun"，若频繁出现，说明日志产生速率远超落盘能力，需降级或分流
