Logs em tempo real - Amazon CloudFront

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

Noções básicas sobre configurações de logs 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.

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

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

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

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

  6. cs-method

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

  7. cs-protocol

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

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

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

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

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

  11. 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.)

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

  13. x-host-header

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

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

  15. cs-protocol-version

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

  16. c-ip-version

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

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

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

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

  20. cs-uri-query

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

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

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

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

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

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

  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.

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

  28. sc-content-type

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

  29. sc-content-len

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

  30. sc-range-start

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

  31. sc-range-end

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

  32. c-port

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

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

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

  35. cs-accept-encoding

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

  36. cs-accept

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

  37. cache-behavior-path-pattern

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

  38. cs-headers

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

    nota

    Este campo é truncado em 800 bytes.

  39. cs-header-names

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

    nota

    Este campo é truncado em 800 bytes.

  40. cs-headers-count

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

Endpoint (stream de dados do Kinesis)

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

Para mais informações sobre como criar um stream de dados do Kinesis, consulte os seguintes tópicos 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 seu registro de log, você poderá habilitar logs em tempo real com uma taxa de amostragem baixa (por exemplo, 1%) e depois calcular o tamanho médio do registro usando dados de monitoramento no Kinesis Data Streams (número total de registros dividido pelo total de bytes de entrada).

  3. Na calculadora de definição de preço na página de definição de preço do Amazon Kinesis Data Streams, insira o número de solicitações (registros) por segundo e o tamanho médio de registro de um único registro de log. Em seguida, escolha Show calculations (Mostrar cálculos).

    A calculadora de definição de preço exibe o número de fragmentos de que você precisa. (E também exibe o custo estimado.)

    O exemplo a seguir mostra que, para um tamanho médio de registro de 0,5 KB e 50.000 solicitações por segundo, você precisa de 50 fragmentos.

    
                                    Exemplo na calculadora de definição de preço do Amazon Kinesis Data Streams indicando que, para 50.000 solicitações por segundo e um tamanho médio de registro de 0,5 KB, você precisa de 50 fragmentos.
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 e usar configurações de log em tempo real

É possível usar configurações de log em tempo real para 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 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.

Como criar uma configuração de log em tempo real (console)

  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/v3/home?#/logs.

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

  3. Selecione Create configuration (Criar configuração).

  4. Escolha a configuração desejada para a configuração do log em tempo real. Observe o seguinte:

    • Por padrão, todos os Fields (Campos) são escolhidos. Para remover um campo, execute um destes procedimentos:

      • Use o menu suspenso Choose fields (Escolher campos) para remover a seleção dos campos que você não quer incluir na configuração do log em tempo real.

      • Use o botão de expansão ( ) para exibir todos os campos e use o botão de remoção ( ) para remover os campos que você não quer incluir na configuração do log em tempo real.

    • Para a IAM role (Função do IAM), é 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ê. Você deve ter permissão para criar funções do IAM.

    • É possível usar a configuração na seção Distribution (Distribuição) para escolher um comportamento de cache e uma distribuição do CloudFront a serem anexados à configuração de log em tempo real.

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

  5. Ao concluir, escolha Create configuration (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 criar uma configuração de log em tempo real com a AWS Command Line Interface (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
    nota

    A opção yaml-input está disponível apenas na versão 2 da AWS CLI. Com a versão 1 da AWS CLI, é possível gerar um arquivo de entrada no formato JSON. Para obter mais informações, consulte Gerar um esqueleto AWS CLI e parâmetros de entrada usando um arquivo de entrada JSON ou YAML no Guia do usuário do AWS Command Line Interface.

  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 configurações de logs 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
    nota

    A opção --output yaml está disponível apenas na versão 2 da AWS CLI. Com a versão 1 da AWS CLI, é possível gerar a saída no formato JSON. Para obter mais informações, consulte Controlar a saída do comando na AWS CLI no Guia do usuário do AWS Command Line Interface.

  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.

Para criar uma configuração de log em tempo real com a API do CloudFront, use CreateRealtimeLogConfig. Para obter mais informações sobre os parâmetros especificados nessa chamada de API, consulte Noções básicas sobre configurações de logs 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 do log em tempo real, é possível anexá-la a um comportamento de cache, usando uma das seguintes chamadas 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 chamadas 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 Valores especificados ao criar ou atualizar uma distribuição e a documentação de referência da API do AWS SDK ou de outro cliente de API.

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. Quando você cria 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.