无Docker环境下多服务器Java Jar应用远程运维管理方案咨询

• 进程保活与本地状态管理直接用系统自带的systemd
  完全不需要修改现有业务代码，10分钟就能完成单个应用的配置，天然适配所有主流Linux发行版，对Java 8无兼容性问题。
  只需在应用所在服务器的/etc/systemd/system/目录下新增对应服务配置文件，示例如下：

  [Unit]
  Description=XX业务数据同步应用
  After=network.target
  
  [Service]
  User=应用运行用户名
  WorkingDirectory=Jar包所在目录绝对路径
  ExecStart=JDK绝对路径/bin/java -jar 你的应用包名.jar
  # 异常退出时自动重启
  Restart=always
  # 重启间隔5秒
  RestartSec=5
  # 日志统一输出到系统journal，可直接用journalctl命令查询
  StandardOutput=journal+console
  StandardError=journal+console
  
  [Install]
  WantedBy=multi-user.target
  

  配置完成后执行以下命令即可生效：

  # 加载新配置
  systemctl daemon-reload
  # 启动应用
  systemctl start 你的服务名.service
  # 设置开机自启
  systemctl enable 你的服务名.service
  # 查看应用运行状态
  systemctl status 你的服务名.service
  

• 集中监控与告警可选用轻量开源工具
  不用Docker的场景下，直接部署process_exporter到各应用服务器，采集Java进程的运行状态，配合Prometheus做指标集中存储，配置简单的告警规则即可实现进程异常退出、资源占用过高时的自动通知，支持邮件、企业微信、钉钉等主流通知渠道，整套部署复杂度低，不需要改造业务代码。如果觉得整套Prometheus体系太重，也可以选择单二进制文件分发的轻量监控工具，开箱即用。

如果需要监控应用内部的运行状态（比如数据拉取是否正常、队列是否堵塞等），不需要做复杂的socket心跳上报，只需要给现有应用内嵌一个极简的HTTP健康检查接口，返回应用的核心运行指标，监控服务定时轮询所有应用的该接口即可，侵入性极低，排查问题也更方便。进程保活依然沿用上面的systemd方案即可，不需要额外开发保活逻辑。

• 不建议强行用Vertx封装现有应用，你已经遇到兼容性问题，后续业务迭代、问题排查的成本会大幅提升，反而影响业务稳定性。
• 非必要不要选择改造应用新增socket心跳的方案，侵入性高，后续新增应用需要重复改造，运维成本远高于上述无侵入方案。

内容的提问来源于stack exchange，提问作者mohd874