Formato de log de integridade aprimorado

AWS Elastic BeanstalkAs plataformas do usam um formato personalizado de log de servidor web para retransmitir informações sobre solicitações HTTP com eficiência ao sistema de relatórios de integridade aprimorada. O sistema analisa os logs, identifica os problemas e define a integridade da instância e do ambiente adequadamente. Se você desabilitar o servidor de proxy da Web no ambiente e atender às solicitações diretamente do contêiner da Web, ainda poderá usar totalmente os relatórios de integridade aprimorada configurando o servidor para enviar logs para o local e no formato usado pelo agente de integridade do Elastic Beanstalk.

nota

As informações desta página são relevantes apenas para plataformas Linux. Na plataforma Windows Server, o Elastic Beanstalk recebe informações sobre solicitações HTTP diretamente do servidor Web do IIS. Para obter mais detalhes, consulte Métricas do servidor web capturadas no IIS no Windows Server.

Configuração do log de servidor web

As plataformas do Elastic Beanstalk são configuradas para gerar dois logs com informações sobre solicitações HTTP. O primeiro está no formato verboso e fornece informações detalhadas sobre a solicitação, incluindo informações sobre o agente do usuário do solicitante e um carimbo de data e hora legível.

/var/log/nginx/access.log

O exemplo a seguir é de um proxy nginx em execução em um ambiente de servidor da web Ruby, mas o formato é semelhante ao do 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"

O segundo log está no formato conciso. Ele inclui informações relevantes apenas para os relatórios de integridade aprimorados. Esse log é gerado em uma subpasta chamada healthd e muda de hora em hora. Os logs antigos são excluídos imediatamente após o rodízio.

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

O exemplo a seguir mostra um log no formato legível por máquina.

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

O formato do log de integridade aprimorado inclui as seguintes informações:

• A hora da solicitação, no horário do Unix.

• O caminho da solicitação

• O código de status HTTP para o resultado

• A hora da solicitação

• A hora de upstream

• O cabeçalho HTTP X-Forwarded-For

Para os proxies nginx, os horários são impressos em segundos de ponto flutuante, com três casas decimais. Para o Apache, são usados microssegundos inteiros.

nota

Se você vir um aviso semelhante ao seguinte em um arquivo de log, em que DATE-TIME é uma data e hora, e estiver usando um proxy personalizado, como em um ambiente do Docker de vários contêineres, você deverá usar um .ebextension para configurar o ambiente a fim que de healthd possa ler os arquivos de log:

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

É possível começar com .ebextension no Docker de vários contêineres demonstrativo.

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

O exemplo a seguir mostra a configuração do log para nginx com o formato de log healthd destacado.

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

O exemplo a seguir mostra a configuração do log para 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

Gerar logs para a geração de relatórios de integridade aprimorados

Para fornecer logs para o agente de integridade, faça o seguinte:

• Gere os logs no formato correto, como mostrado na seção anterior

• Gere logs em /var/log/nginx/healthd/

• Nomeie os logs usando o seguinte formato: application.log.$year-$month-$day-$hour

• Faça rodízio dos logs uma vez por hora

• Não trunque os logs