CentOS 7中无专用“文件系统日志”配置项，需通过kern.*（内核级FS事件）和auditd（VFS系统调用级）协同实现：kern.warning /var/log/fs-kernel.log定向内核FS错误，auditd规则捕获open/write/mount等精确操作，并可由rsyslog转发归档。
rsyslog 中如何控制文件系统相关日志的输出路径和级别
CentOS 7 默认不单独记录“文件系统日志”，而是通过 kern.* 或 daemon.* 等 facility + priority 组合间接捕获内核级文件系统事件（如 ext4 错误、XFS I/O 超时、挂载失败等）。关键不是找“filesystem”专用配置项，而是定位真正产生这些日志的来源——通常是内核模块（kern）。
常见错误现象：修改了 /etc/rsyslog.conf 里 *.* /var/log/messages，但发现 /var/log/messages 里没有 mount/unmount 记录，或缺少 ext4 报错信息。
- 确认内核日志是否启用：检查
/proc/sys/kernel/printk，确保第 1 字段（console loglevel）≥ 4（即WARNING及以上），否则部分 fs 错误不会被 syslog 接收 - 在
/etc/rsyslog.conf中显式添加规则，避免被全局规则覆盖：kern.warning /var/log/fs-kernel.logdaemon.info /var/log/fs-daemon.log - 重启后验证：执行
logger -p kern.warning "test fs log"，再tail -1 /var/log/fs-kernel.log看是否写入
auditd 是唯一能精确捕获文件系统操作行为的日志机制
如果你要记录“谁在什么时候修改了哪个文件”，rsyslog 不行，必须用 auditd。它工作在内核审计子系统层，与 VFS 层联动，能抓到 open/write/unlink/mount 等系统调用。
容易踩的坑：直接改 /etc/audit/rules.d/ 下的文件却不 reload 规则，或规则语法写错导致整个 auditd 启动失败。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
- 添加监控规则前先停服务：
sudo systemctl stop auditd - 编辑
/etc/audit/rules.d/filesystem.rules，例如：-w /etc/passwd -p wa -k passwd_change-a always,exit -F arch=b64 -S openat,openat64 -F path=/data/ -k data_access - 加载规则：
sudo augenrules --load（不是systemctl restart auditd） - 查看效果：
sudo ausearch -k passwd_change | aureport -f -i
$ActionFileDefaultTemplate 对文件系统日志无效？
这个 rsyslog 模板只影响写入文件的日志格式（比如时间戳、主机名），但它**不决定哪些日志被写入、写到哪、是否写入**。很多人误以为改了模板就能“过滤出文件系统日志”，其实不能。
典型混淆点：把 $template FSFormat,... 和 if $programname == 'kernel' then ... 混用，但 $programname 在内核日志中通常是空或 kernel，而实际 kern.* 日志的 $syslogtag 是 kernel:（带冒号），匹配需写成 if $syslogtag == 'kernel:' then /var/log/fs.log;FSFormat。
- 模板本身必须定义在规则前，且名称区分大小写
- 使用
& stop阻止后续规则重复写入同一日志（否则可能同时出现在/var/log/messages和你自定义的/var/log/fs.log） - 测试模板是否生效：临时加一条
*.* /tmp/test.log;FSFormat，再logger test看格式
journalctl 无法按“文件系统”筛选？
journalctl 没有内置的 --unit=filesystem 这类选项。它只能按 service、unit、priority、syslog identifier 过滤。内核日志的 SYSLOG_IDENTIFIER 是 kernel，所以最接近的查法是：
-
sudo journalctl _TRANSPORT=kernel—— 只显示内核日志（含 ext4/xfs/btrfs 报错） sudo journalctl SYSLOG_IDENTIFIER=kernel | grep -i "ext4\|xfs\|mount\|umount"- 加时间范围更实用：
sudo journalctl _TRANSPORT=kernel --since "2 hours ago" - 注意：journal 日志默认不持久化，若
/var/log/journal未启用，重启后历史日志丢失
真正要长期归档文件系统异常，得靠 auditd + rsyslog 转发，或者直接解析 /var/log/audit/audit.log —— 这个文件里每条记录都带 syscall、path、uid、comm，才是“文件系统日志”的事实标准。其他所有方式都是间接或残缺的。
