Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Formato dei log dello stato migliorato
AWS Elastic Beanstalk le piattaforme utilizzano un formato di registro del server Web personalizzato per inoltrare in modo efficiente le informazioni sulle richieste HTTP al sistema di segnalazione sanitaria avanzato. 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, consultare 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.
/.log var/log/nginx/access
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.
/.log.2015-07-23-00 var/log/nginx/healthd/application
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