Format der Protokolle der erweiterten Zustandsberichte

AWS Elastic Beanstalk-Plattformen verwenden ein benutzerdefiniertes Webserver-Protokollformat, um Informationen über HTTP-Anforderungen effizient an das System für erweiterte Zustandsberichte weiterzuleiten. Das System analysiert die Protokolle, identifiziert Probleme und legt den Instance- und Umgebungszustand entsprechend fest. Wenn Sie den Webserver-Proxy in Ihrer Umgebung deaktivieren und Anfragen direkt über den Webcontainer verarbeiten, können Sie erweiterte Integritätsberichte trotzdem vollumfänglich nutzen, indem Sie den Server für die Ausgabe von Protokollen in den Speicherort und im Format konfigurieren, den bzw. das der Elastic-Beanstalk-Integritäts-Agent verwendet.

Anmerkung

Die Informationen auf dieser Seite gilt nur für Linux-basierte Plattformen. Auf der Windows-Server-Plattform erhält Elastic Beanstalk diese Informationen über HTTP-Anfragen direkt von dem IIS-Webserver. Details hierzu finden Sie unter Erfassung von Webserver-Metriken in IIS auf Windows Server.

Konfiguration von Webserver-Protokollen

Elastic-Beanstalk-Plattformen sind so konfiguriert, dass sie zwei Protokolle mit Informationen über HTTP-Anfragen ausgeben. Die erste ist im Verbose-Format und bietet detaillierte Informationen über die Anfrage, einschließlich der Benutzer-Agent-Informationen des Anforderers und eines lesbaren Zeitstempels.

/var/log/nginx/access.log

Im folgenden Beispiel wird ein nginx-Proxy auf einer Ruby-Webserverumgebung ausgeführt, das Format ist jedoch vergleichbar für Apache.

172.31.24.3 - - [23/Jul/2015:00:21:20 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:21 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"

Das zweite Protokoll ist im Terse-Format. Es enthält Informationen, die nur für erweiterte Zustandsberichte relevant sind. Dieses Protokoll wird in einen Unterordner mit dem Namen healthd ausgegeben und stündlich rotiert. Alte Protokolle werden sofort nach der Rotation gelöscht.

/var/log/nginx/healthd/application.log.2015-07-23-00

Das folgende Beispiel zeigt ein Protokoll in einem für Computer lesbaren Format.

1437609879.311"/"200"0.083"0.083"177.72.242.17
1437609879.874"/"200"0.347"0.347"177.72.242.17
1437609880.006"/bad/path"404"0.001"0.001"177.72.242.17
1437609880.058"/"200"0.530"0.530"177.72.242.17
1437609880.928"/bad/path"404"0.001"0.001"177.72.242.17

Das Protokollformat für erweiterte Zustandsberichte enthält die folgenden Informationen:

• Die Uhrzeit der Anfrage in Unix-Zeit

• Den Pfad der Anfrage

• Den HTTP-Statuscode für das Ergebnis

• Die Anfragezeit

• Die Upstream-Zeit

• Den X-Forwarded-For-HTTP-Header

Für nginx-Proxys werden Zeiten in Floating-Point-Sekunden mit drei Dezimalstellen gedruckt. Für Apache werden ganze Mikrosekunden verwendet.

Anmerkung

Wenn Sie eine Warnung ähnlich der Folgenden in einer Protokolldatei sehen, in der Datum und Uhrzeit DATE-TIME ist, und Sie einen benutzerdefinierten Proxy verwenden, z. B. wie in einer Multicontainer-Docker-Umgebung, müssen Sie eine .ebextension zur Konfiguration Ihrer Umgebung verwenden, sodass die healthd Ihre Protokolldateien lesen kann:

W, [DATE-TIME #1922] WARN -- : log file "/var/log/nginx/healthd/application.log.DATE-TIME" does not exist

Sie können mit .ebextension im Beispiel für Multicontainer-Docker beginnen.

/etc/nginx/conf.d/webapp_healthd.conf

Das folgende Beispiel zeigt die Protokollkonfiguration für nginx mit dem healthd-Protokollformat hervorgehoben.

upstream my_app {
  server unix:///var/run/puma/my_app.sock;
}

log_format healthd '$msec"$uri"'
                '$status"$request_time"$upstream_response_time"'
                '$http_x_forwarded_for';

server {
  listen 80;
  server_name _ localhost; # need to listen to localhost for worker tier

  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/access.log  main;
  access_log /var/log/nginx/healthd/application.log.$year-$month-$day-$hour healthd;

  location / {
    proxy_pass http://my_app; # match the name of upstream directive which is defined above
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }

  location /assets {
    alias /var/app/current/public/assets;
    gzip_static on;
    gzip on;
    expires max;
    add_header Cache-Control public;
  }

  location /public {
    alias /var/app/current/public;
    gzip_static on;
    gzip on;
    expires max;
    add_header Cache-Control public;
  }
}

/etc/httpd/conf.d/healthd.conf

Im folgenden Beispiel wird die Protokollkonfiguration für Apache gezeigt.

LogFormat "%{%s}t\"%U\"%s\"%D\"%D\"%{X-Forwarded-For}i" healthd
CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/healthd/application.log.%Y-%m-%d-%H 3600" healthd

Generieren von Protokollen für erweiterte Zustandsberichte

Um Protokolle für den Zustandsagenten bereitzustellen, müssen Sie die folgenden Schritte ausführen:

• Protokolle im korrekten Format ausgeben, wie im vorherigen Abschnitt gezeigt

• Protokolle in Ausgabe /var/log/nginx/healthd/

• Protokolle mit folgendem Format benennen: application.log.$year-$month-$day-$hour

• Protokolle einmal pro Stunde rotieren

• Protokolle nicht kürzen