rsyslog需先确认支持ommail模块（rsyslogd -v查看），否则需安装rsyslog-modules-mail；关键词报警规则写入/etc/rsyslog.d/99-alert.conf，用:msg, contains, "CRITICAL"匹配并调用脚本或写文件，注意大小写、路径硬编码、$msg仅含正文；journald需启用ForwardToSyslog=yes后由rsyslog按$programname和syslogseverity-text过滤；logrotate报警应在prerotate中检查原始日志，避免权限与时机错误；inotifywait监控需处理inode变化及多行日志限制。
怎么用 rsyslog 实现关键词触发邮件报警
直接写规则就能生效，但得先确认 rsyslog 支持 ommail 模块，否则配置再对也发不出邮件。很多系统默认不编译这个模块，rsyslogd -v 查输出里没有 ommail 就得重装带 mail 支持的包（比如 Debian/Ubuntu 要装 rsyslog-modules-mail）。
实际配法是：在 /etc/rsyslog.d/99-alert.conf 里加两段：
:msg, contains, "CRITICAL" /var/log/alert.log :msg, contains, "CRITICAL" ^/usr/lib/rsyslog/sms.sh
注意第二行用 ^ 调用脚本时，脚本必须可执行、且第一行是 #!/bin/bash；路径不能用变量或软链，rsyslog 不解析 shell 环境。
- 关键词匹配区分大小写，想不区分就改用
re_match+ 正则，比如if re_match($msg, "(?i)critical|panic") - 日志量大时别直接调外部命令，会阻塞日志写入；优先写文件再用
inotifywait异步处理 -
$msg只含日志正文，不含时间戳和程序名；要完整匹配得用$rawmsg，但注意它带换行符，正则容易出错
systemd-journald 怎么按服务名+错误级别过滤并转发
journald 本身不支持直接外发，得靠 journalctl 长轮询配合脚本，或者启用 ForwardToSyslog=yes 交给 rsyslog 处理。后者更稳——改 /etc/systemd/journald.conf 里的这一项，然后 systemctl restart systemd-journald。
转发后，在 rsyslog 里按服务过滤的关键是识别字段：systemd 服务日志的 programname 是服务名（如 sshd），但 syslogseverity-text 是英文（err、crit），不是数字。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 匹配 ssh 登录失败：用
if $programname == 'sshd' and $msg contains 'Failed password' - 匹配容器崩溃：Docker 容器日志的
programname是dockerd，但实际错误在$msg里，需结合container_id字段（得开启ForwardToSyslog=yes并确保 rsyslog 加载imjournal） - 别用
Priority数字做判断，journald 转发后可能被 rsyslog 重映射，syslogseverity-text更可靠
logrotate 配合报警时常见的权限与时机陷阱
logrotate 本身不报警，但常被误当成“日志监控工具”。它的作用只是归档，真正要报警得在 postrotate 里加检查逻辑。问题在于：脚本运行身份是 root，但读取的日志文件可能属其他用户（比如 nginx 日志属 www-data），直接 grep 会 Permission denied。
典型错误写法：postrotate grep "500" /var/log/nginx/error.log > /tmp/nginx_500 —— 这条命令在 logrotate 切日志后执行，但此时旧日志已被 rename，error.log 已是新空文件。
- 正确做法是在
prerotate里检查当前日志，或用$1（logrotate 传入的原始路径）配合lastaction做最终判断 - 检查结果写到临时文件后，记得
chown成告警脚本能读的用户，否则后续脚本读不到 - logrotate 默认每天执行一次，如果日志量小，可能一天没触发报警；高频场景建议用
inotifywait监控文件变化，比轮询更及时
用 inotifywait 实时监控日志文件并避免重复报警
inotifywait 轻量，但默认只监听单次事件。要持续监控就得套 while 循环，而循环里如果不 sleep，CPU 占用会飙高；sleep 时间太长又延迟报警。折中方案是用 --monitor --quiet --event modify，配合 read 阻塞等待。
关键点在于：日志追加是 modify 事件，但文件 rotate 时是 move_self 或 delete_self，必须分开处理，否则监控进程会退出。
- 监听前先用
stat -c "%i" /var/log/app.log记 inode，每次事件后重新 stat 对比，inode 变了说明文件被 replace，需重启 inotifywait - grep 匹配到关键词后，用
logger -t alert "high cpu in app.log"写 syslog，再由 rsyslog 统一发邮件，比直接调mail命令更可靠 - 同一行日志反复出现（比如健康检查失败刷屏），加个简单去重：用
md5sum存最近 10 条的哈希，重复则跳过
最麻烦的是多行日志匹配——比如 Java 异常堆栈跨多行，inotifywait 只能捕获每行 modify，没法合并上下文。这种得上 filebeat 或自研状态机，别硬撑。
