Linux 集群监控与故障自动恢复

真正可用的systemd服务自启配置需组合restart=on-failure、restartsec=5、startlimitintervalsec=60、startlimitburst=3和restartpreventexitstatus=255，避免雪崩并留人工介入窗口。

用 systemd 实现服务崩溃后自动拉起，但别只写 Restart=always

单纯加 Restart=always 很容易导致雪崩：服务反复崩溃又重启，把日志打满、端口占死、甚至拖垮节点。真正可用的配置必须叠加限制条件。

• Restart=on-failure 更稳妥——只在非 0 退出码或被信号终止时重启，避免正常退出后误拉起
• 务必配 StartLimitIntervalSec=60 和 StartLimitBurst=3，防止 1 分钟内连续失败超 3 次就彻底停服，留出人工介入窗口
• 如果服务依赖网络或远程存储，加 RestartPreventExitStatus=255（比如 curl 超时返回 255）可避免把临时网络抖动当故障处理
• 示例片段：

  [Service] Restart=on-failure RestartSec=5 StartLimitIntervalSec=60 StartLimitBurst=3 RestartPreventExitStatus=255

集群级进程存活检测不能只靠 ps aux | grep

这种写法在容器化或 systemd 管理环境下极不可靠：进程名被截断、grep 自身混入结果、cgroup 隔离后 ps 看不到跨 Namespace 进程。

• 优先用 systemctl is-active <code>service_name 判断服务状态，它走的是 dbus 协议，准确反映 systemd 管理的真实生命周期
• 对非 systemd 进程（如裸跑的 Python 脚本），改用 pgrep -f "python.*my_worker.py"，-f 匹配完整命令行，比 grep 少一层管道污染
• 在监控脚本里加超时控制：timeout 5 systemctl is-active myapp.service || echo "timeout"，避免因 dbus 卡住导致整个巡检阻塞

node_exporter 默认指标不够用，关键集群维度得自己加

默认采集的 CPU、内存、磁盘指标只能告诉你“机器快挂了”，但无法定位是哪个服务或租户吃掉了资源。集群监控必须带标签下钻能力。

• 用 --collector.textfile.Directory 配合定时脚本，把每个服务的 docker stats --no-stream 或 kubectl top pod 结果写成 .prom 文件，让 node_exporter 暴露为自定义指标（如 container_cpu_usage_cores{job="myapp", instance="node-01"}）
• 禁用冗余采集器节省开销：--no-collector.wifi --no-collector.zfs，ZFS 在 linux 集群几乎不用，WiFi 更是干扰项
• 注意时间戳精度：文本文件里每行末尾加 # TYPE xxx gauge 注释，并确保写入时间与采集周期对齐，否则 prometheus 抓取会丢点

自动恢复脚本里调 curl 或 ssh 前，先做连接性兜底

故障恢复链路上任何一环超时或失败，都会让“自动恢复”变成“自动失联”。不能假设网络永远通、目标端口永远开、密钥永远有效。

• 用 nc -z -w 3 target-host 22 && ssh ... 替代裸 ssh，3 秒内连不上就跳过，不卡住后续步骤
• 调用 API 前先 curl -sfI -m 5 https://api.example.com/health，-s 静默错误、-f 失败不输出、-m 5 限总耗时，靠返回码判断是否值得继续
• 所有远程操作加 set -e 和 set -o pipefail，但关键步骤后立刻用 || true 显式忽略非致命错误（比如清理旧日志失败不影响主流程）

集群自动恢复最麻烦的不是写脚本，而是厘清“什么算恢复成功”——是进程起来了？端口能连了？还是第一个 HTTP 请求返回 200？这个判定标准一旦模糊，所有自动逻辑都会在边界 case 上失效。