auditd需通过系统调用级监控（execve、exit、exit_group）绑定进程上下文，精准捕获关键服务启动与退出事件；应按启动方式（systemd或直接exec）配置针对性规则，使用key标签便于检索，并结合ausearch/aureport验证与分析。
要让 auditd 真正盯住关键服务的进程生命周期（启动、运行、退出），不能只监控二进制文件执行，而需捕获系统调用级事件，并绑定进程上下文。重点在于精准匹配目标服务的启动方式（如 systemd 启动、手动 systemctl 调用或直接 exec）、区分守护进程与子进程，并确保退出状态可追溯。
明确你要监控的关键服务及其启动机制
不同服务启动方式差异大，规则必须适配：
-
systemd 管理的服务（如 nginx、sshd、redis）：实际由
/usr/lib/systemd/systemd派生，但真正执行的是服务单元指定的ExecStart=二进制（如/usr/sbin/nginx）；应优先监控该路径的execve -
非 systemd 启动的服务（如某些自研 daemon 直接运行）：需监控其绝对路径，例如
/opt/app/bin/server -
避免误捕：不用
-F path=/bin/bash这类泛路径，否则会混入大量 shell 启动日志；也不建议监控systemctl本身（它只是控制接口），而应监控被控服务的真实进程。
配置精准的审计规则（推荐使用 augenrules）
将以下规则保存为 /etc/audit/rules.d/service-lifecycle.rules，再执行 sudo augenrules --load 加载：
-
-a always,exit -F arch=b64 -S execve -F path=/usr/sbin/nginx -F key=nginx-start—— 捕获 nginx 主进程启动 -
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/redis-server -F key=redis-start—— 捕获 redis-server 启动 -
-a always,exit -F arch=b64 -S exit,exit_group -F key=service-exit—— 记录所有进程退出事件（后续按 pid 或 comm 过滤） -
-w /proc/sys/kernel/pid_max -p r -k service-pid-check（可选）—— 辅助判断是否发生异常 PID 耗尽导致服务无法拉起
说明：-F key=xxx 是后续快速检索的核心标签；-S exit,exit_group 必须包含两者，因不同内核版本或 libc 实现可能触发任一调用。
验证规则是否生效并提取完整生命周期
不要等故障发生才查，主动测试：
- 重启服务：
sudo systemctl restart nginx - 确认启动记录：
sudo ausearch -k nginx-start -i | grep "comm=\"nginx\"" - 手动停止服务：
sudo systemctl stop nginx - 查找对应退出事件：
sudo ausearch -m exit -i -k service-exit | grep -A2 -B2 "comm=\"nginx\""，关注exit=0（正常）或exit!=0（异常终止） - 若无记录，检查：
sudo auditctl -s是否报错；sudo systemctl status auditd是否 active；SELinux 是否拦截（临时setenforce 0测试）
增强可读性与运维可用性
原始日志字段多、难读，建议结合 aureport 和简单脚本做聚合：
- 生成今日服务启停简报：
sudo aureport --start today -x --key nginx-start,redis-start --summary - 导出带时间、用户、命令、退出码的 CSV：
sudo ausearch -k nginx-start -m execve,exit -i --format csv > nginx-life.csv - 设置日志轮转防爆满：
sudo nano /etc/audit/auditd.conf，调整max_log_file = 20（MB）、num_logs = 10，然后sudo systemctl restart auditd
规则越聚焦，日志越干净；退出码越早被捕获，故障定位就越快。不靠猜，靠 syscall 级事实。
