Rails 如何给 Rails 做 health check

yakjuly · 2018年11月09日 · 最后由 yakjuly 回复于 2018年11月13日 · 664 次阅读

问题说明: 我们公司用docker部署rails项目,部署在AWS的ECS上,我们一般会设置一个 health check的 API endpoint,让AWS监控这个container是健康的。然而最近内部另外一个项目会突然发起大规模请求到当前rails项目上。那么puma的进程和线程都去处理请求了,GET /health 就会超时。AWS会认为这个container是不健康的,不但没有scale up,创建新的containers,反而把正在忙的container 给 kill了。

这里牵涉到一个问题: 如何判断一个container是正在忙碌,而不是真正死掉?

我假设的解决办法:

  1. AWS 目前只支持 http ping,可以在container内加nginx,nginx链接两个后端,一个后端是puma进程, 另外一个进程也是一个http程序,这个进程类似god负责检查puma的状态,如果 puma是健康的,返回 /health 200,如果puma挂了,返回503

  2. Hack一下puma,让puma永远空出一个thread去处理 /health 请求,这样不管如何忙碌,只要puma不挂掉,/health 就永远可以有返回内容。

不知道大家的公司是如何scaling rails程序的,如何做health check?

共收到 10 条回复

k8s也有健康检查 可以去参考下

这种情况应该更改的是监控的指标吧?比如说x分钟内CPU、内存占用率之类的,通过这种指标来触发创建container。 health check 和 load monitoring 应该分开

3楼 已删除

刚好看到 okcomputer,内置了比较常见的一些检查

coderliu 回复

我搞混了,scaling 是依赖别的指标,例如 CPU usage,requests count。但是health check是根据ping 返回的状态来决定是不是要kill container。

w7938940 回复

如果服务器非常忙,你ping /okcomputer 也可能timeout

yakjuly 回复

/health 会 timeout,说明此时该服务器的负载确实已经太高了。要么你的 timeout 太小了,要么就是触发创建新 container 条件不够“敏感”

yakjuly 回复

那这时候服务是不是就可以被认为"不健康"了

yakjuly 回复

这个时候要加服务器了

我们目前也使用AWS

scaling 使用的是Auto Scaling,当CPU或者内存超过一定量的时候,就自动启动新的EC2 Instance

health check 用的NewRelic Infrastructure来监视nginx,unicorn等进程,发现异常后发送到slack

如果只是一时的大量请求,仅仅扩展web server就可以解决的话,用Auto Scaling应该可以解决问题

AWS的health check没实际用过,看了下文档,好像支持任意的command,可以换成监视pumma的进程挂没挂 https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_HealthCheck.html

42thcoder 回复

服务是不健康,需要scale up。但是 container是在工作的,只是比较忙而已,不应该kill掉忙的container。

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