让 systemd 重启服务，也让故障留下线索

“进程还在”与“服务可用”不是同一件事。systemd 能监督进程生命周期，但应用还需要合适的健康检查。先弄清应用如何退出、何时就绪，以及故障时应该留下什么信息，再设置重启策略。

重启之间留出间隔

下面是一段需要按应用实际情况调整的 unit 示例。失败后等待五秒重新启动，短时间连续失败达到阈值后停止重试，避免配置错误形成高频重启循环。

[Unit]
StartLimitIntervalSec=120
StartLimitBurst=5

[Service]
Type=simple
ExecStart=/opt/example/bin/server
Restart=on-failure
RestartSec=5s
TimeoutStopSec=30s

Type=simple 不代表应用已经完成初始化。依赖真正就绪通知的应用可以使用 Type=notify，前提是程序支持它。不要仅靠延长等待时间来掩盖启动依赖问题。

修改前后都观察

systemctl status example --no-pager
journalctl -u example --since '30 minutes ago' --no-pager
systemctl show example -p NRestarts -p MemoryCurrent -p LimitNOFILE

日志时间、退出码、内存和重启次数组合起来，通常比一个“运行中”标签更有用。配置变更后先做语法检查，再重载 unit 并按需重启应用。重载 unit 不会自动使所有应用配置生效。

根据峰值设置资源边界

文件句柄需求应由连接数、日志文件、数据库连接及内部管道估算。提高上限解决不了泄漏；持续增长的打开文件数需要调查。内存预算也应留出系统与其他应用的空间，硬限制过低可能把短时峰值变成反复退出。

把可观测性做小而明确

对小型服务，监测请求成功率、延迟、重启次数和磁盘空间通常已经很有价值。健康检查只读必要状态，不触发昂贵任务。告警应指向用户能感知的问题，同时提供最近变更和一条可执行的排查入口。

参考：systemd.service、资源控制手册。