rest - sociales - instrumentos de medicion en salud

Elastic Beanstalk desactiva el cambio de estado de salud basado en respuestas 4xx

Question

Tengo una api de descanso ejecutándose en Elastic Beanstalk, que funciona genial. Todo en lo que respecta a las aplicaciones funciona bien y funciona como se esperaba.

La aplicación es una API de descanso, que se utiliza para buscar usuarios diferentes.

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

Si se encuentra un usuario con cualquiera de los identificadores, la API responde con 200 OK , si no, responde con 404 Not Found según corresponda. Defensas de código de estado HTTP/1.1 .

No es raro que nuestra API responda 404 Not Found en muchas solicitudes, y el beanstalk elástico transfiere nuestro entorno de OK a Warning o incluso a Degraded debido a esto. Y parece que nginx ha rechazado la conexión a la aplicación debido a este estado degradado. (Parece que tiene un umbral de 30% + en warning y 50% + en estados degraded . Esto es un problema, porque la aplicación funciona realmente como se esperaba, pero la configuración predeterminada de Elastic Beanstalks cree que es un problema, cuando en realidad no es .

¿Alguien sabe de una forma de editar el umbral de las advertencias 4xx y las transiciones de estado en EB, o deshabilitarlas por completo?

¿O debería realmente hacer un tratamiento de síntomas y dejar de usar 404 Not Found en una llamada como esta? (Realmente no me gusta esta opción)

Answer 1

Al sumergirse en la instancia de EB y pasar varias horas buscando dónde el daemon de verificación de salud de EB en realidad informa los códigos de estado a EB para su evaluación, finalmente lo encontré, y se me ocurrió un parche que puede servir como una solución perfecta para prevenir 4xx los códigos de respuesta de convertir el entorno en un estado de salud ambiental Degraded , así como notificarlo inútilmente con este correo electrónico:

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

La lógica de informes del código de estado se encuentra dentro de healthd-appstat , un script de Ruby desarrollado por el equipo de EB que monitorea constantemente /var/log/nginx/access.log e informa los códigos de estado a EB, específicamente en la siguiente ruta:

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

El siguiente archivo .ebextensions corregirá este script de Ruby para evitar el informe de los códigos de respuesta 4xx a EB. Esto significa que EB nunca degradará el estado del medio ambiente debido a errores 4xx porque simplemente no sabrá que están ocurriendo. Esto también significa que la página "Salud" en su entorno EB siempre mostrará 0 para el recuento de códigos de respuesta 4xx .

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

Sí, es un poco feo, pero hace el trabajo, al menos hasta que el equipo de EB proporcione una forma de ignorar los errores 4xx través de algún parámetro de configuración. Inclúyalo con su aplicación cuando implemente, en la siguiente ruta relativa al directorio raíz de su proyecto:

.ebextensions/ignore_4xx.config

¡Buena suerte, y avíseme si esto ayudó!

Answer 2

Aquí hay una solución basada en la respuesta de Adriano Valente . No pude hacer funcionar el bit $loggable , aunque omitir el registro de los 404 parece ser una buena solución. Simplemente creé un nuevo archivo .conf que definió la variable $modstatus y luego healthd el formato de registro de healthd para usar $modstatus en lugar de $status . Este cambio también requirió que nginx se reiniciara. Esto funciona en Amazon 64,0 de Amazon de 64 bits de Elastic Beanstalk ejecutando Ruby 2.3 (Puma).

# .ebextensions/nginx.conf
files:
"/tmp/nginx.conf":
content: |
# Custom config to ignore 4xx in the health file only
map $status $modstatus {
~^[4] 200;
default $status;
}
container_commands:
modify_nginx_1:
command: "cp /tmp/nginx.conf /etc/nginx/conf.d/custom_status.conf"
modify_nginx_2:
command: sudo sed -r -i ''s@/$status@$modstatus@'' /opt/elasticbeanstalk/support/conf/webapp_healthd.conf
modify_nginx_3:
command: sudo /etc/init.d/nginx restart

Answer 3

En base a la respuesta de Elad Nava , creo que es mejor usar el script de control de la dieta de la bolsa elástica directamente en lugar de matar:

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 /opt/elasticbeanstalk/bin/healthd-restart"

Finalmente, al investigar este problema, me he dado cuenta de que el estado de registro de estado de apadrinado y de apache codifica de manera diferente con el primero que usa% s, mientras que el último%> s genera discrepancias entre ellos. También he parchado esto usando:

 03-healthd-logs:
command: sed -i ''s/^LogFormat.*/LogFormat "%{%s}t//"%U//"%>s//"%D//"%D//"%{X-Forwarded-For}i" healthd/g'' /etc/httpd/conf.d/healthd.conf

Answer 4

Gracias por su respuesta Elad Nava , tuve el mismo problema y su solución funcionó perfectamente para mí.

Sin embargo, después de abrir un ticket en el Centro de soporte de AWS, me recomendaron que modificara la configuración de nginx para ignorar 4xx en Health Check en lugar de modificar el script de ruby. Para hacer eso, también tuve que agregar un archivo de configuración al directorio .ebextensions , para sobrescribir el archivo nginx.conf predeterminado:

files:
"/tmp/nginx.conf":
content: |
# Elastic Beanstalk Managed
# Elastic Beanstalk managed configuration file
# Some configuration of nginx can be by placing files in /etc/nginx/conf.d
# using Configuration Files.
# http://docs.amazonwebservices.com/elasticbeanstalk/latest/dg/customize-containers.html
#
# Modifications of nginx.conf can be performed using container_commands to modify the staged version
# located in /tmp/deployment/config/etc#nginx#nginx.conf
# Elastic_Beanstalk
# For more information on configuration, see:
# * Official English Documentation: http://nginx.org/en/docs/
# * Official Russian Documentation: http://nginx.org/ru/docs/
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
worker_rlimit_nofile 1024;
events {
worker_connections 1024;
}
http {
###############################
# CUSTOM CONFIG TO IGNORE 4xx #
###############################
map $status $loggable {
~^[4] 0;
default 1;
}
map $status $modstatus {
~^[4] 200;
default $status;
}
#####################
# END CUSTOM CONFIG #
#####################
port_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
# This log format was modified to ignore 4xx status codes!
log_format main ''$remote_addr - $remote_user [$time_local] "$request" ''
''$status $body_bytes_sent "$http_referer" ''
''"$http_user_agent" "$http_x_forwarded_for"'';
access_log /var/log/nginx/access.log main;
log_format healthd ''$msec"$uri"''
''$modstatus"$request_time"$upstream_response_time"''
''$http_x_forwarded_for'' if=$loggable;
sendfile on;
include /etc/nginx/conf.d/*.conf;
keepalive_timeout 1200;
}
container_commands:
01_modify_nginx:
command: cp /tmp/nginx.conf /tmp/deployment/config/#etc#nginx#nginx.conf

Aunque esta solución es bastante más detallada, personalmente creo que es más seguro implementarla, siempre que no dependa de ningún script propietario de AWS. Lo que quiero decir es que, si por alguna razón AWS decide eliminar o modificar su script de ruby ​​(créanme o no, les encanta cambiar los scripts sin previo aviso), hay una gran posibilidad de que la solución con sed ya no funcione.

Answer 5

Hay una personalización de la regla de supervisión de salud dedicada llamada Ignorar HTTP 4xx (captura de pantalla adjunta). Simplemente habilítela y EB no degradará el estado de la instancia en errores 4xx.

Answer 6

Recientemente me encontré con el mismo problema de ser bombardeado con errores 4xx como lo has hecho. Probé las sugerencias enumeradas anteriormente, pero nada funcionó para mí. Me comuniqué con AWS Support y aquí está lo que han sugerido, y resolvió mi problema. Tengo una aplicación Elastic Beanstalk con 2 instancias ejecutándose.

1. Crea una carpeta llamada .ebextensions
2. Dentro de esta carpeta, crea un archivo llamado nginx.config (asegúrate de que tenga la extensión .config. ".conf" no funcionará)
3. Si está implementando su aplicación con un contenedor Docker, asegúrese de que esta carpeta .ebextensions esté incluida en el paquete de implementación. Para mí, el paquete incluía la carpeta y Dockerrun.aws.json

Aquí está todo el contenido del archivo nginix.config:

files:
"/etc/nginx/nginx.conf":
content: |
# Elastic Beanstalk Nginx Configuration File
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
# Custom config
# HTTP 4xx ignored.
map $status $loggable {
~^[4] 0;
default 1;
}
# Custom config
# HTTP 4xx ignored.
map $status $modstatus {
~^[4] 200;
default $status;
}
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
log_format healthd ''$msec"$uri"$modstatus"$request_time"$upstream_response_time"$http_x_forwarded_for'';
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

Answer 7

Solución provista por el soporte de AWS a partir de abril de 2018:

 files:
"/tmp/custom-site-nginx.conf":
mode: "000664"
owner: root
group: root
content: |
map $http_upgrade $connection_upgrade {
default "upgrade";
"" "";
}
# Elastic Beanstalk Modification(EB_INCLUDE)
# Custom config
# HTTP 4xx ignored.
map $status $loggable {
~^[4] 0;
default 1;
}
server {
listen 80;
gzip on;
gzip_comp_level 4;
gzip_types text/html text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
if ($time_iso8601 ~ "^(/d{4})-(/d{2})-(/d{2})T(/d{2})") {
set $year $1;
set $month $2;
set $day $3;
set $hour $4;
}
access_log /var/log/nginx/healthd/application.log.$year-$month-$day-$hour healthd if=$loggable;
access_log /var/log/nginx/access.log;
location / {
proxy_pass http://docker;
proxy_http_version 1.1;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
container_commands:
override_beanstalk_nginx:
command: "mv -f /tmp/custom-site-nginx.conf /etc/nginx/sites-available/elasticbeanstalk-nginx-docker-proxy.conf"