Problemas comuns - Amazon Data Firehose
Fluxo do Firehose indisponívelSem dados no destinoMétrica de atualidade de dados aumentando ou não emitidaFalha na conversão de formato de registro para Apache ParquetCampos ausentes para objeto transformado para Lambda

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Problemas comuns

Veja a seguir dicas de solução de problemas para ajudar a resolver problemas comuns ao trabalhar com um fluxo do Firehose.

Fluxo do Firehose indisponível

O stream do Firehose não está disponível como destino para CloudWatch registros, CloudWatch eventos ou ações de AWS IoT, pois alguns AWS serviços só podem enviar mensagens e eventos para um stream do Firehose que esteja no mesmo stream. Região da AWS Verifique se o seu fluxo do Firehose está localizado na mesma região que os outros serviços.

Sem dados no destino

Se não há problemas de ingestão de dados e as métricas emitidas para o fluxo do Firehose parecem boas, mas você não está vendo os dados no destino, verifique a lógica do leitor. Certifique-se de que o leitor esteja analisando corretamente todos os dados.

Métrica de atualidade de dados aumentando ou não emitida

A métrica de atualidade de dados informa o quanto os dados estão atualizados no seu fluxo do Firehose. Ela é a idade do registro de dados mais antigo no fluxo do Firehose, medido a partir do momento em que o Firehose incluiu os dados até o momento atual. O Firehose fornece métricas que podem ser usadas para monitorar a atualidade dos dados. Para identificar a métrica de atualização de dados de um destino específico, consulte Monitore o Amazon Data Firehose com métricas CloudWatch.

Se você habilitar o backup de todos os eventos ou todos os documentos, monitore duas métricas de atualização de dados separadas: uma para o destino principal e outra para o backup.

Se a métrica de atualidade de dados não estiver sendo emitida, isso significa que não há entrega ativa para o fluxo do Firehose. Isso acontece quando a entrega de dados está completamente bloqueada ou quando não há dados de entrada.

Se a métrica de atualização de dados estiver aumentando constantemente, isso significa que a entrega de dados está em atraso. Isso pode acontecer por um dos seguintes motivos.

  • O destino não comporta a taxa de entrega. Se o Firehose encontrar erros transitórios devido a grande volume de tráfego, a entrega poderá sofrer atrasos. Isso pode acontecer para destinos diferentes do Amazon S3 (pode acontecer para OpenSearch Service, Amazon Redshift ou Splunk). Certifique-se de que o destino tenha capacidade suficiente para comportar o tráfego de entrada.

  • O destino é lento. A entrega de dados pode sofrer atrasos se o Firehose encontrar alta latência. Monitore a métrica da latência do destino.

  • A função do Lambda está lenta. Isso pode levar a uma taxa de entrega de dados inferior à taxa de ingestão de dados para o fluxo do Firehose. Se possível, melhore a eficiência da função do Lambda. Por exemplo, se a função executa a E/S de rede, use vários threads ou a E/S assíncrona para aumentar o paralelismo. Além disso, considere aumentar o tamanho da memória da função do Lambda para que a alocação de CPU possa aumentar de acordo. Isso pode levar a invocações do Lambda mais rápidas. Para obter informações sobre como configurar funções Lambda, consulte Configurando AWS funções Lambda.

  • Há falhas durante a entrega de dados. Para obter informações sobre como monitorar erros usando o Amazon CloudWatch Logs, consulteMonitore o Amazon Data Firehose usando registros CloudWatch.

  • Se a fonte de dados do fluxo do Firehose for um fluxo de dados do Kinesis, é possível que esteja ocorrendo um controle de utilização. Verifique as métricas ThrottledGetRecords, ThrottledGetShardIterator e ThrottledDescribeStream. Se houver vários consumidores conectados ao fluxo de dados do Kinesis, considere o seguinte:

    • Se as métricas ThrottledGetRecords e ThrottledGetShardIterator estiverem altas, recomendamos aumentar o número de estilhaços provisionados para o fluxo de dados.

    • Se ThrottledDescribeStream for alto, recomendamos que você adicione a kinesis:listshards permissão à função configurada em KinesisStreamSourceConfiguration.

  • Dicas de baixa capacidade de buffer para o destino. Isso pode aumentar o número de ciclos necessários para que o Firehose atinja o destino, o que pode gerar atrasos na entrega. Considere aumentar o valor das dicas de buffer. Para obter mais informações, consulte BufferingHints.

  • Uma longa duração para repetições pode gerar atrasos na entrega quando os erros são frequentes. Considere reduzir a duração das repetições. Além disso, monitore os erros e tente reduzi-los. Para obter informações sobre como monitorar erros usando o Amazon CloudWatch Logs, consulteMonitore o Amazon Data Firehose usando registros CloudWatch.

  • Se o destino for Splunk e DeliveryToSplunk.DataFreshness estiver alto, mas DeliveryToSplunk.Success parecer bom, o cluster do Splunk pode estar ocupado. Libere o cluster do Splunk se possível. Como alternativa, entre em contato com o suporte da AWS e solicite um aumento no número de canais que o Firehose está usando para se comunicar com o cluster do Splunk.

Falha na conversão de formato de registro para Apache Parquet

Isso acontece se você pegar dados do DynamoDB que incluem Set o tipo, transmiti-los por meio do Lambda para um stream do Firehose e usar AWS Glue Data Catalog an para converter o formato de registro em Apache Parquet.

Quando o AWS Glue rastreador indexa os tipos de dados do conjunto do DynamoDB (StringSet,, eBinarySet)NumberSet, ele os armazena no catálogo de dados como, e, respectivamente. SET<STRING> SET<BIGINT> SET<BINARY> No entanto, para que o Firehose converta os registros de dados para o formato Apache Parquet, ele requer os tipos de dados do Apache Hive. Como os tipos de conjunto não são tipos de dados válidos do Apache Hive, há falha na conversão. Para que a conversão funcione, atualize o catálogo de dados com os tipos de dados do Apache Hive. É possível fazer isso alterando set para array no catálogo de dados.

Para alterar um ou mais tipos de dados de set para array em um catálogo AWS Glue de dados

  1. Faça login no Console de gerenciamento da AWS e abra o AWS Glue console em https://console.aws.amazon.com/glue/.

  2. No painel esquerdo, no cabeçalho Data catalog (Catálogo de dados), escolha Tables (Tabelas).

  3. Na lista de tabelas, escolha o nome da tabela na qual você precisa modificar um ou mais tipos de dados. Você será redirecionado para a página de detalhes da tabela

  4. Escolha o botão Editar esquema no canto superior direito da página de detalhes.

  5. Na coluna Data type (Tipo de dados), escolha o primeiro tipo de dados set.

  6. Na lista suspensa Column type (Tipo de coluna), altere o tipo de set para array.

  7. No ArraySchemacampo, insiraarray<string>,array<int>, ouarray<binary>, dependendo do tipo de dados apropriado para seu cenário.

  8. Selecione Atualizar.

  9. Repita as etapas anteriores para converter outros tipos set em tipos array.

  10. Escolha Salvar.

Campos ausentes para objeto transformado para Lambda

Quando você usa a transformação de dados do Lambda para alterar dados de JSON para o objeto Parquet, alguns campos podem estar ausentes após a transformação. Isso acontecerá se o seu objeto JSON tiver letras maiúsculas e a distinção entre maiúsculas e minúsculas estiver definida como false, o que pode levar a uma incompatibilidade nas chaves JSON após a transformação dos dados, causando a falta de dados no objeto Parquet resultante no bucket do S3.

Para corrigir isso, certifique-se de que a configuração do Firehose tenha deserializationOption: case.insensitive definida como true, de forma que as chaves JSON correspondam após a transformação.