Usar logs em tempo real - Amazon CloudFront
Criar e usar configurações de log em tempo realNoções básicas sobre as configurações de log em tempo realCriar um consumidor do Kinesis Data StreamsSolução de problemas de logs em tempo real

Usar logs em tempo real

Com os logs em tempo real do CloudFront, é possível obter informações sobre solicitações feitas para 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.

Os logs em tempo real do CloudFront são configuráveis. É possível escolher:

  • A taxa de amostragem dos logs em tempo real, ou seja, a porcentagem de solicitações para as quais deseja receber registros de log em tempo real.

  • Os campos específicos que você deseja receber nos registros de log.

  • Os comportamentos de cache específicos (padrões de caminho) dos quais você deseja receber logs em tempo real.

Os logs em tempo real do CloudFront são entregues ao stream de dados de sua escolha no Amazon Kinesis Data Streams. É possível criar seu próprio consumidor de fluxo de dados do Kinesis ou usar o Amazon Data Firehose para enviar dados de log para o Amazon Simple Storage Service (Amazon S3), Amazon Redshift, Amazon OpenSearch Service (OpenSearch Service) ou um serviço de processamento de log de terceiros.

O CloudFront cobra por logs em tempo real, além das cobranças que você incorre pelo uso do Kinesis Data Streams. Para obter mais informações sobre definição de preço, consulte Definição de preço do Amazon CloudFront e Definição de preço do Amazon Kinesis Data Streams.

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 em tempo real 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 em tempo real, o número de entradas nos logs não corresponderá ao uso exibido nos relatórios de uso e faturamento da AWS.

Criar e usar configurações de log em tempo real

Para ter informações sobre solicitações feitas a uma distribuição em tempo real, use as configurações de log em tempo real. Os logs são entregues em segundos após o recebimento das solicitações. É possível criar uma configuração de log em tempo real no console do CloudFront com a AWS Command Line Interface (AWS CLI) ou a API do CloudFront.

Para usar uma configuração de log em tempo real, anexe-a a um ou mais comportamentos de cache em uma distribuição do CloudFront.

Console
Como criar uma configuração de log em tempo real

  1. Faça login no AWS Management Console e abra a página Logs no console do CloudFront em https://console.aws.amazon.com/cloudfront/v4/home?#/logs.

  2. Selecione a guia Real-time log configurations (Configurações de log em tempo real).

  3. Escolha Criar configuração.

  4. Em Name (Nome), insira um nome para a configuração.

  5. Em Sampling rate (Taxa de amostragem), insira a porcentagem de solicitações para as quais deseja receber registros de log.

  6. Em Fields (Campos), escolha os campos a serem recebidos nos registros de log em tempo real.

    • Para incluir todos os campos CMCD em seus registros de log, selecione CMCD all keys (todas as chaves CMCD).

  7. Em Endpoint, selecione um ou mais fluxos de dados do Kinesis para receber registros de log em tempo real.

    nota

    Os registros de logs em tempo real do CloudFront são entregues ao fluxo de dados especificado no Kinesis Data Streams. Para ler e analisar os registros de logs em tempo real, é possível criar seu próprio consumidor de fluxo de dados do Kinesis. Também é possível usar o Firehose para enviar dados de log para o Amazon S3, Amazon Redshift, Amazon OpenSearch Service ou um serviço de processamento de log de terceiros.

  8. Em IAM role (Perfil do IAM), selecione Create new service role (Criar novo perfil de serviço) ou selecione um perfil existente. Você deve ter permissão para criar funções do IAM.

  9. (Opcional) Em Distribution (Distribuição), selecione um comportamento de cache e uma distribuição do CloudFront a serem anexados à configuração de log em tempo real.

  10. Escolha Criar configuração.

Se tiver êxito, o console mostrará os detalhes da configuração de log em tempo real que você acabou de criar.

Para ter mais informações, consulte Noções básicas sobre as configurações de log em tempo real.

AWS CLI

Para criar uma configuração de log em tempo real com a AWS CLI, use o comando aws cloudfront create-realtime-log-config. É possível usar um arquivo de entrada para fornecer os parâmetros de entrada do comando, em vez de especificar cada parâmetro individual como entrada na linha de comando.

Como criar uma configuração de log em tempo real (CLI com arquivo de entrada)

  1. Use o comando a seguir para criar um arquivo chamado rtl-config.yaml que contém todos os parâmetros de entrada para o comando create-realtime-log-config.

    
aws cloudfront create-realtime-log-config --generate-cli-skeleton yaml-input > rtl-config.yaml

  2. Abra o arquivo chamado rtl-config.yaml que você acabou de criar. Edite o arquivo para especificar as configurações de log em tempo real desejadas e salve o arquivo. Observe o seguinte:

    • Para StreamType, o único valor válido é Kinesis.

    Para obter mais informações sobre as configurações de log em tempo real, consulte Noções básicas sobre as configurações de log em tempo real.

  3. Use o comando a seguir para criar a configuração de log em tempo real usando parâmetros de entrada do arquivo rtl-config.yaml.

    
aws cloudfront create-realtime-log-config --cli-input-yaml file://rtl-config.yaml

Se tiver êxito, a saída do comando mostrará os detalhes da configuração de log em tempo real que você acabou de criar.

Como anexar uma configuração de log em tempo real a uma distribuição existente (CLI com arquivo de entrada)

  1. Use o comando a seguir para salvar a configuração da distribuição do CloudFront que você deseja atualizar. Substitua distribution_ID pelo ID da distribuição.

    
aws cloudfront get-distribution-config --id distribution_ID --output yaml > dist-config.yaml

  2. Abra o arquivo chamado dist-config.yaml que você acabou de criar. Edite o arquivo, fazendo as seguintes alterações em cada comportamento de cache que você está atualizando para usar uma configuração de log em tempo real.

    • No comportamento de cache, adicione um campo chamado RealtimeLogConfigArn. Para o valor do campo, use o ARN da configuração de log em tempo real que você deseja anexar a esse comportamento de cache.

    • Renomeie o campo ETag para IfMatch, mas não altere o valor do campo.

    Ao concluir, salve o arquivo.

  3. Use o comando a seguir para atualizar a distribuição para usar a configuração de log em tempo real. Substitua distribution_ID pelo ID da distribuição.

    
aws cloudfront update-distribution --id distribution_ID --cli-input-yaml file://dist-config.yaml

Se tiver êxito, a saída do comando mostrará os detalhes da distribuição que você acabou de atualizar.

API

Para criar uma configuração de log em tempo real com a API do CloudFront, use a operação de API CreateRealtimeLogConfig. Para obter mais informações sobre os parâmetros especificados nessa chamada de API, consulte Noções básicas sobre as configurações de log em tempo real e a documentação de referência da API do seu SDK da AWS ou de outro cliente de API.

Depois de criar uma configuração de log em tempo real, é possível anexá-la a um comportamento de cache, usando uma das seguintes operações de API:

  • Para anexá-la a um comportamento de cache em uma distribuição existente, use UpdateDistribution.

  • Para anexá-la a um comportamento de cache em uma nova distribuição, use CreateDistribution.

Para ambas as operações de API, forneça o ARN da configuração de log em tempo real no campo RealtimeLogConfigArn, dentro de um comportamento de cache. Para mais informações sobre os outros campos especificados nessas chamadas de API, consulte Referência de configurações da distribuição e a documentação de referência da API do AWS SDK ou de outro cliente de API.

Noções básicas sobre as configurações de log em tempo real

Para usar os logs em tempo real do CloudFront, você começa criando uma configuração de log em tempo real. A configuração de log em tempo real contém informações sobre quais campos de log você deseja receber, a taxa de amostragem de registros de log e o stream de dados do Kinesis para o qual você deseja entregar os logs.

Especificamente, uma configuração de log em tempo real contém as seguintes configurações:

Nome

Um nome para identificar a configuração do log em tempo real.

Taxa de amostragem

A taxa de amostragem é um número inteiro entre 1 e 100 (inclusive) que determina a porcentagem de solicitações de visualizador enviadas ao Kinesis Data Streams como registros de log em tempo real. Para incluir cada solicitação de visualizador em seus logs em tempo real, especifique 100 para a taxa de amostragem. É possível escolher uma taxa de amostragem mais baixa para reduzir custos enquanto ainda recebe uma amostra representativa de dados de solicitação em seus logs em tempo real.

Campos

Uma lista de campos incluídos em cada registro de log em tempo real. Cada registro em log pode conter até 40 campos, e é possível optar por receber todos os campos disponíveis ou apenas os campos necessários para monitorar e analisar a performance.

A lista a seguir contém cada nome de campo e uma descrição das informações nesse campo. Os campos são listados na ordem em que aparecem nos registros de log que são entregues ao Kinesis Data Streams.

Os campos 46–63 são Common Media Client Data (CMCD) que os clientes do media player podem enviar às CDNs com cada solicitação. É possível usar esses dados para entender cada solicitação, como o tipo de mídia (áudio, vídeo), a taxa de reprodução e a duração da transmissão. Esses campos só aparecerão em seus registros em log em tempo real se forem enviados para o CloudFront.

  1. timestamp

    A data e a hora em que o servidor de borda concluiu a resposta à solicitação.

  2. c-ip

    O endereço IP do visualizador que fez a solicitação, por exemplo, 192.0.2.183 ou 2001:0db8:85a3::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.

  3. s-ip

    O endereço IP do servidor do CloudFront que atendeu à solicitação; por exemplo, 192.0.2.183 ou 2001:0db8:85a3::8a2e:0370:7334.

  4. 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.

  5. sc-status

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

  6. 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 WebSocket e gRPC, esse é o número total de bytes enviados do servidor para o cliente por meio da conexão.

  7. cs-method

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

  8. cs-protocol

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

  9. cs-host

    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 de objetos (como d111111abcdef8.cloudfront.net), esse campo conterá esse nome de domínio. Se você estiver usando nomes de domínio alternativos (CNAMES) nos URLs de objetos (como www.example.com), esse campo conterá o nome de domínio alternativo.

  10. cs-uri-stem

    Todo o URL da solicitação, inclusive a string de consulta (se houver), mas sem o nome do domínio. Por exemplo, /images/cat.jpg?mobile=true.

    nota

    Em logs padrão, o valor de cs-uri-stem não inclui a string de consulta.

  11. cs-bytes

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

  12. 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 da localização geográfica do local da borda. (Essas abreviações podem mudar no futuro.)

  13. 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.

  14. x-host-header

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

  15. 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.

  16. 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.

  17. c-ip-version

    A versão IP da solicitação (IPv4 ou IPv6).

  18. 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.

  19. 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.

  20. cs-cookie

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

    nota

    Este campo é truncado em 800 bytes.

  21. cs-uri-query

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

  22. 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.

  23. 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. Esse campo pode conter vários endereços IP separados por vírgula. Cada endereço IP pode ser um endereço IPv4 (por exemplo, 192.0.2.183) ou um endereço IPv6 (por exemplo, 2001:0db8:85a3::8a2e:0370:7334).

  24. 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.

  25. 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.

  26. 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 e gRPC 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.

  27. 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.

  28. 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.

  29. sc-content-type

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

  30. sc-content-len

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

  31. sc-range-start

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

  32. sc-range-end

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

  33. c-port

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

  34. x-edge-detailed-result-type

    Esse campo conterá o mesmo valor que o campo x-edge-result-type, exceto nos seguintes casos:

    • Quando o objeto for enviado ao visualizador do cache da camada Origin Shield, esse campo conterá OriginShieldHit.

    • Quando o objeto não estiver no cache do CloudFront e a resposta for gerada por uma função Lambda@Edge de solicitação de origem, esse campo conterá MissGeneratedResponse.

    • Quando o valor do campo x-edge-result-type for Error, esse campo conterá um dos seguintes valores com mais informações sobre o erro:

      • AbortedOrigin: o servidor encontrou um problema com a 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.

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

      • 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.

      • 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.

  35. c-country

    Um código de país que representa a localização geográfica do visualizador, conforme determinado pelo endereço IP do visualizador. Para obter uma lista de códigos de país, consulte ISO 3166-1 alfa-2.

  36. cs-accept-encoding

    O valor do cabeçalho Accept-Encoding na solicitação do visualizador.

  37. cs-accept

    O valor do cabeçalho Accept na solicitação do visualizador.

  38. cache-behavior-path-pattern

    O padrão do caminho que identifica o comportamento de cache que correspondeu à solicitação do visualizador.

  39. cs-headers

    Os cabeçalhos HTTP (nomes e valores) na solicitação do visualizador.

    nota

    Este campo é truncado em 800 bytes.

  40. cs-header-names

    Os nomes dos cabeçalhos HTTP (não valores) na solicitação do visualizador.

    nota

    Este campo é truncado em 800 bytes.

  41. cs-headers-count

    O número de cabeçalhos HTTP na solicitação do visualizador.

  42. origin-fbl

    O número de segundos de latência de primeiro byte entre o CloudFront e a origem.

  43. origin-lbl

    O número de segundos de latência de último byte entre o CloudFront e a origem.

  44. asn

    O número de sistema autônomo (ASN) do visualizador.

  45. primary-distribution-id

    Quando a implantação contínua está habilitada, essa ID identifica qual distribuição é a principal na distribuição atual.

  46. primary-distribution-dns-name

    Quando a implantação contínua está habilitada, esse valor mostra o nome de domínio principal relacionado à distribuição atual do CloudFront (por exemplo, d111111abcdef8.cloudfront.net).

    Campos de CMCD em logs em tempo real

    Para ter mais informações sobre esses campos, consulte o documento Ecossistema em vídeo de aplicativo da web de especificação CTA: Common Media Client Data CTA-5004.

  47. cmcd-encoded-bitrate

    A taxa de bits codificada do objeto de áudio ou vídeo solicitado.

  48. cmcd-buffer-length

    O tamanho do buffer do objeto de mídia solicitado.

  49. cmcd-buffer-starvation

    Se o buffer ficou inativo em algum momento entre a solicitação anterior e a solicitação do objeto. Isso pode fazer com que o player fique em um estado de rearmazenamento em buffer, o que pode interromper a reprodução de vídeo ou áudio.

  50. cmcd-content-id

    Uma string exclusiva que identifica o conteúdo atual.

  51. cmcd-object-duration

    A duração da reprodução do objeto solicitado (em milissegundos).

  52. cmcd-deadline

    O prazo a partir do momento da solicitação em que a primeira amostra desse objeto deve estar disponível, para que um estado de buffer inoperante ou outros problemas de reprodução sejam evitados.

  53. cmcd-measured-throughput

    O throughput entre o cliente e o servidor, conforme medido pelo cliente.

  54. cmcd-next-object-request

    O caminho relativo do próximo objeto solicitado.

  55. cmcd-next-range-request

    Se a próxima solicitação for uma solicitação de objeto parcial, essa string indica o intervalo de bytes a ser solicitado.

  56. cmcd-object-type

    O tipo de mídia do objeto atual que está sendo solicitado.

  57. cmcd-playback-rate

    1 se estiver em tempo real, 2 se estiver em velocidade dupla, 0 se não estiver sendo reproduzido.

  58. cmcd-requested-maximum-throughput

    O throughput máximo solicitado que o cliente considera suficiente para a entrega de ativos.

  59. cmcd-streaming-format

    O formato de streaming que define a solicitação atual.

  60. cmcd-session-id

    Um GUID que identifica a sessão de reprodução atual.

  61. cmcd-stream-type

    Token que identifica a disponibilidade do segmento. v = todos os segmentos estão disponíveis. l = os segmentos ficam disponíveis ao longo do tempo.

  62. cmcd-startup

    A chave é incluída sem um valor se o objeto for necessário com urgência durante o startup, busca ou recuperação após um evento de esvaziamento do buffer.

  63. cmcd-top-bitrate

    A representação de taxa de bits mais alta que o cliente pode reproduzir.

  64. cmcd-version

    A versão dessa especificação usada para interpretar os nomes e chave-valor definidos. Se essa chave for omitida, o cliente e o servidor devem interpretar os valores como definidos pela versão 1.

  65. r-host

    Esse campo é enviado para solicitações para a origem e indica o domínio do servidor de origem usado para fornecer o objeto. Em caso de erros, você pode usar esse campo para encontrar a última origem que foi tentada; por exemplo: cd8jhdejh6a.mediapackagev2.us-east-1.amazonaws.com.

  66. sr-reason

    Esse campo fornece o motivo pelo qual a origem foi selecionada. Ele fica vazio quando uma solicitação para a origem primária é bem-sucedida.

    Se ocorrer um failover de origem, o campo conterá o código de erro HTTP que provocou o failover, como Failover:403 ou Failover:502. Em caso de failover de origem, se a solicitação repetida também falhar e você não tiver configurado páginas de erro personalizadas, r-status indicará a resposta da segunda origem. Entretanto, se você tiver configurado páginas de erro personalizadas com o failover de origem, isso conterá a resposta da segunda origem se a solicitação falhar e, em vez disso, for exibida uma página de erro personalizada.

    Se não ocorrer nenhum failover de origem, mas ocorrer seleção de origem por meio do recurso Resiliência com Reconhecimento de Qualidade da Mídia (MQAR), isso será registrado como MediaQuality. Para ter mais informações, consulte Resiliência com Reconhecimento de Qualidade da Mídia.

  67. x-edge-mqcs

    Esse campo indica a Pontuação de Confiança na Qualidade da Mídia (MQCS) (intervalo: 0-100) para segmentos de mídia que o CloudFront recuperou nos cabeçalhos de resposta do CMSD do MediaPackage v2. Ele está disponível para solicitações que correspondam a um comportamento de cache que tenha um grupo de origem habilitado para MQAR. O CloudFront registra esse campo em log para segmentos de mídia que também são fornecidos pelo respectivo cache, além das solicitações para a origem. Para ter mais informações, consulte Resiliência com Reconhecimento de Qualidade da Mídia.

Endpoint (Kinesis Data Streams)

O endpoint contém informações sobre o Kinesis Data Streams para o qual você quer enviar logs em tempo real. Forneça o nome de recurso da Amazon (ARN) do stream de dados.

Consulte mais informações sobre como criar um Kinesis Data Streams nos tópicos a seguir no Guia do desenvolvedor do Amazon Kinesis Data Streams.

Ao criar um stream de dados, você precisa especificar o número de fragmentos. Use as seguintes informações para ajudá-lo a estimar o número de fragmentos necessários.

Como estimar o número de fragmentos para o stream de dados do Kinesis

  1. Calcule (ou estime) o número de solicitações por segundo recebidas pela sua distribuição do CloudFront.

    Você pode usar os relatórios de uso do CloudFront (no console do CloudFront) e as métricas do CloudFront (nos consoles do CloudFront e do Amazon CloudWatch) para ajudar você a calcular as solicitações por segundo.

  2. Determine o tamanho típico de um único registro de log em tempo real.

    Em geral, um único registro de log tem cerca de 500 bytes. Um grande registro que inclui todos os campos disponíveis costuma ter cerca de 1 KB.

    Caso não tenha certeza do tamanho do registro de log, você poderá habilitar logs em tempo real com uma taxa de amostragem baixa (por exemplo, 1%), depois calcular o tamanho médio do registro usando dados de monitoramento no Kinesis Data Streams (total de bytes de entrada dividido pelo número total de registros).

  3. Na página de preços do Amazon Kinesis Data Streams, em AWS Pricing Calculator, selecione Crie já sua estimativa personalizada.

    • Na calculadora, insira o número de solicitações (registros) por segundo.

    • Insira o tamanho médio de um único registro de log.

    • Selecione Mostrar cálculos.

    A calculadora de preços exibe o número de fragmentos de que você precisa e o custo estimado.

IAM role (Função do IAM)

A função do AWS Identity and Access Management (IAM) que concede ao CloudFront permissão para entregar logs em tempo real para o Kinesis Data Streams.

Ao criar uma configuração de log em tempo real com o console do CloudFront, é possível escolher Create new service role (Criar nova função de serviço) para permitir que o console crie a função do IAM para você.

Ao criar uma configuração de log em tempo real com o AWS CloudFormation ou a API do CloudFront (AWS CLI ou SDK), será necessário criar a função do IAM e fornecer o ARN da função. Para criar a função do IAM você mesmo, use as políticas a seguir.

Política de confiança da função do IAM

Para usar a seguinte política de confiança de função do IAM, substitua 111122223333 pelo número de sua Conta da AWS. O elemento Condition nessa política ajuda a evitar o problema confused deputy porque o CloudFront só pode assumir essa função em nome de uma distribuição em sua Conta da AWS.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                }
            }
        }
    ]
}

Política de permissões da função do IAM para um stream de dados não criptografado

Para usar a política a seguir, substitua arn:aws:kinesis:us-east-2:123456789012:stream/StreamName pelo ARN do seu stream de dados do Kinesis.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kinesis:DescribeStreamSummary",
                "kinesis:DescribeStream",
                "kinesis:PutRecord",
                "kinesis:PutRecords"
            ],
            "Resource": [
                "arn:aws:kinesis:us-east-2:123456789012:stream/StreamName"
            ]
        }
    ]
}

Política de permissões da função do IAM para um stream de dados criptografado

Para usar a política a seguir, substitua arn:aws:kinesis:us-east-2:123456789012:stream/StreamName pelo ARN do seu stream de dados do Kinesis e arn:aws:kms:us-east-2:123456789012:key/e58a3d0b-fe4f-4047-a495-ae03cc73d486pelo ARN da sua AWS KMS key.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kinesis:DescribeStreamSummary",
                "kinesis:DescribeStream",
                "kinesis:PutRecord",
                "kinesis:PutRecords"
            ],
            "Resource": [
                "arn:aws:kinesis:us-east-2:123456789012:stream/StreamName"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:GenerateDataKey"
            ],
            "Resource": [
                "arn:aws:kms:us-east-2:123456789012:key/e58a3d0b-fe4f-4047-a495-ae03cc73d486"
            ]
        }
    ]
}

Criar um consumidor do Kinesis Data Streams

Para ler e analisar os logs em tempo real, crie ou use um consumidor do Kinesis Data Streams. Ao criar um consumidor para logs em tempo real do CloudFront, é importante saber que os campos em cada registro de log em tempo real são sempre entregues na mesma ordem, conforme listado na seção Campos. Crie o consumidor para acomodar essa ordem fixa.

Por exemplo, considere uma configuração de log em tempo real que inclua apenas estes três campos: time-to-first-byte, sc-status e c-country. Nesse cenário, o último campo, c-country, é sempre o campo número 3 em cada registro de log. No entanto, se posteriormente você adicionar campos à configuração de log em tempo real, o posicionamento de cada campo em um registro pode ser alterado.

Por exemplo, se você adicionar os campos sc-bytes e time-taken à configuração de log em tempo real, esses campos serão inseridos em cada registro de log de acordo com a ordem mostrada na seção Campos. A ordem resultante de todos os cinco campos é time-to-first-byte, sc-status, sc-bytes, time-taken e c-country. Originalmente, o campo c-country era o campo número 3, mas agora é o campo número 5. Verifique se o consumidor da aplicação pode manusear campos que mudam de posição em um registro de log, caso você adicione campos à configuração de log em tempo real.

Solução de problemas de logs em tempo real

Depois de criar uma configuração de log em tempo real, é possível descobrir que nenhum registro (ou nem todos os registros) são entregues ao Kinesis Data Streams. Nesse caso, primeiro verifique se a distribuição do CloudFront está recebendo solicitações do visualizador. Se estiver, você poderá verificar a seguinte configuração para continuar a solução de problemas.

Permissões de função do IAM

Para entregar registros de log em tempo real ao stream de dados do Kinesis, o CloudFront usa a função do IAM na configuração de log em tempo real. Verifique se a política de confiança da função e a política de permissões da função correspondem às políticas mostradas em IAM role (Função do IAM).

Limitação do Kinesis Data Streams

Se o CloudFront gravar registros de log em tempo real no stream de dados do Kinesis de forma mais rápida do que o stream pode processar, o Kinesis Data Streams poderá limitar as solicitações do CloudFront. Nesse caso, é possível aumentar o número de fragmentos no stream de dados do Kinesis. Cada fragmento pode oferecer suporte a gravações de até 1.000 registros por segundo, até um número máximo de gravações de 1 MB de dados por segundo.