企业官网建设流程全解析

1. 这不是日志清单，而是一份Linux系统“数字尸检报告”操作手册

你有没有遇到过这样的场景：凌晨三点，监控告警疯狂闪烁，服务突然503，但top里CPU和内存都风平浪静；或者安全团队发来一份IP地址，说这个源在凌晨2:17尝试了17次SSH爆破，可你翻遍/var/log/auth.log，只看到两行成功的登录记录，其余踪迹全无；又或者渗透测试结束后，客户要求你提供“攻击路径复盘证据”，你打开日志目录，面对几十个文件名相似、格式各异、时间戳混乱的日志，像在考古现场面对一堆没编号的陶片——知道它重要，却不知从哪下手拼出真相。这不是运维新手的窘境，而是所有Linux系统从业者迟早要直面的“日志迷宫”。我干这行十多年，亲手处理过上千起线上故障、数百次安全事件响应和近百场红蓝对抗复盘，最深的体会是：Linux日志不是一堆文本文件，它是系统运行时留下的唯一、不可篡改（在合理配置下）、自带时间戳与上下文的“数字DNA”。它不告诉你“发生了什么”，但它会用精确到微秒的时间、完整的进程ID、调用栈的深度、甚至内核模块的加载状态，向你展示“事情是如何一步步走到这一步的”。今天这篇，不罗列/var/log/下所有文件名，也不堆砌journalctl命令大全。我要带你拆解的是：当故障排查、安全审计、渗透复盘这三类高压力、高时效性任务真正压下来时，你该盯住哪几条日志的哪几行？为什么是这几行？它们背后的数据结构如何保证其可信度？以及，如何在海量信息中，用最少的命令、最短的时间，精准定位那个决定性的“异常信号”。核心关键词——Linux、日志、故障排查、安全审计、渗透复盘——将贯穿每一个技术细节。无论你是刚考完RHCE的新手，还是管理着上万台服务器的SRE，只要你需要靠日志说话，这篇就是为你写的实战笔记。

2. 日志体系设计逻辑：为什么Linux不只有一份“日记本”，而是一个分层取证系统

2.1 三层日志架构：内核层、系统服务层、应用层，各司其职不可替代

Linux日志绝非一个简单的/var/log/messages就能概括。它的设计哲学是“分层归因”，每一层负责记录不同粒度、不同来源、不同可信度的信息。理解这个分层，是高效读取日志的前提。

• 内核层日志（Kernel Ring Buffer）：这是整个系统的“心跳记录仪”。所有硬件中断、驱动加载、内存分配失败、OOM Killer触发等底层事件，都会第一时间写入内核环形缓冲区（ring buffer）。它不依赖任何用户空间服务，即使rsyslog崩溃或磁盘满载，只要系统没宕机，这部分日志依然存在。dmesg命令读取的就是它。它的特点是：原始、高频、无格式化、易丢失（环形缓冲区大小有限）。一次PCIe设备热插拔，内核会瞬间刷出上百行pcieport 0000:00:1c.0: AER: ...，这些信息对排查硬件兼容性问题至关重要，但对分析一个Web服务超时毫无帮助。我见过太多人一上来就tail -f /var/log/messages，却忘了先dmesg -T | grep -i "error\|warn"看一眼内核是否在“呻吟”。

• 系统服务层日志（Systemd Journal + Rsyslog）：这是现代Linux的“中央档案馆”。systemd-journald作为systemd的原生日志守护进程，以二进制格式（.journal）统一收集所有systemd管理的服务、内核、用户会话的日志。它支持结构化字段（如_PID,_COMM,PRIORITY），可按服务名、时间范围、优先级精确过滤。rsyslog则是更传统的、高度可配置的“日志邮局”，它接收来自journald、网络设备、甚至其他应用的UDP/TCP日志，按规则路由到不同文件（如auth.log,syslog,kern.log）。它的优势在于持久化、可转发、可加密、可归档。当你需要把日志实时同步到SIEM平台，或设置logrotate按周压缩，rsyslog是唯一可靠的选择。journalctl和rsyslog不是替代关系，而是互补：journalctl用于快速交互式查询，rsyslog用于长期存储与合规审计。

• 应用层日志（Application-specific Logs）：这是“案发现场”的第一手证词。Nginx的access.log和error.log、MySQL的error.log和slow_query.log、Redis的redis-server.log，它们由应用自身控制格式和内容。其价值在于业务语义明确、上下文丰富。access.log里的一行192.168.1.100 - - [10/Jan/2024:02:17:33 +0000] "POST /api/login HTTP/1.1" 401 123 "-" "curl/7.68.0"，直接告诉你谁、何时、用什么工具、访问了哪个接口、返回了什么状态码。但它的致命弱点是完全依赖应用本身是否健壮。一个有bug的Python脚本可能根本不会写日志，或者把错误信息全打在stdout里被journald捕获，而自己的app.log一片空白。所以，应用日志永远是“补充”，而非“唯一”。

提示：不要迷信/var/log/目录下的文件名。messages在RHEL/CentOS里是rsyslog的默认输出，但在Ubuntu里可能只是journald的一个软链接。真正的权威来源永远是journalctl --list-boots和rsyslogd -N1（验证配置语法）。

2.2 时间戳：日志可信度的基石，也是最容易被忽略的“破案线索”

所有日志的价值，都建立在一个前提上：时间戳必须准确且一致。我处理过一个案例，某金融客户的核心交易系统出现间歇性延迟，/var/log/syslog显示数据库连接池耗尽，但/var/log/mysql/error.log里同一时刻只有几条无关紧要的警告。最终发现，数据库服务器的NTP服务异常，时间比应用服务器快了整整3分钟。所有日志的时间线都是错位的，导致排查方向完全错误。Linux日志的时间戳有三个关键层级：

1. 内核时间戳（dmesg）：基于系统启动后的单调时钟（monotonic clock），不受NTP调整影响，绝对可靠，但只记录相对启动时间。dmesg -T会将其转换为本地时间，但转换依赖于当前系统时间，若系统时间不准，转换结果也无效。

2. journald时间戳：systemd-journald使用CLOCK_REALTIME，即系统实时时钟。它会随NTP同步自动校正，因此是最推荐用于跨服务关联分析的时间基准。journalctl --since "2024-01-10 02:15:00"能精准定位到毫秒级。

3. 应用日志时间戳：完全由应用自身决定。PHP的error_log()、Java的log4j、Python的logging模块，都允许自定义格式。很多老旧应用甚至只记录小时和分钟（[10/Jan/2024:02:17]），丢失了秒级精度。在渗透复盘中，如果攻击者利用了一个时间窗口极小的漏洞（如JWT token重放），缺少秒级精度的日志，会让你永远无法确认攻击发生的确切顺序。

注意：journalctl的--since和--until参数，其时间解析能力远超grep。journalctl --since "2 hours ago"比grep "Jan 10 02:" /var/log/syslog可靠一万倍，因为它直接查询二进制索引，而非逐行扫描文本。

2.3 日志级别（Priority Level）：不是噪音过滤器，而是事件严重性的“分级警报系统”

PRIORITY=3（ERR）、PRIORITY=6（INFO）、PRIORITY=7（DEBUG）这些数字，不是为了让你grep -v "INFO"来减少屏幕输出，而是系统内置的事件严重性分级协议。rsyslog的/etc/rsyslog.conf里，*.info表示记录所有INFO及以上级别的日志，auth.*则表示记录所有认证相关的日志，无论级别。这意味着，一条PRIORITY=3的sshd日志，其权重天然高于一条PRIORITY=6的cron日志。在故障排查的黄金30分钟里，你应该首先聚焦PRIORITY=2（CRIT）和PRIORITY=3（ERR）的日志。例如：

# 快速定位所有ERROR级别以上的系统级事件 journalctl -p err..emerg --since "1 hour ago" # 精准抓取认证服务的ERROR，排除大量INFO干扰 journalctl -u sshd -p err --since "10 minutes ago"

而安全审计，则需反其道而行之：PRIORITY=6（INFO）的sudo命令执行记录，其价值远高于PRIORITY=3的某个服务重启。因为sudo的INFO日志里，包含了完整的命令行、执行用户、TTY终端，这才是溯源的关键。journalctl -u systemd-logind -o json | jq 'select(.MESSAGE | contains("New session"))'，这条命令能提取所有新用户会话的创建时间，是排查横向移动的第一步。

3. 核心日志详解：故障排查、安全审计、渗透复盘的“黄金三件套”

3.1/var/log/auth.log（或/var/log/secure）：安全审计的“指纹数据库”

这是Linux安全审计的绝对核心。它由rsyslog的auth和authpriv设施（facility）生成，记录所有与身份认证、权限提升、密钥管理相关的事件。其价值不在于“有多少次失败”，而在于“每一次失败的完整上下文”。

• SSH暴力破解的完整画像：一条典型的失败登录记录是：

  Jan 10 02:17:22 server sshd[12345]: Failed password for invalid user admin from 192.168.1.200 port 54321 ssh2 Jan 10 02:17:23 server sshd[12345]: Connection closed by invalid user admin 192.168.1.200 port 54321 [preauth]

  注意这里的关键信息：invalid user admin（用户名不存在）、from 192.168.1.200（源IP）、port 54321（源端口）、[preauth]（认证前断开）。这与一次正常的密码错误（Failed password for user john）有本质区别。前者是自动化扫描，后者可能是用户输错密码。我通常会用这条命令快速统计：

  # 统计1小时内所有失败登录，并按IP和用户名分组 journalctl -u sshd --since "1 hour ago" | grep "Failed password" | awk '{print $11, $9}' | sort | uniq -c | sort -nr | head -20

  输出如17 192.168.1.200 admin，立刻就能锁定攻击源和目标用户名。

• sudo提权的“行为审计链”：sudo日志是渗透复盘的金矿。它不仅记录“谁执行了什么”，还记录“在哪执行”、“用了什么环境变量”。一条典型记录：

  Jan 10 02:18:01 server sudo: john : TTY=pts/1 ; PWD=/home/john ; USER=root ; COMMAND=/bin/bash

  这里TTY=pts/1表明是在一个交互式终端执行，PWD=/home/john是工作目录，USER=root是目标用户，COMMAND=/bin/bash是具体命令。如果攻击者通过sudo -i获得root shell，这条记录就是无可辩驳的证据。更关键的是，sudo日志会记录后续在这个shell里执行的所有命令（如果sudoers配置了logfile），形成完整的命令链。

• pam_faillock模块：让失败登录“留下永久伤疤”：这是现代Linux（RHEL 8+/Ubuntu 20.04+）的标配。它会在/var/run/faillock/下为每个用户创建一个二进制锁文件，记录失败次数、时间、IP。faillock --user john能直接查看。在安全审计中，这比单纯看auth.log更可靠，因为faillock数据独立于rsyslog，即使日志服务被停，数据仍在。faillock --user john --reset是管理员手动解锁的命令，这个操作本身也会被记录在auth.log里，形成审计闭环。

实操心得：auth.log的默认权限是600，只有root可读。但这恰恰是安全审计的起点——如果你无法以root身份读取它，说明你的审计权限已被剥夺，这本身就是最高级别的安全事件。

3.2/var/log/syslog（或/var/log/messages）：故障排查的“系统健康总览图”

这是系统级事件的汇总日志，由rsyslog的*.*规则生成，覆盖内核、网络、存储、服务启停等几乎所有方面。它的价值在于“广度”，是故障排查时的第一张“全景地图”。

• 服务启停的“时间锚点”：当一个Web服务突然不可用，第一步不是查Nginx日志，而是查syslog里它的启停记录：

  # 查看nginx服务在过去1小时内的所有状态变更 journalctl -u nginx --since "1 hour ago" --no-pager | grep -E "(started|stopped|failed)"

  如果看到nginx.service: Main process exited, code=killed, status=9/KILL，那基本可以确定是OOM Killer干的，接下来就该去dmesg里找Out of memory: Kill process了。如果看到nginx.service: Failed with result 'exit-code'，则说明是配置错误或依赖缺失，需要检查nginx -t。

• 磁盘I/O瓶颈的“无声警报”：当iostat显示%util接近100%，但top里没有进程CPU高，问题往往在syslog。内核会持续记录ata、nvme、sd设备的错误：

  kernel: nvme nvme0: I/O 12345 timeout, reset controller kernel: sd 0:0:0:0: [sda] tag#12345 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK

  这些日志意味着硬件层面的I/O超时，可能是SSD固件bug、RAID卡故障或电源不稳。此时smartctl -a /dev/sda的输出，往往已经晚了，因为syslog里的错误是硬件发出的“求救信号”。

• 网络连接的“状态快照”：syslog会记录NetworkManager、systemd-networkd的详细状态。当一个服务无法访问外网，ping不通，先看：

  # 查看网络服务的最新状态 journalctl -u NetworkManager --since "5 minutes ago" | grep -E "(disconnected|connected|failed)" # 查看DNS解析是否正常 journalctl -u systemd-resolved --since "5 minutes ago" | grep "Using DNS servers"

  我曾遇到一个案例，curl https://google.com超时，ping 8.8.8.8成功，nslookup google.com失败。syslog里赫然写着systemd-resolved: Failed to resolve 'google.com': Server returned error NXDOMAIN，根源是/etc/resolv.conf被一个脚本错误地覆盖为nameserver 127.0.0.1，而本地dnsmasq服务并未运行。

注意：syslog的体积巨大，logrotate是必备项。但/var/log/syslog.1.gz里的日志，zcat /var/log/syslog.1.gz | grep "error"是低效的。正确做法是zgrep "error" /var/log/syslog.1.gz，它直接在压缩流中搜索，速度提升10倍以上。

3.3/var/log/kern.log：内核层的“手术室直播”

这是rsyslog专门分离出来的内核日志，等价于dmesg的持久化版本。它不记录用户空间事件，只专注硬件、驱动、内存、调度器的底层行为。它是诊断“系统级顽疾”的终极武器。

• OOM Killer的“处决令”：当系统内存耗尽，OOM Killer会选择一个进程杀死。kern.log里会留下完整的“判决书”：

  Out of memory: Kill process 12345 (java) score 852 or sacrifice child Killed process 12345 (java) total-vm:2048000kB, anon-rss:1536000kB, file-rss:0kB

  这里score 852是OOM分数，越高越可能被杀；total-vm是虚拟内存大小；anon-rss是实际占用的物理内存。如果anon-rss远小于total-vm，说明是内存泄漏；如果两者接近，说明是应用真的需要这么多内存。ps aux --sort=-%mem | head -5只能看到“谁吃得多”，而kern.log告诉你“谁被杀了”以及“为什么杀它”。

• 硬件故障的“早期预警”：现代服务器的BMC（基板管理控制器）会通过IPMI将硬件传感器数据（温度、电压、风扇转速）上报给内核，内核再写入kern.log：

  kernel: iTCO_wdt: Found a Intel PCH TCO device (Version=2, TCOBASE=0x0400) kernel: EDAC MC0: 1 CE memory event(s) on MC0 kernel: mce: CPU0: Machine check events logged

  EDAC MC0表示内存控制器检测到1次可纠正错误（Correctable Error），这是内存条开始老化的征兆；Machine check events则是CPU内部的硬件错误，往往预示着CPU即将失效。这些日志在dmesg里一闪而过，但kern.log会永久保存，是预测性维护的唯一依据。

• 内核模块的“加载日志”：当一个新驱动（如GPU驱动nvidia.ko）或安全模块（如apparmor）加载时，kern.log会记录其初始化过程：

  kernel: nvidia: module license 'NVIDIA' taints kernel. kernel: nvidia: loading out-of-tree module taints kernel. kernel: nvidia-uvm: Loaded the UVM driver, major device number 510.

  如果一个服务依赖特定内核模块（如nf_conntrack用于防火墙），而kern.log里没有它的加载记录，那问题一定出在模块未加载或加载失败。

提示：kern.log的默认权限是640，adm组可读。这意味着普通运维人员无需root权限，就能查看硬件健康状况，这是安全设计的精妙之处——将监控权限与管理权限分离。

4. 实战场景拆解：用日志完成一次完整的“数字尸检”

4.1 故障排查：一个Web服务503错误的15分钟定位流程

假设你收到告警：https://api.example.com/v1/users返回503。以下是标准操作流程，每一步都对应一个日志源。

第1-2分钟：确认服务状态与基础资源

# 1. 检查nginx服务是否在运行 systemctl is-active nginx # 如果是inactive，跳转到syslog查启停原因 # 2. 检查后端应用（假设是Python Flask）是否存活 systemctl is-active myapp # 如果是inactive，立即journalctl -u myapp --since "5 minutes ago" # 3. 检查系统资源（内存、磁盘） free -h && df -h # 如果磁盘100%，直接去/var/log/syslog查是否有"no space left on device"

第3-5分钟：聚焦syslog与auth.log

# 4. 查看nginx最近的错误 journalctl -u nginx --since "10 minutes ago" | grep -i "error\|fail\|refuse" # 5. 查看后端应用的错误（如果myapp是systemd服务） journalctl -u myapp --since "10 minutes ago" | grep -i "exception\|traceback\|segmentation" # 6. 检查是否有大量连接被拒绝（网络层问题） journalctl -u systemd-networkd --since "10 minutes ago" | grep -i "connection refused"

常见发现：nginx日志显示upstream timed out (110: Connection timed out)，指向后端。myapp日志为空，说明问题不在应用代码。

第6-10分钟：深入kern.log与dmesg

# 7. 检查内核是否有OOM或I/O错误 dmesg -T | grep -i "out of memory\|kill process\|timeout" # 8. 检查磁盘I/O是否异常 iostat -x 1 3 # 如果%util持续100%，查kern.log journalctl -u systemd --since "10 minutes ago" | grep -i "block"

常见发现：kern.log里有nvme nvme0: I/O 12345 timeout，结合iostat的r_await和w_await极高，确认是SSD硬件故障。

第11-15分钟：结论与修复

• 结论：SSD硬件故障导致I/O阻塞，进而使myapp数据库连接超时，nginx上游超时，最终返回503。
• 修复：更换SSD，重启myapp和nginx。
• 验证：curl -I https://api.example.com/v1/users返回200 OK。

实操心得：这个流程里，journalctl的--since参数是灵魂。--since "10 minutes ago"比tail -n 100 /var/log/syslog可靠，因为它基于时间戳索引，而非行数。tail可能漏掉关键的、位于文件开头的早期错误。

4.2 安全审计：一次可疑sudo提权事件的完整溯源

假设安全团队通报：userA在2024-01-10T02:17:00Z执行了sudo /bin/bash。你需要证明这是授权行为还是入侵。

第1步：定位原始日志

# 在auth.log中精确查找该时间点的记录 journalctl -u sshd --since "2024-01-10 02:16:00" --until "2024-01-10 02:18:00" | grep "userA" # 输出：Jan 10 02:17:01 server sudo: userA : TTY=pts/0 ; PWD=/home/userA ; USER=root ; COMMAND=/bin/bash

第2步：关联会话与登录源

# 查找userA在同一时间的登录会话 journalctl -u systemd-logind --since "2024-01-10 02:16:00" --until "2024-01-10 02:18:00" | grep "userA" # 输出：New session 1234 of user userA. (TTY=pts/0, FROM=192.168.1.100) # 查找该IP的SSH登录记录 journalctl -u sshd --since "2024-01-10 02:16:00" --until "2024-01-10 02:18:00" | grep "192.168.1.100" # 输出：Accepted password for userA from 192.168.1.100 port 54321 ssh2

第3步：检查sudoers策略与历史

# 查看userA的sudo权限 sudo -l -U userA # 输出：(ALL) NOPASSWD: /bin/bash # 检查`sudo`的审计日志（如果配置了） grep "userA" /var/log/sudo.log # 可能包含更详细的命令行参数

第4步：交叉验证与结论

• 时间线：02:16:55，192.168.1.100成功登录；02:17:01，userA执行sudo /bin/bash；02:17:05，userA退出root shell。
• 权限：sudoers明确授权，无需密码。
• 结论：这是一次合规的、有据可查的提权操作，非安全事件。

注意：如果sudoers里没有NOPASSWD，而日志里也没有密码输入记录，那sudo命令就不可能成功执行，这本身就是矛盾点，需要进一步调查sudo配置或日志完整性。

4.3 渗透复盘：红队攻击路径的“日志证据链”构建

假设红队报告：他们通过userB的弱密码SSH登录，然后利用sudo漏洞（CVE-2021-3156）提权至root，并修改了/etc/passwd。你需要从日志中还原完整路径。

第1步：定位初始访问

# 查找userB的所有SSH登录 journalctl -u sshd --since "2024-01-10" | grep "userB" # 输出：Jan 10 02:17:22 server sshd[12345]: Accepted password for userB from 10.0.0.5 port 12345 ssh2 # 这里`10.0.0.5`是红队的C2服务器IP，非内网IP，是第一个异常点。

第2步：追踪提权行为

# 查找userB的sudo行为 journalctl -u sshd --since "2024-01-10" | grep "userB" | grep "sudo" # 输出：Jan 10 02:17:30 server sudo: userB : TTY=pts/0 ; PWD=/home/userB ; USER=root ; COMMAND=/usr/bin/sudoedit -s /tmp/shell # 关键！`sudoedit -s`是CVE-2021-3156的典型利用方式

第3步：确认root shell与文件修改

# 查找root用户的活动 journalctl -u sshd --since "2024-01-10" | grep "root" | grep "pts" # 输出：Jan 10 02:17:35 server sshd[12346]: Started session 1235 of user root. # 查找/etc/passwd的修改时间（inode change time） stat /etc/passwd # 输出：Change: 2024-01-10 02:17:40.123456789 +0000 # 在syslog中查找该时间点附近的文件系统事件 journalctl --since "2024-01-10 02:17:35" --until "2024-01-10 02:17:45" | grep -E "(passwd|chmod|chown)" # 输出：Jan 10 02:17:40 server audit[12346]: SYSCALL arch=c000003e syscall=257 success=yes ... comm="vim" ... name="/etc/passwd"

第4步：构建完整证据链

1. 02:17:22：userB从外部IP10.0.0.5登录。
2. 02:17:30：userB执行恶意sudoedit命令，触发漏洞。
3. 02:17:35：root会话启动。
4. 02:17:40：vim修改/etc/passwd，audit日志记录。 所有时间点紧密衔接，IP来源异常，命令模式匹配已知漏洞，形成铁证链。

实操心得：auditd（Linux审计守护进程）是渗透复盘的终极利器。它能记录execve系统调用的完整参数，比sudo日志更底层、更难绕过。ausearch -m execve -ts recent | aureport -f -i能直接列出所有被执行的命令及其参数。

5. 常见问题与独家避坑技巧实录

5.1 “日志查不到”：不是日志没了，而是你没找对地方

问题现象：grep "error" /var/log/syslog返回空，但dmesg里明明有Out of memory。

根本原因：rsyslog的默认配置可能将kern.*日志路由到了/var/log/kern.log，而不是/var/log/syslog。/var/log/syslog只包含*.*;kern.none。

解决方案：

1. 检查/etc/rsyslog.conf，找到kern.*这一行，确认其目标文件。
2. 直接查/var/log/kern.log：grep -i "out of memory" /var/log/kern.log。
3. 更通用的方法：journalctl -p err..emerg，它不依赖rsyslog配置，直接从journald二进制库查询。

避坑技巧：永远不要假设/var/log/syslog是“万能日志”。用ls -la /var/log/看看哪些文件最近被写入，用file /var/log/*.log看看哪些是纯文本，哪些是二进制（journald的.journal文件）。

5.2 “日志时间对不上”：NTP漂移与夏令时陷阱

问题现象：auth.log里02:17的登录，syslog里却是01:17。

根本原因：系统时区设置错误，或NTP服务未启用。Linux默认使用UTC时间存储日志，rsyslog根据/etc/timezone或timedatectl设置转换为本地时间显示。如果时区配置为Asia/Shanghai，但系统时间是UTC，就会差8小时。

解决方案：

1. 统一检查：timedatectl status，确认System clock synchronized: yes和Time zone: Asia/Shanghai (CST, +0800)。
2. 强制同步：sudo systemctl restart systemd-timesyncd。
3. 对于journald，时间戳是UTC，journalctl --utc可强制以UTC显示，避免混淆。

避坑技巧：在多时区团队协作时，所有日志分析命令一律加上--utc参数，如journalctl --utc --since "2024-01-10 02:17:00 UTC"，确保时间基准绝对一致。

5.3 “日志被删了”：logrotate的温柔刀与journald的自动清理

问题现象：/var/log/syslog.1.gz存在，但/var/log/syslog为空，且journalctl也查不到昨天的日志。

根本原因：journald的/var/log/journal/目录有磁盘配额，默认可能只保留最近3天的日志。logrotate的/etc/logrotate.d/rsyslog配置了rotate 7，但compress后可能被误删。

解决方案：

1. 检查journald配额：journalctl --disk-usage，sudo journalctl --vacuum-time=30d可手动保留30天。
2. 检查logrotate状态：sudo logrotate -d /etc/logrotate.d/rsyslog（dry-run模式），看它计划如何处理。
3. 永久方案：编辑/etc/systemd/journald.conf，设置SystemMaxUse=1G和MaxRetentionSec=3month。

避坑技巧：journalctl --list-boots是你的“日志时间机器”。它会列出所有系统启动记录，journalctl --boot=-1可以查看上一次启动的所有日志，即使/var/log/journal/被清空，只要/run/log/journal/（内存中的临时日志）还在，就能找回。

5.4 “日志看不懂”：结构