部署 [炒冷饭] Rails 进程监视,你的选择是?

msg7086 · 2015年08月12日 · 最后由 nine 回复于 2015年08月13日 · 2328 次阅读

目标机器 Ubuntu 12.04 LTS,不能使用 Systemd。

所以大致就是这么几个选择

  • monit
  • supervised
  • god
  • 系统自带 upstart

主要监视 unicorn (独立运行的unicorn),需要崩溃时自动重启;以及将来可能用来监视 puppet agent 和 apache,看是不是死锁吃满CPU什么的。

你的选择是?以及理由?

共收到 10 条回复

upstart 系统自带,无需安装,节省资源,稳定

Rails App Server 进程不需要监视,不会挂,另外 Uncorn Puma 之类的 Master 进程本身有进程保护的。

monit 另外,systemd和监视有啥关系?

#3楼 @vkill 姑且也是有一些监视功能的吧,比如崩溃自动重启什么的

用 Foreman 导出配置,系统是 upstart 的时候导出 upstart,是 systemd 的时候导出 systemd。

http://chloerei.com/2014/12/15/foreman/

我倾向于选择系统自带的进程管理器, upstart 或者 systemd,优点:

  • 没有第三方依赖
  • 由 init 进程负责开机自动启动,并将进程的生命周期托管给 init 统一管理
  • 被管理进程自己无需实现 daemonize,且也不需要 PID 文件(我一直觉得PID记录进程号的管理方式带来的问题比解决的问题更多)
  • 被管理进程自己无需实现日志文件管理,只需要把日志信息输出到 STDOUT,然后就可以通过 syslog 统一管理,如果是 systemd 的话,还可以用更先进的 journald 来统一管理日志

缺点正如 @rei 的文章中提到的 Foreman 导出 upstart 配置后的遇到的问题一样。

  • 如果将进程托管给 upstart,通过 Capistrano / Mina 执行 upstart 的管理命令的话。Capistrano 建议配置 sudo 执行特定命令时不要求密码,虽然ok,但是我觉得这是权宜之计
  • 如果将进程托管给 upstart,但是由 Capistrano / Mina 来控制的话,则需要通过 PID 文件记录进程号,方便查找进程以及向进程发送信号
  • 如果不将进程托管给 upstart,而是通过 Capistrano / Mina 来管理的话,那就只用到了 upstart 做开机自动启动,也要让 upstart 以用户身份执行进程启动脚本,以及在启动前初始化好 Shell 环境变量(如 rvm/rbenv, RAILS_ENV 等),这样失去了 upstart 对进程的托管和 monitor 的作用,需要通过第三方如 monit 来解决进程意外挂掉的情况。

总之这部分坑很多,没有标准答案,需要根据自己对系统的理解以及项目的需要灵活搭配调整。

一直用的是CentOS puma交给自身的master管理,没问题。内存占用过大了,直接kill了worker就重启了。 后台跑的sleep的rake 任务用god,最大的问题是stop的时候停不掉。目前是手工关掉god 然后再kill掉进程。 supervised 搞不定rvm环境初始化,放弃了。monit 没搞明白,预感会遇到rvm环境问题,放弃,用god了。

核心服务都用默认的或者不用(如上面说的本身自带进程保护),小脚本程序用了eye(类似god,用下来感觉更简单好用耗资源)。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册