Configurar e usar logs padrão (logs de acesso) - Amazon CloudFront

Configurar e usar logs padrão (logs de acesso)

Você pode configurar o CloudFront para criar arquivos de log que contenham informações detalhadas sobre todas as solicitações dos usuários que ele recebe. Esses são chamados de logs padrão, também conhecidos como logs de acesso. Se você habilitar os logs padrão, também será possível especificar o bucket do Amazon S3 no qual você deseja que o CloudFront salve arquivos.

É possível habilitar os logs padrão ao criar ou atualizar uma distribuição. Para obter mais informações, consulte Valores especificados ao criar ou atualizar uma distribuição.

O CloudFront também oferece logs em tempo real, que fornecem informações sobre solicitações feitas em uma distribuição em tempo real (os logs são entregues em segundos após o recebimento das solicitações). É possível usar os logs em tempo real para monitorar, analisar e tomar ações com base na performance da entrega de conteúdo. Para obter mais informações, consulte Logs em tempo real.

Como funciona o registro em log padrão

O diagrama a seguir mostra como o CloudFront registra informações sobre as solicitações de seus objetos.


					Fluxo básico de logs de acesso

As considerações a seguir explicam como o CloudFront registra informações sobre as solicitações de seus objetos, conforme ilustrado no diagrama anterior.

  1. Neste diagrama, você tem dois sites, A e B, e duas distribuições do CloudFront correspondentes. Os usuários solicitam seus objetos usando URLs associados a suas distribuições.

  2. O CloudFront encaminha cada solicitação para o ponto de presença adequado.

  3. O CloudFront grava dados sobre cada solicitação em um arquivo de log específico a essa distribuição. Neste exemplo, informações sobre as solicitações relacionadas à Distribuição A são registradas em um arquivo de log exclusivo para ela. Da mesma forma, informações sobre as solicitações relacionadas à Distribuição B são registradas em um arquivo de log exclusivo para ela.

  4. O CloudFront periodicamente salva o arquivo de log de uma distribuição no bucket do Amazon S3 especificado ao habilitar o registro. Depois, o CloudFront começa salvando as informações de solicitações subsequentes em um novo arquivo de log para a distribuição.

Se nenhum usuário acessar seu conteúdo em uma hora específica, você não receberá arquivos de log referentes a essa hora.

Cada entrada em um arquivo de log fornece detalhes sobre uma única solicitação. Para obter mais informações sobre o formato do arquivo de log, consulte Formato de arquivo de log padrão.

Importante

Recomendamos que você use os logs para compreender a natureza das solicitações do seu conteúdo, não como uma contabilidade completa de todas as solicitações. O CloudFront entrega logs de acesso com base no melhor esforço. A entrada do log de uma solicitação específica pode ser entregue muito depois do processamento da solicitação e, raramente, nunca ser entregue. Quando uma entrada de log for omitida dos logs de acesso, o número de entradas nos logs não corresponderá ao uso exibido nos relatórios de uso e faturamento da AWS.

Escolher um bucket do Amazon S3 para seus logs padrão

Ao habilitar o registro de uma distribuição, você especifica o bucket do Amazon S3 no qual deseja que o CloudFront armazene os arquivos de log. Se você estiver usando o Amazon S3 como origem, recomendamos que não use o mesmo bucket para os arquivos de log. O uso de um bucket separado simplifica a manutenção.

Importante

Não escolha um bucket do Amazon S3 com S3 Object Ownership (Propriedade do objeto do S3) configurado como bucket owner enforced (imposto pelo proprietário do bucket). Essa configuração desativa as ACLs para o bucket e os objetos nele contidos, o que impede que o CloudFront entregue arquivos de log para o bucket.

Não escolha um bucket do Amazon S3 em nenhuma das regiões a seguir, porque o CloudFront não entrega logs padrão para buckets nessas regiões:

  • África (Cidade do Cabo) af-south-1

  • Ásia-Pacífico (Hong Kong) ap-east-1

  • Ásia-Pacífico (Jakarta)  ap-southeast-3

  • UE (Milão) eu-south-1

  • Oriente Médio (Bahrein) me-south-1

Você pode armazenar os arquivos de log de várias distribuições no mesmo bucket. Ao habilitar o registro, você pode especificar um prefixo opcional para os nomes dos arquivos, a fim de diferenciar quais arquivos de log são associados a quais distribuições.

Permissões necessárias para configurar o registro em log padrão e acessar os arquivos de log

Importante

Não escolha um bucket do Amazon S3 com S3 Object Ownership (Propriedade do objeto do S3) configurado como bucket owner enforced (imposto pelo proprietário do bucket). Essa configuração desativa as ACLs para o bucket e os objetos nele contidos, o que impede que o CloudFront entregue arquivos de log para o bucket.

Sua conta da AWS deve ter as seguintes permissões para o bucket especificado para os arquivos de log:

  • A lista de controle de acesso (ACL) do S3 do bucket deve conceder a você FULL_CONTROL. Se você for o proprietário do bucket, sua conta terá essa permissão por padrão. Em caso negativo, o proprietário do bucket deverá atualizar a ACL do bucket.

  • s3:GetBucketAcl

  • s3:PutBucketAcl

Observe o seguinte:

ACL do bucket

Ao criar ou atualizar uma distribuição e habilitar o registro em log, o CloudFront usa essas permissões para atualizar a ACL do bucket a fim de fornecer à conta awslogsdelivery a permissão FULL_CONTROL. A conta awslogsdelivery grava arquivos de log no bucket. Caso sua conta não tenha as permissões necessárias para atualizar a ACL, ocorrerá uma falha na criação ou atualização da distribuição.

Em alguns casos, se você enviar, de forma programática, uma solicitação para criar um bucket, mas já existir um bucket com o nome especificado, o S3 redefinirá as permissões do bucket para o valor padrão. Se você configurou o CloudFront para salvar os logs de acesso em um bucket do S3 e interromper o registro nesse bucket, verifique as permissões dele para garantir que o CloudFront tenha as permissões necessárias.

Restauração da ACL do bucket

Se você remover as permissões da conta awslogsdelivery, o CloudFront não poderá salvar os logs no bucket do S3. Para permitir que o CloudFront comece a salvar logs para sua distribuição novamente, restaure a permissão da ACL de uma das seguintes maneiras:

  • Desabilite o registro em log de sua distribuição no CloudFront e habilite-o novamente. Para obter mais informações, consulte Valores especificados ao criar ou atualizar uma distribuição.

  • Adicione a permissão da ACL para awslogsdelivery manualmente navegando até o bucket do S3 no console do Amazon S3 e adicionando a permissão. Para adicionar a ACL para awslogsdelivery, você deve fornecer o ID canônico da conta, que é o seguinte:

    c4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0

    Para obter mais informações sobre como adicionar ACLs a buckets do S3, consulte Como definir permissões para buckets da ACL? no Manual do usuário do Amazon Simple Storage Service.

ACL para cada arquivo de log

Além da ACL no bucket, há uma ACL em cada arquivo de log. O proprietário do bucket tem permissão FULL_CONTROL em cada arquivo de log, o proprietário da distribuição (se não for o proprietário do bucket) não tem permissão e a conta awslogsdelivery tem permissões de leitura e de gravação.

Como desabilitar o registro

Se você desabilitar o registro, o CloudFront não excluirá as ACLs do bucket nem dos arquivos de log. Se desejar, você mesmo pode fazer isso.

Política de chaves obrigatória para buckets do SSE-KMS

Se o bucket do S3 para seus logs padrão usar criptografia no lado do servidor com AWS KMS keys (SSE-KMS) usando uma chave gerenciada pelo cliente, você deverá adicionar a seguinte instrução à política de chaves para sua chave gerenciada pelo cliente. Isso permite que o CloudFront grave arquivos de log no bucket. (Não é possível usar o SSE-KMS com a Chave gerenciada pela AWS porque o CloudFront não poderá gravar arquivos de log no bucket.)

{ "Sid": "Allow CloudFront to use the key to deliver logs", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": "kms:GenerateDataKey*", "Resource": "*" }

Se o bucket do S3 para seus logs padrão usar SSE-KMS com uma Chave de bucket do S3, você também precisará adicionar a permissão kms:Decrypt à instrução de política. Nesse caso, a declaração de política completa se parece com a seguinte.

{ "Sid": "Allow CloudFront to use the key to deliver logs", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": [ "kms:GenerateDataKey*", "kms:Decrypt" ], "Resource": "*" }

Formato do nome do arquivo

O nome de cada arquivo de log salvo pelo CloudFront no seu bucket do Amazon S3 usa o seguinte formato do nome do arquivo:

<optional prefix>/<distribution ID>.YYYY-MM-DD-HH.unique-ID.gz

A data e a hora estão em Tempo Universal Coordenado (UTC).

Por exemplo, se você usar example-prefix como prefixo e seu ID de distribuição for EMLARXS9EXAMPLE, seus nomes de arquivo serão semelhantes a este:

example-prefix/EMLARXS9EXAMPLE.2019-11-14-20.RT4KCN4SGK9.gz

Ao habilitar o registro para uma distribuição, você pode especificar um prefixo opcional para os nomes dos arquivos, a fim de diferenciar quais arquivos de log são associados a quais distribuições. Se você incluir um valor para o prefixo do arquivo de log e seu prefixo não terminar com uma barra (/), o CloudFront acrescentará uma automaticamente. Se o seu prefixo terminar com uma barra, o CloudFront não adicionará outra.

O .gz no fim do nome do arquivo indica que o CloudFront compactou o arquivo de log usando gzip.

Tempo de entrega do arquivo de log padrão

O CloudFront oferece logs padrão para uma distribuição até várias vezes por hora. Em geral, um arquivo de log contém informações sobre as solicitações recebidas pelo CloudFront durante um período específico. O CloudFront geralmente entrega o arquivo de log desse período no seu bucket do Amazon S3 em até uma hora após os eventos exibidos no log. No entanto, observe que algumas ou todas as entradas do arquivo de log referentes a um período podem demorar até 24 horas. Quando entradas de log atrasam, o CloudFront as salva em um arquivo de log no qual o nome do arquivo inclui a data e a hora do período de ocorrência das solicitações, não de entrega do arquivo.

Ao criar um arquivo de log, o CloudFront consolida as informações da sua distribuição de todos os pontos de presença que receberam solicitações de seus objetos durante o período de cobertura do arquivo de log.

O CloudFront pode salvar mais de um arquivo por período, dependendo da quantidade de solicitações recebidas pelo CloudFront dos objetos associados a uma distribuição.

O CloudFront começa a entregar os logs de acesso cerca de quatro horas depois de você habilitar o registro. É possível que você receba alguns logs de acesso antes disso.

nota

Se nenhum usuário solicitar seus objetos nesse período, você não receberá arquivos de log referentes a ele.

O CloudFront também oferece logs em tempo real, que fornecem informações sobre solicitações feitas em uma distribuição em tempo real (os logs são entregues em segundos após o recebimento das solicitações). É possível usar os logs em tempo real para monitorar, analisar e tomar ações com base na performance da entrega de conteúdo. Para obter mais informações, consulte Logs em tempo real.

Como as solicitações são registradas em log quando os cabeçalhos ou o URL de solicitação excedem o tamanho máximo

Se o tamanho total de todos os cabeçalhos de solicitação, incluindo cookies, exceder 20 KB, ou se o URL exceder 8192 bytes, o CloudFront não poderá analisar a solicitação completamente e não poderá registrá-la. Como a solicitação não está conectada, você não verá no log os arquivos que o código de status de erro HTTP retornou.

Se o corpo da solicitação exceder o tamanho máximo, a solicitação será registrada, incluindo o código de status de erro HTTP.

Analisar logs padrão

Como você pode receber vários logs de acesso por hora, recomendamos que combine todos os arquivos de log recebidos em um determinado período em um único arquivo. Assim você poderá analisar os dados desse período de forma mais precisa e completa.

Uma forma de analisar seus logs de acesso é usar o Amazon Athena. O Athena é um serviço de consulta interativo que pode ajudar você a analisar dados de serviços da AWS, incluindo o CloudFront. Para saber mais, consulte Consultar logs do Amazon CloudFront no Guia do usuário do Amazon Athena.

Além disso, as seguintes postagens de blog da AWS discutem algumas maneiras de analisar os logs de acesso.

Importante

Recomendamos que você use os logs para compreender a natureza das solicitações do seu conteúdo, não como uma contabilidade completa de todas as solicitações. O CloudFront entrega logs de acesso com base no melhor esforço. A entrada do log de uma solicitação específica pode ser entregue muito depois do processamento da solicitação e, raramente, nunca ser entregue. Quando uma entrada de log é omitida dos logs de acesso, o número de entradas nos logs não corresponderá ao uso exibido nos relatórios de uso e faturamento da AWS.

Editar as configurações do registro em log padrão

Você pode habilitar ou desabilitar o registro, alterar o bucket do Amazon S3 no qual os logs são armazenados e alterar o prefixo dos arquivos de log usando o console ou a API do CloudFront. As alterações feitas nas configurações de registro são aplicadas em até 12 horas.

Para obter mais informações, consulte os tópicos a seguir:

  • Para atualizar uma distribuição usando o console do CloudFront, consulte Atualizar uma distribuição.

  • Para atualizar uma distribuição usando a API do CloudFront, consulte UpdateDistribution na Referência de API do Amazon CloudFront.

Excluir arquivos de log padrão de um bucket do Amazon S3

O CloudFront não exclui automaticamente arquivos de log do seu bucket do Amazon S3. Para obter informações sobre como excluir arquivos de log de um bucket do Amazon S3, consulte os seguintes tópicos:

  • Com o console do Amazon S3: Excluir objetos no Guia do usuário do console do Amazon Simple Storage Service.

  • Usando a API REST: DeleteObject na Referência da API do Amazon Simple Storage Service.

Formato de arquivo de log padrão

Cada entrada em um arquivo de log fornece detalhes sobre uma única solicitação do visualizador. Os arquivos de log têm as seguintes características:

  • Use o formato do arquivo de log estendido do W3C.

  • Contêm valores separados por tabulação.

  • Contêm registros não necessariamente em ordem cronológica.

  • Contém duas linhas de cabeçalho: uma com a versão do formato do arquivo e outra que relaciona os campos do W3C incluídos em cada registro.

  • Contém equivalentes codificados em URL para espaços e alguns outros caracteres em valores de campo.

    Equivalentes codificados em URL são usados para os seguintes caracteres:

    • Códigos de caracteres ASCII 0 a 32, inclusive

    • Códigos de caracteres ASCII 127 e posterior

    • Todos os caracteres na tabela a seguir

    O padrão de codificação de URL é definido no RFC 1738.

Valor codificado em URL

Caractere

%3C

<

%3E

>

%22

"

%23

#

%25

%

%7B

{

%7D

}

%7C

|

%5C

\

%5E

^

%7E

~

%5B

[

%5D

]

%60

`

%27

'

%20

espaço

Campos padrão de arquivo de log

O arquivo de log para uma distribuição contém 33 campos. A lista a seguir contém cada nome de campo, em ordem, juntamente com uma descrição das informações nesse campo.

  1. date

    A data em que o evento ocorreu no formato YYYY-MM-DD. Por exemplo, 2019-06-30. A data e a hora estão em Tempo Universal Coordenado (UTC). Para conexões WebSockets, esta é a data em que a conexão foi encerrada.

  2. time

    A hora em que o servidor do CloudFront terminou de responder à solicitação (em UTC), por exemplo, 01:42:39. Para conexões WebSockets, este é o momento em que a conexão é fechada.

  3. x-edge-location

    O ponto de presença que atendeu à solicitação. Cada ponto de presença é identificado por um código de três letras e um número atribuído arbitrariamente (por exemplo, DFW3). O código de três letras normalmente corresponde ao código da Associação Internacional de Transportes Aéreos (IATA) de um aeroporto perto do local geográfico do ponto de presença. (Essas abreviações podem mudar no futuro.)

  4. sc-bytes

    O número total de bytes enviados pelo servidor para o visualizador em resposta à solicitação, inclusive os cabeçalhos. Para conexões WebSockets, este é o número total de bytes enviados do servidor para o cliente por meio da conexão.

  5. c-ip

    O endereço IP do visualizador que fez a solicitação, por exemplo, 192.0.2.183 ou 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Se o visualizador usar um proxy HTTP ou um load balancer para enviar a solicitação, o valor desse campo será o endereço IP do proxy ou do load balancer. Veja também o campo x-forwarded-for.

  6. cs-method

    O método de solicitação HTTP recebido do visualizador.

  7. cs(Host)

    O nome de domínio da distribuição do CloudFront (por exemplo, d111111abcdef8.cloudfront.net).

  8. cs-uri-stem

    A parte do URL da solicitação que identifica o caminho e o objeto (por exemplo, /images/cat.jpg). Os pontos de interrogação (?) em URLs e strings de consulta não são incluídos no log.

  9. sc-status

    Contém um dos seguintes valores:

    • O código de status HTTP da resposta do servidor (por exemplo, 200).

    • 000, que indica que o visualizador fechou a conexão antes que o servidor pudesse responder à solicitação. Se o visualizador fecha a conexão após o servidor começar a enviar a resposta, esse campo contém o código de status HTTP da resposta que o servidor começou a enviar.

  10. cs(Referer)

    O valor do cabeçalho Referer na solicitação. Esse é o nome do domínio que originou a solicitação. Indicadores comuns incluem: mecanismos de pesquisa, outros sites vinculados diretamente aos seus objetos e seu próprio site.

  11. cs(User-Agent)

    O valor do cabeçalho User-Agent na solicitação. O cabeçalho User-Agent identifica a origem da solicitação, como o tipo de dispositivo e o navegador que enviou a solicitação e, se a solicitação for proveniente de um mecanismo de pesquisa, o mecanismo de pesquisa.

  12. cs-uri-query

    A parte da string de consulta do URL da solicitação, se houver.

    Quando um URL não contém uma string de consulta, o valor desse campo é um hífen (-). Para obter mais informações, consulte Armazenar em cache o conteúdo com base em parâmetros de string de consulta.

  13. cs(Cookie)

    O cabeçalho Cookie na solicitação, incluindo pares de nome-valor e os atributos associados.

    Se você habilitar o registro de cookies, o CloudFront os registrará em todas as solicitações, independentemente de quais você optar por encaminhar para a origem. Quando uma solicitação não inclui um cabeçalho de cookie, o valor desse campo é um hífen (-). Para obter mais informações sobre cookies, consulte Armazenar conteúdo em cache com base em cookies.

  14. x-edge-result-type

    Como o servidor classificou a resposta após o último byte sair do servidor. Em alguns casos, o tipo de resultado pode mudar entre a hora em que o servidor está pronto para enviar a resposta e a hora em que ele conclui o envio. Veja também o campo x-edge-response-result-type.

    Por exemplo, em streaming HTTP, suponha que o servidor encontre um segmento do stream no cache. Nesse cenário, o valor desse campo normalmente seria Hit. No entanto, se o visualizador encerrar a conexão antes de o servidor entregar o segmento inteiro, o tipo do resultado final (e, portanto, o valor desse campo) será Error.

    As conexões WebSocket terão um valor de Miss para esse campo porque o conteúdo não é armazenável em cache e é enviado diretamente de volta ao servidor de origem.

    Os possíveis valores incluem:

    • Hit: o servidor forneceu o objeto do cache ao visualizador.

    • RefreshHit: o servidor encontrou o objeto no cache, mas o objeto expirou, portanto, o servidor entrou em contato com a origem para verificar se o cache tinha a versão mais recente do objeto.

    • Miss: não foi possível atender à solicitação por um objeto no cache e, portanto, o servidor a encaminhou ao servidor de origem e retornou o resultado ao visualizador.

    • LimitExceeded: a solicitação foi negada porque uma cota do CloudFront (anteriormente conhecida como limite) foi excedida.

    • CapacityExceeded: o servidor retornou um código de status HTTP 503 porque não tinha capacidade suficiente no momento da solicitação para fornecer o objeto.

    • Error: normalmente, isso significa que a solicitação resultou em um erro de cliente (o valor do campo sc-status está no intervalo 4xx) ou em um erro de servidor (o valor do campo sc-status está no intervalo 5xx). Se o valor do campo sc-status for 200 ou se o valor desse campo for Error e o valor do campo x-edge-response-result-type não for Error, isso significa que a solicitação HTTP foi bem-sucedida, mas o cliente desconectou antes de receber todos os bytes.

    • Redirect: o servidor redirecionou o visualizador de HTTP para HTTPS de acordo com as configurações de distribuição.

  15. x-edge-request-id

    Uma string opaca que identifica exclusivamente uma solicitação. O CloudFront também envia essa string no cabeçalho de resposta x-amz-cf-id.

  16. x-host-header

    O valor incluído pelo visualizador no cabeçalho Host da solicitação. Se você estiver usando o nome de domínio do CloudFront nos URLs do objeto (como d111111abcdef8.cloudfront.net), esse campo conterá esse nome de domínio. Se você estiver usando nomes de domínio alternativos (CNAMES) nos URLs dos objetos (como www.example.com), esse campo conterá o nome de domínio alternativo.

    Se você estiver usando nomes de domínio alternativos, consulte cs(Host) no campo 7 do nome de domínio associado a sua distribuição.

  17. cs-protocol

    O protocolo da solicitação do visualizador (http, https, ws ou wss).

  18. cs-bytes

    O número de bytes de dados que o visualizador adicionou à solicitação, incluindo cabeçalhos. Para conexões WebSockets, este é o número total de bytes enviados do cliente para o servidor na conexão.

  19. time-taken

    O número de segundos (até o milésimo de segundo, por exemplo, 0,082) de quando o servidor recebe a solicitação do visualizador até quando o servidor grava o último byte da resposta na fila de saída, conforme medido no servidor. Da perspectiva do visualizador, o tempo total para obter o objeto completo será mais longo que esse valor devido à latência da rede e o armazenamento em buffer do TCP.

  20. x-forwarded-for

    Se o visualizador usar um proxy HTTP ou um load balancer para enviar a solicitação, o valor do campo c-ip será o endereço IP do proxy ou do load balancer. Nesse caso, esse campo é o endereço IP do visualizador que originou a solicitação. Este campo contém um endereço IPv4 (por exemplo, 192.0.2.183) ou um endereço IPv6 (por exemplo, 2001:0db8:85a3:0000:0000:8a2e:0370:7334).

    Se o visualizador não tiver usado um proxy HTTP ou um load balancer, o valor deste campo será um hífen (-).

  21. ssl-protocol

    Quando a solicitação usa HTTPS, esse campo contém o protocolo SSL/TLS que o visualizador e o servidor negociaram para transmitir a solicitação e a resposta. Para obter uma lista de valores possíveis, consulte os protocolos SSL/TLS compatíveis em Protocolos e cifras compatíveis entre visualizadores e o CloudFront.

    Quando cs-protocol no campo 17 for http, o valor desse campo será um hífen (-).

  22. ssl-cipher

    Quando a solicitação usa HTTPS, esse campo contém a cifra SSL/TLS que o visualizador e o servidor negociaram para criptografar a solicitação e a resposta. Para obter uma lista de valores possíveis, consulte as cifras SSL/TLS compatíveis em Protocolos e cifras compatíveis entre visualizadores e o CloudFront.

    Quando cs-protocol no campo 17 for http, o valor desse campo será um hífen (-).

  23. x-edge-response-result-type

    Como o servidor classificou a resposta logo antes de devolvê-la para o visualizador. Veja também o campo x-edge-result-type. Os possíveis valores incluem:

    • Hit: o servidor forneceu o objeto do cache ao visualizador.

    • RefreshHit: o servidor encontrou o objeto no cache, mas o objeto expirou, portanto, o servidor entrou em contato com a origem para verificar se o cache tinha a versão mais recente do objeto.

    • Miss: não foi possível atender à solicitação por um objeto no cache, portanto, o servidor a encaminhou ao servidor de origem e retornou o resultado ao visualizador.

    • LimitExceeded: a solicitação foi negada porque uma cota do CloudFront (anteriormente conhecida como limite) foi excedida.

    • CapacityExceeded: o servidor retornou um erro 503 porque não tinha capacidade suficiente no momento da solicitação para fornecer o objeto.

    • Error: normalmente, isso significa que a solicitação resultou em um erro de cliente (o valor do campo sc-status está no intervalo 4xx) ou em um erro de servidor (o valor do campo sc-status está no intervalo 5xx).

      Se o valor do campo x-edge-result-type for Error e o valor desse campo não for Error, o cliente desconectou antes de concluir o download.

    • Redirect: o servidor redirecionou o visualizador de HTTP para HTTPS de acordo com as configurações de distribuição.

  24. cs-protocol-version

    A versão HTTP especificada pelo visualizador na solicitação. Os valores possíveis incluem HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2.0 e HTTP/3.0.

  25. fle-status

    Quando a criptografia em nível de campo é configurada para uma distribuição, esse campo contém um código que indica se o corpo da solicitação foi processado com êxito. Quando o servidor processa o corpo da solicitação, criptografa os valores nos campos especificados e encaminha a solicitação para a origem com êxito, o valor desse campo é Processed. Nesse caso, o valor de x-edge-result-type pode indicar um erro do lado do cliente ou do lado do servidor.

    Os valores possíveis para esse campo incluem:

    • ForwardedByContentType: o servidor encaminhou a solicitação para a origem sem análise nem criptografia, pois nenhum tipo de conteúdo foi configurado.

    • ForwardedByQueryArgs: o servidor encaminhou a solicitação para a origem sem análise nem criptografia, pois a solicitação contém um argumento de consulta que não foi configurado para a criptografia em nível de campo.

    • ForwardedDueToNoProfile: o servidor encaminhou a solicitação para a origem sem análise nem criptografia, pois nenhum perfil foi especificado na configuração da criptografia em nível de campo.

    • MalformedContentTypeClientError: o servidor rejeitou a solicitação e retornou o código de status HTTP 400 para o visualizador, pois o valor do cabeçalho Content-Type estava em um formato inválido.

    • MalformedInputClientError: o servidor rejeitou a solicitação e retornou o código de status HTTP 400 para o visualizador, pois o corpo da solicitação estava em um formato inválido.

    • MalformedQueryArgsClientError: o servidor rejeitou a solicitação e retornou o código de status HTTP 400 para o visualizador, pois um argumento de consulta estava vazio ou em um formato inválido.

    • RejectedByContentType: o servidor rejeitou a solicitação e retornou o código de status HTTP 400 para o visualizador, pois nenhum tipo de conteúdo foi especificado na configuração para criptografia em nível de campo.

    • RejectedByQueryArgs: o servidor rejeitou a solicitação e retornou o código de status HTTP 400 para o visualizador, pois nenhum argumento de consulta foi especificado na configuração para criptografia em nível de campo.

    • ServerError: o servidor de origem retornou um erro.

    Se a solicitação exceder uma cota de criptografia em nível de campo (anteriormente conhecida como limite), esse campo conterá um dos seguintes códigos de erro, e o servidor retornará o código de status HTTP 400 ao visualizador. Para obter uma lista das cotas atuais de criptografia no nível de campo, consulte Cotas para criptografia no nível de campo.

    • FieldLengthLimitClientError: um campo configurado para ser criptografado excedeu o tamanho máximo permitido.

    • FieldNumberLimitClientError: uma solicitação que a distribuição está configurada para criptografar contém o número de campos maior do que o permitido.

    • RequestLengthLimitClientError: o tamanho do corpo da solicitação excedeu o tamanho máximo permitido quando a criptografia no nível de campo foi configurada.

    Se a criptografia no nível de campo não estiver configurada para a distribuição, o valor desse campo será um hífen (-).

  26. fle-encrypted-fields

    O número de campos de criptografia em nível de campo que o servidor de borda criptografou e encaminhou para a origem. Os servidores do CloudFront fazem streaming da solicitação processada para a origem à medida que criptografam dados, portanto, esse campo pode ter um valor, mesmo que o valor de fle-status seja um erro.

    Se a criptografia no nível de campo não estiver configurada para a distribuição, o valor desse campo será um hífen (-).

  27. c-port

    O número da porta da solicitação do visualizador.

  28. time-to-first-byte

    O número de segundos entre o recebimento da solicitação e a gravação do primeiro byte da resposta, conforme medido no servidor.

  29. x-edge-detailed-result-type

    Quando o valor do campo x-edge-result-type for Error, esse campo conterá o tipo de erro específico. Quando o objeto for enviado ao visualizador do cache do Origin Shield, esse campo conterá OriginShieldHit. Em todos os outros casos, esse campo conterá o mesmo valor que x-edge-result-type. Os valores possíveis para esse campo incluem:

    • AbortedOrigin: o servidor encontrou um problema com a origem.

    • OriginCommError: a solicitação expirou durante a conexão à origem ou a leitura de dados da origem.

    • ClientCommError: a resposta ao visualizador foi interrompida devido a um problema de comunicação entre o servidor e o visualizador.

    • ClientGeoBlocked – a distribuição é configurada para recusar solicitações da localização geográfica do visualizador.

    • ClientHungUpRequest – o visualizador parou prematuramente ao enviar a solicitação.

    • Error — ocorreu um erro para o qual o tipo de erro não se encaixa em nenhuma das outras categorias. Esse tipo de erro pode ocorrer quando o servidor fornece uma resposta de erro do cache.

    • InvalidRequest: o servidor recebeu uma solicitação inválida do visualizador.

    • InvalidRequestBlocked – o acesso ao recurso solicitado é bloqueado.

    • InvalidRequestCertificate – a distribuição não corresponde ao certificado SSL/TLS para o qual a conexão HTTPS foi estabelecida.

    • InvalidRequestHeader: a solicitação continha um cabeçalho inválido.

    • InvalidRequestMethod – a distribuição não está configurada para lidar com o método de solicitação HTTP que foi usado. Isso pode acontecer quando a distribuição oferece suporte somente a solicitações armazenáveis em cache.

    • OriginConnectError: o servidor não pôde se conectar à origem.

    • OriginContentRangeLengthError – o cabeçalho Content-Length na resposta da origem não corresponde ao tamanho no cabeçalho Content-Range.

    • OriginDnsError: o servidor não pôde resolver o nome de domínio da origem.

    • OriginError – a origem retornou uma resposta incorreta.

    • OriginHeaderTooBigError: um cabeçalho retornado pela origem é muito grande para o processamento pelo servidor de borda.

    • OriginInvalidResponseError – a origem retornou uma resposta inválida.

    • OriginReadError: o servidor não pôde ler na origem.

    • OriginShieldHit: o objeto foi enviado ao visualizador do cache do Origin Shield.

    • OriginWriteError: o servidor não pôde gravar na origem.

    • OriginZeroSizeObjectError – um objeto de tamanho zero enviado da origem resultou em um erro.

    • SlowReaderOriginError – o visualizador ficou lento ao ler a mensagem que causou o erro de origem.

  30. sc-content-type

    O valor do cabeçalho do HTTP Content-Type da resposta.

  31. sc-content-len

    O valor do cabeçalho do HTTP Content-Length da resposta.

  32. sc-range-start

    Quando a resposta contém o cabeçalho do HTTP Content-Range, esse campo contém o valor inicial do intervalo.

  33. sc-range-end

    Quando a resposta contém o cabeçalho do HTTP Content-Range, esse campo contém o valor final do intervalo.

Veja abaixo um exemplo de arquivo de log para uma distribuição:

#Version: 1.0 #Fields: date time x-edge-location sc-bytes c-ip cs-method cs(Host) cs-uri-stem sc-status cs(Referer) cs(User-Agent) cs-uri-query cs(Cookie) x-edge-result-type x-edge-request-id x-host-header cs-protocol cs-bytes time-taken x-forwarded-for ssl-protocol ssl-cipher x-edge-response-result-type cs-protocol-version fle-status fle-encrypted-fields c-port time-to-first-byte x-edge-detailed-result-type sc-content-type sc-content-len sc-range-start sc-range-end 2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit SOX4xwn4XV6Q4rgb7XiVGOHms_BGlTAC4KyHmureZmBNrjGdRLiNIQ== d111111abcdef8.cloudfront.net https 23 0.001 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.001 Hit text/html 78 - - 2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit k6WGMNkEzR5BEM_SaF47gjtX9zBDO2m349OY2an0QPEaUum1ZOLrow== d111111abcdef8.cloudfront.net https 23 0.000 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.000 Hit text/html 78 - - 2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit f37nTMVvnKvV2ZSvEsivup_c2kZ7VXzYdjC-GUQZ5qNs-89BlWazbw== d111111abcdef8.cloudfront.net https 23 0.001 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.001 Hit text/html 78 - - 2019-12-13 22:36:27 SEA19-C1 900 192.0.2.200 GET d111111abcdef8.cloudfront.net /favicon.ico 502 http://www.example.com/ Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Error 1pkpNfBQ39sYMnjjUQjmH2w1wdJnbHYTbag21o_3OfcQgPzdL2RSSQ== www.example.com http 675 0.102 - - - Error HTTP/1.1 - - 25260 0.102 OriginDnsError text/html 507 - - 2019-12-13 22:36:26 SEA19-C1 900 192.0.2.200 GET d111111abcdef8.cloudfront.net / 502 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Error 3AqrZGCnF_g0-5KOvfA7c9XLcf4YGvMFSeFdIetR1N_2y8jSis8Zxg== www.example.com http 735 0.107 - - - Error HTTP/1.1 - - 3802 0.107 OriginDnsError text/html 507 - - 2019-12-13 22:37:02 SEA19-C2 900 192.0.2.200 GET d111111abcdef8.cloudfront.net / 502 - curl/7.55.1 - - Error kBkDzGnceVtWHqSCqBUqtA_cEs2T3tFUBbnBNkB9El_uVRhHgcZfcw== www.example.com http 387 0.103 - - - Error HTTP/1.1 - - 12644 0.103 OriginDnsError text/html 507 - -

Cobranças de logs padrão

O registro em log padrão é um recurso opcional do CloudFront. Não há cobrança adicional para a habilitação do registro em log padrão. No entanto, você acumula as cobranças normais do Amazon S3 para armazenar e acessar os arquivos nele (é possível excluí-los a qualquer momento).

Para mais informações sobre a definição de preço do Amazon S3, consulte Definição de preço do Amazon S3.

Para mais informações sobre preços do CloudFront, consulte Definição de preço do CloudFront.