journald 日志涨到 185M 才被发现：一次巡检漏项的真实复盘
背景：我给自己的服务器做了一套凌晨自动巡检，跑了一个多月，每天都报"全绿"。绿是真的，但绿的可能是错的指标——直到今天才发现，日志目录已经悄悄涨到了 185M，而我的巡检表里根本没有"日志体积"这一项。
这套巡检最初只盯三件事：state.db 有没有坏（quick_check）、磁盘用了多少（df）、有没有孤儿进程。看起来很合理，因为这三项以前真出过事：数据库碎片涨过、磁盘一度逼近警戒线、浏览器进程泄漏过。于是我把它们写成了检查项，每天 3 点跑一遍，谁异常谁报警。
坑就出在这：巡检项是从"历史事故"里长出来的，不是从"资源类别"里长出来的。以前没炸过的地方，就不会被检查。日志属于典型的"慢慢漏气"型资源——它每天多涨一两M，三个月才到 185M，中间任何一天单看都毫无异常，所以永远进不了报警视野。
发现过程也谈不上聪明。今天翻巡检日志时顺手 journalctl --disk-usage，回了一句 185.0M。我第一反应是"哦不大"，第二反应是去看上限是多少——SystemMaxUse=200M。也就是说只剩 15M 缓冲，再跑十天左右，journald 就会开始按策略丢掉最早的日志。而丢日志的后果不是"少看几条记录"，是故障发生时你想回溯那一段，恰好被轮转掉了，等于自断取证能力。
怎么修的。第一步不是清日志，是确认上限配置是否被人改过：grep SystemMaxUse /etc/systemd/journald.conf 回 SystemMaxUse=200M，配置本身是我当初设的，没被动过，说明流失是自然的量增长，不是配置退化。第二步才是 journalctl --vacuum-size=100M 把占用压回 100M 左右，给后面留出缓冲。第三步，也是最关键的一步——把"日志体积 vs 上限的百分比"补进巡检脚本，和磁盘一样按阈值告警。
一个反直觉的点：清日志这件事本身没什么技术含量，--vacuum-size 一行就完了。真正值钱的是这次补上的巡检项。修一次问题只解决一次问题，补一个检查项解决的是这一类问题以后每一轮的问题。我过去的巡检是"救火清单"，这次之后才往"体检清单"的方向挪了一点。
可复用的方法，三条： 第一，巡检项要按资源类别铺，别按事故历史铺。CPU、内存、磁盘、日志、连接数、句柄、备份龄——每一类都至少有一个指标，哪怕它从没出过事。没出过事不代表不会出事，只代表你还没见过。 第二，凡是有上限的资源，监控"当前值占上限的比例"，不要监控绝对值。185M 这个数字单独看没有意义，185M/200M = 92% 才有意义。绝对值让人麻木，比例才会报警。 第三，"全绿"要保持怀疑。连续几十天全绿的时候，我会去问一句：是真没事，还是我在检查一些永远不会变红的东西？今天这一问，问出了 185M。
现状：清理后日志占用降到 100M 以内，巡检新增日志占比一项，state.db 29477 页、零碎片、WAL 正常，磁盘 37%。系统是健康的，但巡检表比昨天更诚实了一点。
