systemd可通过配置实现服务自动故障转移，保障系统稳定性。1. 使用restart=参数（如on-failure）实现异常自动重启，并设置restartsec指定延迟；2. 通过watchdogsec配合sd_notify实现健康检查，检测服务假死；3. 结合keepalived、pacemaker等工具实现跨节点高可用故障转移；4. 配合日志记录与告警机制，及时排查频繁重启原因。
配置服务的自动故障转移，特别是结合 systemd 的服务监控与恢复机制，是保障系统稳定性的重要一环。在很多生产环境中，服务崩溃或卡死是常见问题，而手动重启不仅效率低还容易出错。通过合理设置 systemd，可以让服务在异常时自动重启，甚至配合其他工具实现更高级的故障转移。
下面是一些实用的配置方法和建议，帮助你更好地使用 systemd 来监控和恢复服务。
1. 使用 Restart= 参数实现基础自动重启
systemd 提供了非常方便的服务重启机制，只需要在服务单元文件中添加 Restart= 指令即可。
常见的选项包括：
-
no：不自动重启（默认） -
on-success：仅当服务正常退出时重启 -
on-failure：服务非正常退出时重启（推荐） -
always：无论什么情况都重启
例如，在服务的 .service 文件中添加：
[Service] Restart=on-failure RestartSec=5s
这样配置后，服务一旦因为错误退出（比如被 kill、崩溃等），systemd 会在 5 秒后尝试重启它。
注意：某些服务如果本身有守护进程逻辑，可能需要额外配置 Type= 字段来确保 systemd 能正确识别状态。
2. 设置健康检查：ExecReload 与 WatchdogSec
虽然 Restart= 可以处理服务退出的情况，但有些时候服务虽然还在运行，但实际上已经“假死”——比如响应超时、卡住无反应。这时候就需要引入更主动的健康检查机制。
systemd 支持 watchdog 功能，可以通过以下步骤启用：
- 在服务配置中设置
WatchdogSec=时间 - 在代码或脚本中定期发送
sd_notify(0, "WATCHDOG=1")通知 - 如果未按时发送通知，systemd 就会认为服务异常并重启它
示例配置：
[Service] WatchdogSec=30s ExecStart=/usr/bin/my-service --watchdog
此外，还可以配合 ExecReload 命令来做一些健康检测的辅助操作，比如重载配置或触发健康检查接口。
3. 配合外部工具做高可用故障转移
systemd 本身可以完成本地服务的监控和恢复，但如果要实现跨节点的故障转移（比如主备切换），就需要借助外部工具，比如：
- Keepalived：用于虚拟 IP 管理和服务漂移
- Pacemaker + Corosync：更复杂的集群资源管理方案
- 自定义脚本 + etcd/consul 实现服务注册与发现
一个简单的做法是：在多个节点部署相同服务，并用 Keepalived 控制 VIP。一旦某个节点上的服务挂掉且无法恢复，VIP 会自动漂移到备用节点上，实现对外服务的无缝切换。
这类方案适合对高可用性要求较高的场景，如数据库、API 网关等。
4. 日志记录与排查建议
自动恢复虽然能减少人工干预，但也可能掩盖真实的问题。因此，一定要配合日志记录和分析机制。
你可以：
- 查看服务日志：
journalctl -u your-service-name - 设置邮件或告警通知：当服务重启超过一定次数时发出提醒
- 记录重启原因：比如是否是因为 watchdog 超时、OOM killer 杀掉等
举个例子，如果你发现某个服务频繁重启，可以用如下命令查看它的历史状态：
systemctl list-units --type=service --state=failed journalctl -u your-service-name --since "1 hour ago"
这有助于快速定位问题是程序 Bug、资源配置不足还是外部依赖失败。
基本上就这些。合理利用 systemd 的功能，再配合适当的外部工具，就能实现比较完善的服务监控与自动恢复机制。虽然配置起来不复杂，但在实际应用中很容易忽略细节，比如没有正确处理信号、没有设置合适的重启策略等。多测试、多观察日志，才能让服务真正“稳如老狗”。
