Elastische Beanstalk deaktivieren Gesundheit Zustand ändern basierend auf 4xx Antworten

Question

Ich habe eine Pause api auf Elastic Beanstalk, die gut funktioniert. Alles, was die Anwendung angeht, läuft gut und funktioniert wie erwartet.

Die Anwendung ist eine Rest-API, die verwendet wird, um verschiedene Benutzer zu suchen.

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

Wenn ein Benutzer mit entweder IDs gefunden wird, antwortet der api mit 200 OK, wenn nicht, mit 404 Not Found gemäß reagiert. HTTP/1.1 Statuscode-Defensionen.

Es ist nicht ungewöhnlich für unsere api 404 Not Found auf viele Anfragen zu beantworten, und das elastische Bohnenstengel überträgt unsere Umwelt aus OK in Warning oder sogar in Degraded, weil dieser. Und es sieht so aus, als ob nginx die Verbindung zu der Anwendung aufgrund dieses verschlechterten Zustands abgelehnt hat. (sieht aus wie es einen Grenzwert von 30% + in warning und 50% + in degraded Staaten hat. Dies ist ein Problem, weil die Anwendung tatsächlich wie erwartet funktioniert, aber die Standardeinstellungen von Elastic Beanstalk ist es ist ein Problem, wenn es ist wirklich nicht.

Kennt jemand eine Möglichkeit, den Schwellenwert der 4xx Warnungen und Zustandsübergänge in EB zu bearbeiten, oder sie vollständig deaktivieren?

oder soll ich wirklich eine Symptom-Behandlung tun und aufhören mit 404 Not Found auf Ein Anruf wie dieser? (Ich mag diese Option wirklich nicht)

Answer 1

Nach dem Tauchen in die EB Instanc mehr Stunden e und Ausgaben der Suche nach dem Gesundheitscheck Daemon EB tatsächlich meldet die Statuscodes zurück zu EB zur Auswertung, finde ich es schließlich und kam mit einem Patch auf, der das als völlig in Ordnung, Abhilfe zu verhindern, dass 4xx Antwortcodes vom Drehen dienen kann Umwelt in einem Gesundheitszustand Degraded Umwelt sowie anmelde Sie pointlessly mit dieser E-Mail:

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

der Code Statusbericht-Logik wird durch das EB-Team entwickelt innerhalb healthd-appstat, ein Ruby-Skript befindet, das /var/log/nginx/access.log ständig überwacht und meldet die Statuscodes an EB, insbesondere im folgenden Pfad:

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

Die folgende .ebextensions Datei wird diese Ruby-Skript Patch 4xx Antwortcodes zurück zu EB zu vermeiden Berichterstattung. Das bedeutet, dass EB nie die Umwelt Gesundheit aufgrund 4xx Fehler verschlechtern, weil es einfach nicht wissen, dass sie auftreten. Das bedeutet auch, dass die „Gesundheit“ Seite in Ihrer EB-Umgebung immer 0 für die 4xx Antwortcode Zahl angezeigt wird.

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 

Ja, es ist ein bisschen hässlich, aber es wird die Arbeit erledigt, zumindest bis das EB-Team einen Weg 4xx Fehler über einige Konfigurationsparameter ignorieren bieten. Fügen Sie es mit Ihrer Anwendung, wenn Sie in dem folgenden Pfad relativ zum Stammverzeichnis des Projekts bereitstellen:

.ebextensions/ignore_4xx.config

Viel Glück, und lassen Sie mich wissen, ob dies geholfen!

Answer 2

Vielen Dank für Ihre Antwort Elad Nava, ich hatte das gleiche Problem und Ihre Lösung funktionierte perfekt für mich!

Nach dem Öffnen eines Tickets im AWS Support Center empfahlen sie mir jedoch, die nginx Konfiguration zu ändern, um 4xx auf Health Check zu ignorieren, anstatt das Ruby-Skript zu ändern. Um das zu tun, musste ich auch eine Config-Datei in das Verzeichnis .ebextensions hinzufügen, um den Standard nginx.conf Datei überschrieben werden:

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 

Obwohl diese Lösung recht ausführliche, ich persönlich glaube, dass es sicherer ist, zu implementieren, , solange es nicht von einem proprietären AWS-Skript abhängt. Ich meine, wenn AWS aus irgendeinem Grund beschließt, sein Ruby-Skript zu entfernen oder zu ändern (glaube mir oder nicht, sie lieben es, Skripte ohne vorherige Ankündigung zu ändern), besteht die große Chance, dass die Problemumgehung mit sed nicht mehr funktioniert.

Answer 3

Hier ist eine Lösung basierend auf Adriano Valente's answer. Ich konnte das Bit $loggable nicht zum Funktionieren bringen, obwohl das Überspringen der Protokollierung für die 404er scheint, als wäre das eine gute Lösung. Ich erstellte einfach eine neue .conf Datei, die die $modstatus Variable definierte, und überschrieb dann das healthd Protokollformat, um $modstatus anstelle von $status zu verwenden. Diese Änderung erforderte auch den Neustart von nginx. Dies funktioniert auf Elastic Beanstalks 64bit Amazon Linux 2016.09 v2.3.1 mit 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 4

Basierend auf Elad Nava's Answer, ich glaube, es ist besser, die elasticbeanstalk healthd Kontrolle Skript direkt verwenden anstelle eines Tötungs:

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" 

Schließlich, wenn dieses Problem zu untersuchen, habe ich das healthd und Apache log bemerkt Statuscodes unterscheiden sich von denen der ersteren mit% s, während die letzten%> s zu Diskrepanzen zwischen ihnen führen. Ich habe auch diese mit gepatchten:

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 5

ich vor kurzem in der gleichen Ausgabe lief der mit 4xx Fehler bombardiert werden wie Sie. Ich habe die oben genannten Vorschläge ausprobiert, aber nichts hat für mich funktioniert. Ich habe AWS Support kontaktiert und hier ist, was sie vorgeschlagen haben, und es hat mein Problem gelöst. Ich habe eine Elastic Beanstalk-Anwendung mit 2 Instanzen ausgeführt.

1. Erstellen Sie einen Ordner namens .ebextensions
2. In diesem Ordner erstellen Sie eine Datei namens nginx.config (stellen Sie sicher, dass es die .config-Erweiterung hat. „Conf“ nicht tun!)
3. Wenn Wenn Sie Ihre Anwendung mit einem Docker-Container bereitstellen, stellen Sie bitte sicher, dass dieser Ordner .exextensions im Bereitstellungspaket enthalten ist. Für mich eingeschlossen das Bündel der Ordner sowie die Dockerrun.aws.json

Hier wird der gesamte Inhalt der nginix.config Datei ist: 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/*; 
    } 

container_commands: restart-nginx: command: "service nginx restart"