Como lidar com falhas de entrega de dados

Cada destino do Amazon Data Firehose tem seu próprio tratamento de falhas de entrega de dados.

Ao configurar um stream do Firehose, para muitos destinos, como OpenSearch Splunk e HTTP endpoints, você também configura um bucket S3 em que os dados que não foram entregues podem ser copiados. Para obter mais informações sobre como o Firehose faz backup dos dados em caso de falhas nas entregas, consulte as seções de destino relevantes nesta página. Para obter mais informações sobre como conceder acesso aos buckets do S3 nos quais os dados que não foram entregues podem ser copiados, consulte Concessão ao Firehose de acesso a um destino do Amazon S3. Quando o Firehose (a) falha em entregar dados ao destino do fluxo e (b) falha em gravar dados no bucket do S3 de backup devido a entregas com falha, ele pausa de fato a entrega do fluxo até que os dados possam ser entregues ao destino ou gravados no local do S3 para backup.

Amazon S3

A entrega de dados para o bucket do S3 pode apresentar falha por vários motivos. Por exemplo, o bucket pode não existir mais, a IAM função que o Amazon Data Firehose assume pode não ter acesso ao bucket, a rede falhou ou eventos similares. Nessas condições, o Amazon Data Firehose continua a fazer novas tentativas por até 24 horas até que a entrega tenha êxito. O tempo máximo de armazenamento de dados do Amazon Data Firehose é de 24 horas. Se a entrega de dados apresentar falha por mais de 24 horas, os dados serão perdidos.

A entrega de dados para seu bucket do S3 pode falhar por vários motivos, como:

• O bucket não existe mais.

• A IAM função assumida pelo Amazon Data Firehose não tem acesso ao bucket.

• Problemas de rede.

• Erros do S3, como HTTP 500s ou outras API falhas.

Nesses casos, o Amazon Data Firehose tentará novamente a entrega:

• DirectPut fontes: as novas tentativas continuam por até 24 horas.

• Kinesis Data Streams MSK ou fontes da Amazon: as novas tentativas continuam indefinidamente, até a política de retenção definida no stream.

O Amazon Data Firehose entrega registros com falha para um bucket de erros do S3 somente quando o processamento do Lambda ou a conversão do parquet falham. Outros cenários de falha resultarão em tentativas contínuas de repetição do S3 até que o período de retenção seja atingido. Quando o Firehose entrega registros com sucesso ao S3, ele cria um arquivo de objeto do S3 e, em casos de falhas parciais no registro, ele tenta automaticamente a entrega e atualiza o mesmo arquivo de objeto do S3 com os registros processados com sucesso.

Amazon Redshift

Para um destino do Amazon Redshift, é possível especificar um período de novas tentativas (0 a 7.200 segundos) ao criar um fluxo do Firehose.

A entrega de dados ao cluster provisionado do Amazon Redshift ou ao grupo de trabalho do Amazon Redshift Sem Servidor pode falhar por vários motivos. Por exemplo, é possível ter uma configuração de cluster incorreta do fluxo do Firehose, um cluster ou grupo de trabalho em manutenção ou uma falha de rede. Nessas condições, o Amazon Data Firehose faz novas tentativas durante o período especificado e depois pula esse lote de objetos do Amazon S3. As informações dos objetos ignorados são entregues no bucket do S3 como um arquivo manifesto na pasta errors/, que pode ser usado para alocação manual. Para obter informações sobre como armazenar COPY dados manualmente com arquivos de manifesto, consulte Usando um manifesto para especificar arquivos de dados.

Amazon OpenSearch Service e OpenSearch Serverless

Para o destino OpenSearch Service e OpenSearch Serverless, você pode especificar uma duração de nova tentativa (0 a 7200 segundos) durante a criação do stream do Firehose.

A entrega de dados para seu cluster OpenSearch de serviços ou coleção OpenSearch sem servidor pode falhar por vários motivos. Por exemplo, você pode ter uma configuração incorreta de cluster de OpenSearch serviços ou coleção OpenSearch Serverless do seu stream Firehose, um cluster de OpenSearch serviços ou coleção OpenSearch Serverless em manutenção, uma falha na rede ou eventos semelhantes. Nessas condições, o Amazon Data Firehose realiza novas tentativas durante período especificado e depois pula essa solicitação de índice. Os documentos ignorados são entregues no bucket do S3 na pasta AmazonOpenSearchService_failed/, que pode ser usada para alocação manual.

Para OpenSearch Serviço, cada documento tem o seguinte JSON formato:

{
    "attemptsMade": "(number of index requests attempted)",
    "arrivalTimestamp": "(the time when the document was received by Firehose)",
    "errorCode": "(http error code returned by OpenSearch Service)",
    "errorMessage": "(error message returned by OpenSearch Service)",
    "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)",
    "esDocumentId": "(intended OpenSearch Service document ID)",
    "esIndexName": "(intended OpenSearch Service index name)",
    "esTypeName": "(intended OpenSearch Service type name)",
    "rawData": "(base64-encoded document data)"
}

Para o OpenSearch Serverless, cada documento tem o seguinte formato: JSON

{
    "attemptsMade": "(number of index requests attempted)",
    "arrivalTimestamp": "(the time when the document was received by Firehose)",
    "errorCode": "(http error code returned by OpenSearch Serverless)",
    "errorMessage": "(error message returned by OpenSearch Serverless)",
    "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)",
    "osDocumentId": "(intended OpenSearch Serverless document ID)",
    "osIndexName": "(intended OpenSearch Serverless index name)",
    "rawData": "(base64-encoded document data)"
}
                    

Splunk

Quando o Amazon Data Firehose envia dados para o Splunk, ele aguarda uma confirmação do Splunk. Se ocorrer um erro ou a confirmação não chegar dentro do tempo limite para confirmação, o Amazon Data Firehose iniciará o contador do período de novas tentativas. Ele continuará tentando novamente até a duração da nova tentativa expirar. Depois disso, o Amazon Data Firehose considerará que houve uma falha de entrega de dados e fará o backup dos dados no bucket do Amazon S3.

Sempre que o Amazon Data Firehose envia dados para o Splunk, seja a tentativa inicial ou uma nova tentativa, ele reinicia o contador de tempo limite para confirmação. Em seguida, ele aguarda pela chegada de um reconhecimento do Splunk. Mesmo que o período de novas tentativas expire, o Amazon Data Firehose ainda aguardará a confirmação até recebê-la ou até que o tempo limite para confirmação seja atingido. Se o tempo limite para confirmação expirar, o Amazon Data Firehose verificará se ainda resta algum tempo no contador de novas tentativas. Se houver tempo restante, ele tentará executar novamente e repetirá a lógica até receber um reconhecimento ou determinará que o tempo de tentar novamente expirou.

Uma falha em receber uma confirmação não é o único tipo de erro de entrega de dados que pode ocorrer. Para obter informações sobre outros tipos de erros de entrega de dados, consulte Erros de entrega de dados do Splunk. Qualquer erro de entrega de dados dispara a lógica de novas tentativas se a duração é maior que 0.

Veja a seguir um exemplo de registro de erro.

{
  "attemptsMade": 0,
  "arrivalTimestamp": 1506035354675,
  "errorCode": "Splunk.AckTimeout",
  "errorMessage": "Did not receive an acknowledgement from HEC before the HEC acknowledgement timeout expired. Despite the acknowledgement timeout, it's possible the data was indexed successfully in Splunk. Amazon Data Firehose backs up in Amazon S3 data for which the acknowledgement timeout expired.",
  "attemptEndingTimestamp": 13626284715507,
  "rawData": "MiAyNTE2MjAyNzIyMDkgZW5pLTA1ZjMyMmQ1IDIxOC45Mi4xODguMjE0IDE3Mi4xNi4xLjE2NyAyNTIzMyAxNDMzIDYgMSA0MCAxNTA2MDM0NzM0IDE1MDYwMzQ3OTQgUkVKRUNUIE9LCg==",
  "EventId": "49577193928114147339600778471082492393164139877200035842.0"
}

HTTPdestino do endpoint

Quando o Amazon Data Firehose envia dados para um destino de HTTP endpoint, ele espera por uma resposta desse destino. Se ocorrer um erro ou se a resposta não chegar dentro do tempo limite de resposta, o Amazon Data Firehose iniciará o contador do período de novas tentativas. Ele continuará tentando novamente até a duração da nova tentativa expirar. Depois disso, o Amazon Data Firehose considerará que houve uma falha de entrega de dados e fará o backup dos dados no bucket do Amazon S3.

Toda vez que o Amazon Data Firehose envia dados para um destino de HTTP endpoint, seja a tentativa inicial ou uma nova tentativa, ele reinicia o contador de tempo limite de resposta. Em seguida, ele espera que uma resposta chegue do destino do HTTP endpoint. Mesmo que o período de novas tentativas expire, o Amazon Data Firehose ainda aguardará a resposta até recebê-la ou até que o tempo limite para confirmação seja atingido. Se o tempo limite para resposta expirar, o Amazon Data Firehose verificará se ainda resta algum tempo no contador de novas tentativas. Se restar algum tempo, ele tentará novamente e repetirá a lógica até receber uma resposta ou determinar que o período de novas tentativas expirou.

Deixar de receber confirmação não é o único tipo de erro de entrega de dados que pode ocorrer. Para obter informações sobre os outros tipos de erros de entrega de dados, consulte HTTPEndpoint Data Delivery Errors

Veja a seguir um exemplo de registro de erro.

{
	"attemptsMade":5,
	"arrivalTimestamp":1594265943615,
	"errorCode":"HttpEndpoint.DestinationException",
	"errorMessage":"Received the following response from the endpoint destination. {"requestId": "109777ac-8f9b-4082-8e8d-b4f12b5fc17b", "timestamp": 1594266081268, "errorMessage": "Unauthorized"}", 
	"attemptEndingTimestamp":1594266081318,
	"rawData":"c2FtcGxlIHJhdyBkYXRh",
	"subsequenceNumber":0,
	"dataId":"49607357361271740811418664280693044274821622880012337186.0"
}                   

Snowflake

Para o destino Snowflake, ao criar um fluxo do Firehose, é possível especificar um período opcional de nova tentativa (0 a 7200 segundos). O valor padrão para a duração da nova tentativa é de 60 segundos.

A entrega de dados para sua tabela do Snowflake pode falhar por vários motivos, como configuração incorreta de destino do Snowflake, interrupção do Snowflake, falha na rede etc. A política de novas tentativas não se aplica a erros não recuperáveis. Por exemplo, se o Snowflake rejeitar sua JSON carga porque ela tinha uma coluna extra que está faltando na tabela, o Firehose não tentará entregá-la novamente. Em vez disso, ele cria um backup para todas as falhas de inserção devido a problemas de JSON carga no seu bucket de erros do S3.

Da mesma forma, se a entrega falhar devido a um perfil, tabela ou banco de dados incorretos, o Firehose não tentará novamente gravar os dados em seu bucket do S3. A duração da nova tentativa só se aplica a falhas devido a um problema no serviço Snowflake, falhas transitórias na rede, etc. Nessas condições, o Firehose faz novas tentativas durante o período especificado antes de entregá-los ao S3. Os registros com falha são entregues na pasta snowflake-failed/, que pode ser usada para preenchimento manual.

Veja a seguir um exemplo JSON para cada registro que você entrega ao S3.

{
    "attemptsMade": 3,
    "arrivalTimestamp": 1594265943615,
    "errorCode": "Snowflake.InvalidColumns",
    "errorMessage": "Snowpipe Streaming does not support columns of type AUTOINCREMENT, IDENTITY, GEO, or columns with a default value or collation",
    "attemptEndingTimestamp": 1712937865543,
    "rawData": "c2FtcGxlIHJhdyBkYXRh"
}