关于日志集中告警的五个误解

保留 180 天不是数字游戏，是为了能回溯三个月前的一次异常，到期前先确认冷数据查得回来

下面五条，每条都能对应一个真实的事故模式。

先说结论

误解的共同点是：把「降低概率」当成「消除风险」。

• 误解一：有 WAF 就安全
• 误解二：内网系统不用管
• 误解三：修完就没事了
• 误解四：低危可以先放着
• 误解五：加密了就安全了

误解一：有防护设备就安全

采集端必须有本地缓冲，网络抖动时直接丢弃是很常见的设计缺陷，缓冲要按峰值流量算足，磁盘也要预留一倍。

WAF 挡的是已知模式，绕过的成本往往是「改个编码」级别。它能降噪，不能当唯一防线。

误解二：内网不用管

全文索引的成本是原始存储的五到十倍，冷数据应该只做归档，超过 30 天的查询本来就少，归档要能查回来。

内网的前提是「边界真的存在」。一旦有一台机器被钓鱼，内网就是平的。

误解三：修完就没事了

所有日志都开 debug，磁盘一周就写满

修复要覆盖：同一入口的其它路径、同类代码的其它位置、以及历史数据。

这个问题的几个常见误判

实际评估时最容易被带偏的几条：

• 告警分级没有出口规则，P1 会被 P3 淹没，最后没人再看，分级没有出口等于没有分级，出口规则要写下来
• 时间戳统一到 UTC，跨时区排查时本地时间会误导判断

误解四与五

多个低危串起来常常就是一条完整链路：信息泄露、越权、拿后台。加密解决的是机密性，解决不了「密钥在代码里」和「加密了但没验签」。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• 日志量失控的主因是 debug 级别误开到生产，能占到总量的七成
• 保留 180 天不是数字游戏，是为了能回溯三个月前的一次异常，到期前先确认冷数据查得回来
• 告警全发到同一个群，两周后全员免打扰
• 采集端不做缓冲，重启期间的日志全丢

安全里最贵的一句话是「应该没问题吧」。