journald 通过内置机制实现二进制日志滚动、归档与压缩，需启用持久化（Storage=persistent）、压缩（Compress=yes）及体积/时间限制（如SystemMaxUse、MaxFileSec等）协同控量，并配合速率限制防日志洪水。
journald 本身不提供传统意义上的“轮转”（如 logrotate 那样重命名、切割文本文件），它的日志管理是基于二进制文件自动滚动、归档与压缩的内置机制。配置重点在于控制日志生命周期、磁盘占用和压缩行为，而非手动切分文件。
启用持久化存储并开启压缩
默认情况下，journald 可能只在内存中（/run/log/journal/）暂存日志，重启即丢失。要让压缩和长期管理生效，必须启用持久化：
- 确保
/var/log/journal/目录存在：sudo mkdir -p /var/log/journal - 编辑
/etc/systemd/journald.conf，取消注释并设置： Storage=persistent
Compress=yes - 重启服务生效：
sudo systemctl restart systemd-journald
注意：Compress=yes 仅对已归档的旧日志文件（.journal~）做 gzip 压缩，不影响正在写入的活跃日志文件，也不降低实时写入压力。
限制日志体积与保留周期
靠压缩不能解决磁盘爆满问题，关键要主动控量。以下参数需协同设置：
- SystemMaxUse=800M：硬性限制日志总占用空间上限
- SystemKeepFree=2G：预留至少 2GB 空闲空间，避免触发紧急清理加重 IO
- MaxFileSec=12h 或 MaxFileSec=1day：缩短单个日志文件存活时间，加快轮转节奏
- SystemMaxFileSize=64M：限制单个日志文件最大体积，防止大文件刷盘阻塞
这些设置共同作用，把集中式大 IO 拆成更细粒度、更可控的小操作。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
配合速率限制防日志洪水
高并发场景下，应用疯狂打日志，journald 写入、索引、压缩全会成为瓶颈。压缩无法阻止洪水，必须限流：
- RateLimitIntervalSec=30s
- RateLimitBurst=5000
表示每 30 秒最多接收 5000 条日志，超出部分直接丢弃（可接受）。建议先用 journalctl --since "30s ago" | wc -l 实测当前速率，再设合理阈值。
验证与日常维护
配置后务必验证是否生效：
- 查看当前磁盘占用：
journalctl --disk-usage - 检查配置加载状态：
systemctl show systemd-journald | grep -E "(Storage|Compress|Max)" - 手动触发一次清理（谨慎）：
sudo journalctl --vacuum-size=500M或--vacuum-time=2weeks
不要依赖 logrotate 处理 /var/log/journal/ 下的文件——那是 journald 自己管理的二进制数据，外部轮转会破坏索引结构，导致日志不可读。
