Formato dei log dello stato migliorato

AWS Elastic BeanstalkLe piattaforme utilizzano un formato di registro del server Web personalizzato per inoltrare in modo efficiente le informazioni sulle richieste HTTP al sistema di reportistica dell'integrità migliorata. che analizza i log, identifica i problemi e imposta lo stato dell'istanza e dell'ambiente di conseguenza. Se disabiliti il server proxy Web nel tuo ambiente e servi le richieste direttamente dal container Web, è comunque possibile utilizzare appieno il reporting dello stato avanzato configurando il server in modo che i log siano pubblicati nel percorso e nel formato impiegati dall'agente di stato Elastic Beanstalk.

Nota

Le informazioni contenute in questa pagina si applicano solo alle piattaforme basate su Linux. Nella piattaforma Windows Server, Elastic Beanstalk riceve le informazioni sulle richieste HTTP direttamente dal server Web IIS. Per informazioni dettagliate, consulta Acquisizione di parametri dei server Web in IIS su Windows Server.

Configurazione dei log del server Web

Le piattaforme Elastic Beanstalk sono configurate per produrre due log con informazioni sulle richieste HTTP. Il primo è in formato Verbose e fornisce informazioni dettagliate sulla richiesta, incluse le informazioni sull'utente agente del richiedente e un timestamp leggibile.

/var/log/nginx/access.log

L'esempio seguente è da un proxy nginx in esecuzione in un ambiente con server Web Ruby, ma il formato è simile a quello di 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"

Il secondo log è in formato Terse. Include informazioni rilevanti solo per il reporting sullo stato migliorato. Questo log viene pubblicato su una sottocartella denominata healthd e ruota su base oraria. I vecchi log vengono eliminati immediatamente dopo la rotazione.

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

L'esempio seguente mostra un log nel formato leggibile dal computer.

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

Il formato di log dello stato migliorato include le informazioni riportate di seguito:

• L'ora della richiesta, in tempo Unix

• Il percorso della richiesta

• Il codice di stato HTTP per il risultato

• L'orario della richiesta

• L'orario di upstream

• L'intestazione HTTP X-Forwarded-For

Per i proxy nginx, gli orari sono stampati in secondi con virgola mobile, con tre decimali. Per Apache, vengono utilizzati interi microsecondi.

Nota

Se viene visualizzato un avviso simile a questo in un file di log, dove DATE-TIME indica data e ora, e si sta utilizzando un proxy personalizzato, ad esempio in un ambiente Docker multicontainer, è necessario utilizzare un .ebextension per configurare l'ambiente in modo che healthd sia in grado di leggere i file di log:

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

È possibile iniziare con .ebextension nel Docker multicontainer di esempio.

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

L'esempio seguente mostra la configurazione di log per nginx con il formato di log healthd evidenziato.

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

L'esempio seguente mostra la configurazione di log per Apache.

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

Generazione di log per il reporting sullo stato migliorato

Per fornire i log all'agente di stato, è necessario:

• Produrre i log nel formato corretto, come illustrato nella sezione precedente

• Produrre i log su /var/log/nginx/healthd/

• Assegnare un nome ai log utilizzando il formato seguente: application.log.$year-$month-$day-$hour

• Ruotare i log una volta all'ora

• Non troncare i log