先看现象。排查故障时发现某段时间的日志整段缺失，查询时提示有消息被抑制，可应用明明一直在报错，重启服务之后日志才又恢复正常。
原因不止一个，得分开看。默认对同一服务做速率限制。还有一种是短时间刷了大量相同的日志。
少数情况下是限流参数没有按业务调整。
先确认是否被限流
journalctl -u app | grep -i suppressed然后看当前限流配置
grep -i ratelimit /etc/systemd/journald.conf接着放宽突发条数
sed -i 's/^#RateLimitBurst=.*/RateLimitBurst=10000/' /etc/systemd/journald.conf等前面都确认过，再重启服务确认
systemctl restart systemd-journald同事提醒我看一下最近一次发布，时间点确实对得上。
命令输出我都留了记录，免得改完记不清原来的值。
改之前先确认了最近有没有人动过配置，避免白查一遍。
恢复的判定其实很直接。复现故障时日志完整，查询不再提示有消息被抑制。
限流本身是保护磁盘的手段，关掉之后一定要配合轮转策略和容量告警，否则日志量会把分区写满，排查故障反而更难。这类问题最好一次改到位，反复小改反而容易把原因搅混。