Elastic Beanstalk 基于 4xx 响应禁用健康状态更改 [英] Elastic Beanstalk disable health state change based on 4xx responses

问题描述

我有一个在 Elastic Beanstalk 上运行的 rest api，效果很好.应用方面的一切都运行良好，并按预期工作.

I have a rest api running on Elastic Beanstalk, which works great. Everything application-wise is running good, and working as expected.

该应用程序是一个rest api，用于查找不同的用户.

The application is a rest api, used to lookup different users.

example url: http://service.com/user?uid=xxxx&anotherid=xxxx

如果找到具有任一 id 的用户，api 将响应 200 OK，如果没有，则按照 404 Not Found 响应.HTTP/1.1 状态码定义.

If a user with either id's is found, the api responds with 200 OK, if not, responds with 404 Not Found as per. HTTP/1.1 status code defenitions.

我们的api在很多请求上回答404 Not Found的情况并不少见，弹性beanstalk将我们的环境从OK转移到Warning 甚至因此变成 Degraded .由于这种降级状态，看起来 nginx 已拒绝连接到应用程序.(看起来它有 30%+ 进入 warning 和 50%+ 进入 degraded 状态的阈值.这是一个问题，因为应用程序实际上按预期工作，但是Elastic Beanstalks 默认设置认为有问题，但实际上并非如此.

It is not uncommon for our api to answer 404 Not Found on a lot of requests, and the elastic beanstalk transfers our environment from OK into Warning or even into Degraded because of this. And it looks like nginx has refused connection to the application because of this degraded state. (looks like it has a threshold of 30%+ into warningand 50%+ into degraded states. This is a problem, because the application is actually working as expected, but Elastic Beanstalks default settings thinks it is a problem, when it's really not.

有谁知道编辑 EB 中 4xx 警告和状态转换阈值的方法，或完全禁用它们?

Does anyone know of a way to edit the threshold of the 4xx warnings and state transitions in EB, or completely disable them?

或者我真的应该进行症状治疗并停止在这样的电话中使用 404 Not Found 吗?(我真的不喜欢这个选项)

Or should i really do a symptom-treatment and stop using 404 Not Found on a call like this? (i really do not like this option)

推荐答案

更新: AWS EB 最终为此包含了一个内置设置:https://stackoverflow.com/a/51556599/1123355

Update: AWS EB finally includes a built-in setting for this: https://stackoverflow.com/a/51556599/1123355

旧解决方案:在深入研究 EB 实例并花费几个小时寻找 EB 的健康检查守护程序实际将状态代码报告回 EB 进行评估的位置后，我终于找到了它，并提出了一个补丁可以作为一个完美的解决方法，用于防止 4xx 响应代码将环境变成 Degraded 环境健康状态，以及用此电子无意义地通知您-邮件:

Old Solution: Upon diving into the EB instance and spending several hours looking for where EB's health check daemon actually reports the status codes back to EB for evaluation, I finally found it, and came up with a patch that can serve as a perfectly fine workaround for preventing 4xx response codes from turning the environment into a Degraded environment health state, as well as pointlessly notifying you with this e-mail:

Environment health has transitioned from Ok to Degraded. 59.2 % of the requests are erroring with HTTP 4xx.

状态代码报告逻辑位于 healthd-appstat 中，这是一个由 EB 团队开发的 Ruby 脚本，用于持续监控 /var/log/nginx/access.log并将状态码上报给EB，具体路径如下:

The status code reporting logic is located within healthd-appstat, a Ruby script developed by the EB team that constantly monitors /var/log/nginx/access.log and reports the status codes to EB, specifically in the following path:

/opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.2.0/gems/healthd-appstat-1.0.1/lib/healthd-appstat/plugin.rb

以下 .ebextensions 文件将修补此 Ruby 脚本以避免将 4xx 响应代码报告回 EB.这意味着 EB 永远不会因为 4xx 错误而降低环境健康，因为它只是不知道它们正在发生.这也意味着您的 EB 环境中的健康"页面将始终为 4xx 响应代码计数显示 0.

The following .ebextensions file will patch this Ruby script to avoid reporting 4xx response codes back to EB. This means that EB will never degrade the environment health due to 4xx errors because it just won't know that they're occurring. This also means that the "Health" page in your EB environment will always display 0 for the 4xx response code count.

container_commands:
    01-patch-healthd:
        command: "sudo /bin/sed -i 's/\\# normalize units to seconds with millisecond resolution/if status \\&\\& status.index(\"4\") == 0 then next end/g' /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.2.0/gems/healthd-appstat-1.0.1/lib/healthd-appstat/plugin.rb"
    02-restart-healthd:
        command: "sudo /usr/bin/kill $(/bin/ps aux | /bin/grep -e '/bin/bash -c healthd' | /usr/bin/awk '{ print $2 }')"
        ignoreErrors: true

是的，它有点难看，但它完成了工作，至少在 EB 团队提供一种通过某些配置参数忽略 4xx 错误的方法之前.部署时将其包含在您的应用程序中，位于相对于项目根目录的以下路径中:

Yes, it's a bit ugly, but it gets the job done, at least until the EB team provide a way to ignore 4xx errors via some configuration parameter. Include it with your application when you deploy, in the following path relative to the root directory of your project:

.ebextensions/ignore_4xx.config

祝你好运，如果这有帮助，请告诉我！

Good luck, and let me know if this helped!

这篇关于Elastic Beanstalk 基于 4xx 响应禁用健康状态更改的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！