linux集群日志异常时可通过五种路径实现监控与自动恢复：一、rsyslog+logstash关键词检测触发脚本；二、prometheus指标越限调用恢复；三、systemd定时扫描日志并重启服务；四、journald内置onfailure联动处理；五、elk模式识别后api驱动恢复。
如果您在 Linux 集群环境中发现关键服务日志异常中断、错误率突增或进程意外退出，则可能是由于日志采集失效、磁盘空间耗尽或监控代理崩溃所致。以下是实现日志监控与自动恢复的多种操作路径：
一、部署基于rsyslog+Logstash的日志集中采集与异常检测
该方法通过标准化日志转发路径，在中心节点实时解析集群各节点日志流，利用 Logstash 的 grok 过滤器识别 ERROR、FATAL、panic 等关键词，并触发告警或恢复动作。
1、在所有集群节点编辑 /etc/rsyslog.conf，在文件末尾添加：*.* @central-logger:514，其中 central-logger 为日志服务器主机名。
2、在日志服务器上安装 logstash，配置 /etc/logstash/conf.d/monitor.conf，设置 input 插件监听 UDP 514 端口，filter 插件启用 grok 匹配 %{LOGLEVEL:level} 和 %{GREEDYDATA:message}。
3、在 output 插件中添加 if [level] in ["ERROR", "FATAL"] { exec { command => "/usr/local/bin/recover-service.sh %{@host}" } }。
4、赋予 /usr/local/bin/recover-service.sh 可执行权限，并确保其包含 service nginx status || service nginx start 命令逻辑。
二、使用Prometheus+Alertmanager+Node Exporter构建指标驱动型恢复
该方法不依赖原始日志文本，而是采集 rsyslog 进程状态、/var/log 目录可用空间、journalctl 日志条目速率等系统指标，当指标越限时直接调用恢复脚本。
1、在每台节点部署 node_exporter，并确认 metrics_path="/metrics" 下可获取 node_filesystem_avail_bytes{mountpoint="/var/log"} 等指标。
2、在 Prometheus 配置文件中添加 job_name: 'cluster-logs'，scrape_interval: 15s，target 列表包含全部节点 IP 和端口。
3、定义 alert_rules.yml 规则：ALERT LogDirLowSpace IF node_filesystem_avail_bytes{mountpoint="/var/log"}
4、在 Alertmanager 配置中为该 alert 设置 webhook_configs，指向本地恢复服务地址 http://localhost:8080/recover。
5、运行轻量 HTTP 服务监听 /recover 路径，收到 POST 请求后执行 systemctl restart rsyslog && journalctl --vacuum-size=200M。
三、基于inotifywait的本地日志文件变更响应机制
该方法适用于无网络外联或需毫秒级响应的场景，直接监听 /var/log/messages 或应用专属日志路径，一旦检测到新增 ERROR 行即刻干预。
1、在目标节点安装 inotify-tools 工具包，确认 inotifywait 命令可用。
2、编写监控脚本 monitor-log.sh，核心语句为：inotifywait -m -e modify /var/log/messages | while read path action file; do grep --line-buffered "ERROR" "$path$file" | while read line; do echo "$(date): $line" >> /var/log/recovery-trigger.log; /usr/local/bin/trigger-restart.sh; done; done。
3、将该脚本加入 systemd 服务 unit 文件，设置 Restart=always 和 StartLimitIntervalSec=0，确保常驻运行。
4、trigger-restart.sh 中判断当前故障服务名称（例如从 $line 提取 "sshd" 或 "dockerd"），执行 systemctl is-active --quiet $service || systemctl start $service。
四、利用systemd-journald的内置日志监控与服务重启联动
该方法复用 systemd 原生日志设施，通过 journalctl 实时尾部读取并过滤，结合 systemd 的 OnFailure 指令实现服务级自动恢复闭环。
1、为待监控服务（如 myapp.service）在 /etc/systemd/system/myapp.service 中添加：OnFailure=myapp-failure-handler.service。
2、创建 /etc/systemd/system/myapp-failure-handler.service，内容包含 Type=oneshot 和 ExecStart=/usr/local/bin/check-and-recover.sh %i。
3、check-and-recover.sh 中执行 journalctl -u myapp --since "1 hour ago" --no-pager | grep -q "Out of memory\|Segmentation fault"，若匹配成功则运行 systemctl reset-failed myapp && systemctl start myapp。
4、启用并启动 myapp-failure-handler.service，同时执行 systemctl daemon-reload 使配置生效。
五、基于ELK栈的日志模式识别与API驱动恢复
该方法将日志送入 Elasticsearch 存储，通过 Kibana 创建异常模式看板，并利用 Watcher 功能定期查询匹配结果，命中后调用预设 Webhook 执行恢复流程。
1、在 Logstash output 配置中指定 elasticsearch { hosts => ["es-cluster:9200"] index => "cluster-logs-%{+YYYY.MM.dd}" }。
2、在 Kibana 中新建一个 Discover 页面，筛选字段 message: "ERROR" AND host: "node01"，保存为 "Node01 Critical Errors"。
3、进入 Stack Management > Watcher，创建新 watcher，Trigger 设为 schedule 每 30 秒执行一次，Input 使用 search 查询 saved_objects 中前述 Discover 的 DSL。
4、Condition 设置为 ctx.payload.hits.total.value > 3，表示连续 30 秒内出现超 3 条 ERROR。
5、Action 配置为 webhook，URL 指向 http://recovery-gateway/api/v1/restart?target=node01，method 为 POST，body 为 {"reason": "log_error_burst"}。
6、接收端验证请求签名后，调用 ansible-playbook -i inventory.yml restart-service.yml --extra-vars "target_host=node01 service_name=rsyslog"。
