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á. # Noções básicas sobre entrega de dados no Amazon Data Firehose Quando você envia dados para o seu fluxo do Firehose, eles são automaticamente entregues no destino escolhido. A tabela a seguir explica a entrega de dados para destinos diferentes. | Destino | Detalhes | | --- | --- | | Amazon S3 | Para a entrega de dados ao Amazon S3, o Firehose concatena vários registros de entrada com base na configuração do armazenamento em buffer do seu fluxo do Firehose. Depois, entrega os ao Amazon S3; como um objeto do S3;. Por padrão, o Firehose concatena dados sem nenhum delimitador. Se quiser ter novos delimitadores de linha entre os registros, eles podem ser adicionados ativando o atributo na [configuração do console Firehose](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-s3) ou no [parâmetro da API](https://docs.aws.amazon.com/firehose/latest/APIReference/API_Processor.html). A entrega de dados entre o Firehose e o destino do Amazon S3 é criptografada com TLS (HTTPS). | | banco de dados de origem | Para entrega de dados ao Amazon Redshift, o Firehose primeiro entrega os dados recebidos ao bucket do S3 no formato descrito anteriormente. Depois, o Firehose emite um comando **COPY** do Amazon Redshift para carregar os dados do bucket do S3 no cluster provisionado do Amazon Redshift ou no grupo de trabalho Amazon Redshift sem servidor. Certifique-se de que, após o Amazon Data Firehose concatenar vários registros recebidos em um objeto do Amazon S3, o objeto do Amazon S3 possa ser copiado para o cluster provisionado do Amazon Redshift ou para o grupo de trabalho do Amazon Redshift sem servidor. Para obter mais informações, consulte [Parâmetros de formato de dados do comando COPY do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-format.html). | | OpenSearch Serviço e sem OpenSearch servidor | Para entrega de dados para OpenSearch Service e OpenSearch Serverless, o Amazon Data Firehose armazena registros de entrada com base na configuração de buffer do seu stream Firehose. Em seguida, ele gera uma solicitação em massa de OpenSearch serviço ou OpenSearch sem servidor para indexar vários registros em seu cluster de OpenSearch serviços ou coleção sem OpenSearch servidor. Certifique-se de que o registro esteja codificado em UTF-8 e reduzido a um objeto JSON de linha única antes de enviá-lo para o Amazon Data Firehose. Além disso, a rest.action.multi.allow\$1explicit\$1index opção para seu cluster de OpenSearch serviços deve ser definida como verdadeira (padrão) para receber solicitações em massa com um índice explícito definido por registro. Para obter mais informações, consulte [OpenSearch Service Configure Advanced Options](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-advanced-options) no Amazon OpenSearch Service Developer Guide. | | Splunk | Para a entrega de dados ao Splunk, o Amazon Data Firehose concatena os bytes enviados por você. Se você quer delimitadores em seus dados, como um caractere de nova linha, deve inseri-los. Certifique-se de que o Splunk é configurado para analisar quaisquer delimitadores. Para redirecionar os dados que foram entregues ao bucket de erros do S3 (backup do S3) de volta ao Splunk, siga as etapas mencionadas na [Documentação do Splunk](https://www.splunk.com/en_us/blog/tips-and-tricks/aws-technical-add-on-simplifying-error-data-re-ingestion.html). | | Endpoint de HTTP | Para entrega de dados a um endpoint de HTTP de propriedade de um provedor de serviços terceirizado com suporte, é possível usar o serviço Amazon Lambda integrado para criar uma função para transformar os registros recebidos no formato que é esperado ela integração do provedor de serviços. Entre em contato com o provedor de serviços terceirizado cujo endpoint de HTTP você escolheu como destino para saber mais sobre o formato de registro que ele aceita. | | Snowflake | Para entrega de dados ao Snowflake, o Amazon Data Firehose armazena internamente os dados em buffer por um segundo e usa as operações da API de streaming do Snowflake para inserir dados no Snowflake. Por padrão, os registros que você insere são liberados e confirmados na tabela do Snowflake a cada segundo. Depois de fazer a chamada de inserção, o Firehose emite uma CloudWatch métrica que mede quanto tempo levou para que os dados fossem confirmados no Snowflake. Atualmente, o Firehose oferece suporte a apenas um único item JSON como carga útil de registro, e não oferece suporte a matrizes JSON. Certifique-se de que sua carga útil de entrada seja um objeto JSON válido e esteja bem formada, sem aspas duplas, aspas ou caracteres de escape adicionais. | Cada destino do Firehose tem sua própria frequência de entrega de dados. Para obter mais informações, consulte [Configuração de sugestões de armazenamento em buffer](create-configure-backup.md#buffering-hints). **Registros duplicados** O Amazon Data Firehose usa at-least-once semântica para entrega de dados. Em algumas circunstâncias, como quando o tempo limite para entrega de dados é atingido, as novas tentativas de entrega feitas pelo Amazon Data Firehose poderão introduzir duplicatas se a solicitação de entrega de dados original acabar sendo atendida. Isso se aplica a todos os tipos de destino com suporte no Amazon Data Firehose, exceto os destinos do Amazon S3, as tabelas do Apache Iceberg e os destinos do Snowflake. **Topics** + [Entenda a entrega em todas AWS as contas e regiões](across.md) + [Noções básicas das especificações de solicitação e resposta de entrega de endpoint de HTTP](httpdeliveryrequestresponse.md) + [Como lidar com falhas de entrega de dados](retry.md) + [Configuração de formato de nome de objeto do Amazon S3](s3-object-name.md) + [Configurar a rotação do índice para o OpenSearch serviço](es-index-rotation.md) + [Pausa e retomada da entrega de dados](pause-restart-stream.md) # Entenda a entrega em todas AWS as contas e regiões O Amazon Data Firehose oferece suporte à entrega de dados para destinos de endpoints HTTP em todas as contas. AWS O stream do Firehose e o endpoint HTTP que você escolhe como destino podem pertencer a contas diferentes. AWS O Amazon Data Firehose também oferece suporte à entrega de dados para destinos de endpoints HTTP em todas as regiões. AWS Você pode entregar dados de um stream do Firehose em uma AWS região para um endpoint HTTP em outra região. AWS Você também pode entregar dados de um stream do Firehose para um destino de ponto de extremidade HTTP fora das AWS regiões, por exemplo, para seu próprio servidor local, definindo a URL do ponto de extremidade HTTP como o destino desejado. Nesses cenários, taxas adicionais de transferência de dados são adicionadas aos seus custos de entrega. Para obter mais informações, consulte a seção [Transferência de dados](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer) na página "Preços sob demanda". # Noções básicas das especificações de solicitação e resposta de entrega de endpoint de HTTP Para que o Amazon Data Firehose entregue dados com êxito aos endpoints de HTTP personalizados, esses endpoints devem aceitar solicitações e enviar respostas usando determinados formatos de solicitação e resposta do Amazon Data Firehose. Esta seção descreve as especificações de formato das solicitações HTTP que o serviço Amazon Data Firehose envia para endpoints de HTTP personalizados, bem como as especificações de formato das respostas HTTP que o serviço Amazon Data Firehose espera. Os endpoints de HTTP têm 3 minutos para responder a uma solicitação antes que o Amazon Data Firehose atinja o tempo limite da solicitação. O Amazon Data Firehose trata as respostas que não seguem o formato adequado como falhas de entrega. ## Formato de solicitação **Parâmetros de caminho e URL** Eles são configurados diretamente por você como parte de um único campo de URL. O Amazon Data Firehose os envia como foram configurados, sem modificação. Somente há suporte para destinos de https. As restrições de URL são aplicadas durante a configuração do fluxo de entrega. Atualmente, somente a porta 443 oferece suporte à entrega de dados de endpoint de HTTP. **Cabeçalhos HTTP - Versão X-Amz-Firehose-Protocol** Esse cabeçalho é usado para indicar a versão dos formatos de solicitação/resposta. Atualmente, a única versão é a 1.0. **Cabeçalhos HTTP - X-Amz-Firehose-Request -Id** O valor desse cabeçalho é um GUID opaco que pode ser usado para depuração e eliminação de duplicações. As implementações de endpoint devem registrar em log o valor desse cabeçalho, se possível, tanto para solicitações com êxito ou não. O ID da solicitação é mantido entre as várias tentativas da mesma solicitação. **Cabeçalhos HTTP: Content-Type** O valor do cabeçalho Content-Type é sempre `application/json`. **Cabeçalhos HTTP: Content-Encoding** Um fluxo do Firehose pode ser configurado para usar o GZIP para compactar o corpo das solicitações ao enviá-las. Quando essa compactação está habilitada, o valor do cabeçalho Content-Encoding é definido como gzip, de acordo com a prática padrão. Se a compactação não estiver habilitada, o cabeçalho Content-Encoding estará totalmente ausente. **Cabeçalhos HTTP: Content-Length** Isso é usado da maneira padrão. **Cabeçalhos HTTP - X-Amz-Firehose-Source -Arn:** O ARN do fluxo do Firehose representado no formato string ASCII. O ARN codifica a região, o ID da AWS conta e o nome do stream. Por exemplo, .`arn:aws:firehose:us-east-1:123456789:deliverystream/testStream` **Cabeçalhos HTTP - -Key X-Amz-Firehose-Access** Esse cabeçalho carrega uma chave de API ou outras credenciais. É possível criar ou atualizar a chave de API (também conhecida como token de autorização) ao criar ou atualizar seu fluxo de entrega. O Amazon Data Firehose restringe o tamanho da chave de acesso a 4.096 bytes. O Amazon Data Firehose não tenta, de maneira nenhuma, interpretar essa chave. A chave configurada é copiada literalmente para o valor desse cabeçalho. Contudo, se você usar o Secrets Manager para configurar a chave, o segredo deve seguir o formato de objeto JSON específico: `{"api_key": "..."}`. O conteúdo pode ser arbitrário e pode representar um token JWT ou uma ACCESS\$1KEY. Se um endpoint exigir credenciais com vários campos (por exemplo, nome de usuário e senha), os valores de todos os campos devem ser armazenados juntos em uma única chave de acesso em um formato que o endpoint entenda (JSON ou CSV). Esse campo pode ser codificado na base 64 se o conteúdo original for binário. O Amazon Data Firehose não modifica a and/or codificação do valor configurado e usa o conteúdo como está. **Cabeçalhos HTTP - X-Amz-Firehose-Common -Atributos** Esse cabeçalho carrega os atributos comuns (metadados) que pertencem à solicitação inteira, and/or a todos os registros dentro da solicitação. Eles são configurados diretamente por você ao criar um fluxo do Firehose. O valor desse atributo é codificado como um objeto JSON com o seguinte esquema: ``` "$schema": http://json-schema.org/draft-07/schema# properties: commonAttributes: type: object minProperties: 0 maxProperties: 50 patternProperties: "^.{1,256}$": type: string minLength: 0 maxLength: 1024 ``` Veja um exemplo abaixo: ``` "commonAttributes": { "deployment -context": "pre-prod-gamma", "device-types": "" } ``` **Corpo: tamanho máximo** O tamanho máximo do corpo é configurado por você e pode ter até 64 MiB, antes de compactado. **Corpo: esquema** O corpo leva um único documento JSON com o seguinte esquema JSON (escrito em YAML): ``` "$schema": http://json-schema.org/draft-07/schema# title: FirehoseCustomHttpsEndpointRequest description: > The request body that the Firehose service sends to custom HTTPS endpoints. type: object properties: requestId: description: > Same as the value in the X-Amz-Firehose-Request-Id header, duplicated here for convenience. type: string timestamp: description: > The timestamp (milliseconds since epoch) at which the Firehose server generated this request. type: integer records: description: > The actual records of the Firehose stream, carrying the customer data. type: array minItems: 1 maxItems: 10000 items: type: object properties: data: description: > The data of this record, in Base64. Note that empty records are permitted in Firehose. The maximum allowed size of the data, before Base64 encoding, is 1024000 bytes; the maximum length of this field is therefore 1365336 chars. type: string minLength: 0 maxLength: 1365336 required: - requestId - records ``` Veja um exemplo abaixo: ``` { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090901599 "records": [ { "data": "aGVsbG8=" }, { "data": "aGVsbG8gd29ybGQ=" } ] } ``` ## Formato de resposta **Comportamento padrão em caso de erro** Se uma resposta não estiver em conformidade com os requisitos abaixo, o servidor do Firehose a tratará como se tivesse um código de status 500 sem corpo. **Código de status** O código de status do HTTP DEVE estar no intervalo 2XX, 4XX ou 5XX. O servidor do Amazon Data Firehose NÃO segue redirecionamentos (códigos de status 3XX). Somente o código de resposta 200 é considerado uma entrega com êxito de registros para HTTP/EP. O código de resposta 413 (tamanho excedido) é considerado uma falha permanente, e o lote de registros não é enviado para o bucket de erros, se configurado. Todos os outros códigos de resposta são considerados erros passíveis de novas tentativas e estão sujeitos ao algoritmo de novas tentativas de recuo que será explicado posteriormente. **Cabeçalhos HTTP: tipo de conteúdo** O único tipo de conteúdo aceitável é aplicação/json. **Cabeçalhos HTTP: Content-Encoding** A codificação de conteúdo NÃO DEVE ser usada. O corpo DEVE estar descompactado. **Cabeçalhos HTTP: Content-Length** O cabeçalho Content-Length DEVE estar presente se a resposta tiver um corpo. **Corpo: tamanho máximo** O corpo da resposta deve ter no máximo 1 MiB. ``` "$schema": http://json-schema.org/draft-07/schema# title: FirehoseCustomHttpsEndpointResponse description: > The response body that the Firehose service sends to custom HTTPS endpoints. type: object properties: requestId: description: > Must match the requestId in the request. type: string timestamp: description: > The timestamp (milliseconds since epoch) at which the server processed this request. type: integer errorMessage: description: > For failed requests, a message explaining the failure. If a request fails after exhausting all retries, the last Instance of the error message is copied to error output S3 bucket if configured. type: string minLength: 0 maxLength: 8192 required: - requestId - timestamp ``` Veja um exemplo abaixo: ``` Failure Case (HTTP Response Code 4xx or 5xx) { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": "1578090903599", "errorMessage": "Unable to deliver records due to unknown error." } Success case (HTTP Response Code 200) { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090903599 } ``` **Lidar com respostas de erro** Em todos os casos de erro, o servidor d Amazon Data Firehose faz uma nova tentativa de entrega do mesmo lote de registros usando um algoritmo de recuo exponencial. As novas tentativas são recuadas usando um tempo de recuo inicial (1 segundo) com um fator de instabilidade de (15%) e cada nova tentativa subsequente é recuada usando a fórmula (initial-backoff-time \$1 (multiplicador (2) ^ retry\$1count)) com variação adicional. O tempo de recuo é limitado por um intervalo máximo de 2 minutos. Por exemplo, na 'n'-ésima tentativa, o tempo de recuo é = MAX(120, 2^n) \$1 random(0,85, 1,15). Os parâmetros especificados na equação anterior estão sujeitos a alterações. Consulte a documentação do AWS Firehose para ver o tempo exato de recuo inicial, o tempo máximo de recuo, o multiplicador e as porcentagens de instabilidade usadas no algoritmo de recuo exponencial. Em cada nova tentativa subsequente, o and/or destino da chave de acesso para a qual os registros são entregues pode mudar com base na configuração atualizada do stream do Firehose. O serviço Amazon Data Firehose usa, dentro do máximo possível, o mesmo ID de solicitação em todas as novas tentativas. Esse último atributo pode ser usado para eliminar duplicação pelo servidor de endpoint de HTTP. Se a solicitação ainda não for entregue após o tempo máximo permitido (com base na configuração do fluxo do Firehose), o lote de registros poderá, opcionalmente, ser entregue a um bucket de erros de acordo com a configuração do fluxo. ## Exemplos Exemplo de uma solicitação CWLog originada. ``` { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090901599, "records": [ { "data": { "messageType": "DATA_MESSAGE", "owner": "123456789012", "logGroup": "log_group_name", "logStream": "log_stream_name", "subscriptionFilters": [ "subscription_filter_name" ], "logEvents": [ { "id": "0123456789012345678901234567890123456789012345", "timestamp": 1510109208016, "message": "log message 1" }, { "id": "0123456789012345678901234567890123456789012345", "timestamp": 1510109208017, "message": "log message 2" } ] } } ] } ``` # 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 endpoints HTTP, 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](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-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, o perfil do IAM que o Amazon Data Firehose assume pode não ter acesso ao bucket, a rede pode ter falhado ou outros 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 o bucket do S3 pode apresentar falha por vários motivos, como: + O bucket não existe mais. + O perfil do IAM assumido pelo Amazon Data Firehose não tem acesso ao bucket. + Problemas de rede. + Erros do S3, como HTTP 500s ou outras falhas de API. Nesses casos, o Amazon Data Firehose tentará novamente a entrega: + **DirectPut fontes: as** novas tentativas continuam por até 24 horas. + **Fontes do Kinesis Data Streams ou do Amazon MSK:** as novas tentativas continuam indefinidamente, até a política de retenção definida no fluxo. 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 novas tentativas contínuas para o S3 até que o período de retenção seja atingido. Quando o Firehose entrega registros com sucesso ao S3, cria um arquivo de objeto do S3 e, em caso de falhas parciais no registro, tenta automaticamente uma nova entrega e atualiza o mesmo arquivo de objeto do S3 com os registros processados com êxito. ## banco de dados de origem 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 COPIAR manualmente os dados com arquivos de manifesto, consulte [Uso de um manifesto para especificar arquivos de dados](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-files-using-manifest.html). ## 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 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 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 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](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-splunk-errors). 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" } ``` ## Destino do endpoint de HTTP Quando o Amazon Data Firehose envia dados para um destino de endpoint de HTTP, 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 endpoint de HTTP, seja a tentativa inicial ou uma nova tentativa, ele reinicia o contador de tempo limite para resposta. Depois, ele espera a chegada de uma resposta do destino de endpoint de HTTP. 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 outros tipos de erros de entrega de dados, consulte [HTTP Endpoint Data Delivery Errors](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-http-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 carga útil de JSON porque ela tinha uma coluna extra que está faltando na tabela, o Firehose não tentará entregá-la novamente. Em vez disso, ele criará um backup para todas as falhas de inserção devido a problemas de carga útil de JSON em 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 de 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" } ``` # Configuração de formato de nome de objeto do Amazon S3 Quando o Firehose entrega dados para o Amazon S3, o nome da chave do objeto S3 segue o formato **, onde o sufixo tem o formato * *, começando com 1 e aumentando em 1 para cada alteração de configuração do fluxo do Firehose. É possível alterar as configurações do fluxo do Firehose (por exemplo, o nome do bucket do S3, as sugestões de armazenamento em buffer, a compactação e a criptografia). Você pode fazer isso usando o console Firehose ou a operação da [UpdateDestination](https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html)API. Para **, o Firehose adiciona um prefixo de hora padrão no formato `YYYY/MM/dd/HH`. Esse prefixo cria uma hierarquia lógica no bucket, no qual cada barra (/) cria um nível na hierarquia. É possível modificar essa estrutura especificando um prefixo personalizado que inclua expressões que sejam avaliadas no runtime. Para obter informações sobre como especificar um prefixo personalizado, consulte [Prefixos personalizados para objetos do Amazon Simple Storage Service](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html). Por padrão, o fuso horário usado para prefixo e sufixo de hora está em UTC, mas é possível alterá-lo para um fuso horário de sua preferência. Por exemplo, para usar o horário padrão do Japão em vez do UTC, você pode configurar o fuso horário Asia/Tokyo como Console de gerenciamento da AWS na [configuração de parâmetros da API CustomTimeZone ()](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html). A lista a seguir contém fusos horários com suporte no Firehose para a configuração do prefixo do S3. ## Fusos horários suportados: A seguir há uma lista de fusos horários com suporte no Firehose para a configuração do prefixo do S3. ------ #### [ Africa ] ``` Africa/Abidjan Africa/Accra Africa/Addis_Ababa Africa/Algiers Africa/Asmera Africa/Bangui Africa/Banjul Africa/Bissau Africa/Blantyre Africa/Bujumbura Africa/Cairo Africa/Casablanca Africa/Conakry Africa/Dakar Africa/Dar_es_Salaam Africa/Djibouti Africa/Douala Africa/Freetown Africa/Gaborone Africa/Harare Africa/Johannesburg Africa/Kampala Africa/Khartoum Africa/Kigali Africa/Kinshasa Africa/Lagos Africa/Libreville Africa/Lome Africa/Luanda Africa/Lubumbashi Africa/Lusaka Africa/Malabo Africa/Maputo Africa/Maseru Africa/Mbabane Africa/Mogadishu Africa/Monrovia Africa/Nairobi Africa/Ndjamena Africa/Niamey Africa/Nouakchott Africa/Ouagadougou Africa/Porto-Novo Africa/Sao_Tome Africa/Timbuktu Africa/Tripoli Africa/Tunis Africa/Windhoek ``` ------ #### [ America ] ``` America/Adak America/Anchorage America/Anguilla America/Antigua America/Aruba America/Asuncion America/Barbados America/Belize America/Bogota America/Buenos_Aires America/Caracas America/Cayenne America/Cayman America/Chicago America/Costa_Rica America/Cuiaba America/Curacao America/Dawson_Creek America/Denver America/Dominica America/Edmonton America/El_Salvador America/Fortaleza America/Godthab America/Grand_Turk America/Grenada America/Guadeloupe America/Guatemala America/Guayaquil America/Guyana America/Halifax America/Havana America/Indianapolis America/Jamaica America/La_Paz America/Lima America/Los_Angeles America/Managua America/Manaus America/Martinique America/Mazatlan America/Mexico_City America/Miquelon America/Montevideo America/Montreal America/Montserrat America/Nassau America/New_York America/Noronha America/Panama America/Paramaribo America/Phoenix America/Port_of_Spain America/Port-au-Prince America/Porto_Acre America/Puerto_Rico America/Regina America/Rio_Branco America/Santiago America/Santo_Domingo America/Sao_Paulo America/Scoresbysund America/St_Johns America/St_Kitts America/St_Lucia America/St_Thomas America/St_Vincent America/Tegucigalpa America/Thule America/Tijuana America/Tortola America/Vancouver America/Winnipeg ``` ------ #### [ Antarctica ] ``` Antarctica/Casey Antarctica/DumontDUrville Antarctica/Mawson Antarctica/McMurdo Antarctica/Palmer ``` ------ #### [ Asia ] ``` Asia/Aden Asia/Almaty Asia/Amman Asia/Anadyr Asia/Aqtau Asia/Aqtobe Asia/Ashgabat Asia/Ashkhabad Asia/Baghdad Asia/Bahrain Asia/Baku Asia/Bangkok Asia/Beirut Asia/Bishkek Asia/Brunei Asia/Calcutta Asia/Colombo Asia/Dacca Asia/Damascus Asia/Dhaka Asia/Dubai Asia/Dushanbe Asia/Hong_Kong Asia/Irkutsk Asia/Jakarta Asia/Jayapura Asia/Jerusalem Asia/Kabul Asia/Kamchatka Asia/Karachi Asia/Katmandu Asia/Krasnoyarsk Asia/Kuala_Lumpur Asia/Kuwait Asia/Macao Asia/Magadan Asia/Manila Asia/Muscat Asia/Nicosia Asia/Novosibirsk Asia/Phnom_Penh Asia/Pyongyang Asia/Qatar Asia/Rangoon Asia/Riyadh Asia/Saigon Asia/Seoul Asia/Shanghai Asia/Singapore Asia/Taipei Asia/Tashkent Asia/Tbilisi Asia/Tehran Asia/Thimbu Asia/Thimphu Asia/Tokyo Asia/Ujung_Pandang Asia/Ulaanbaatar Asia/Ulan_Bator Asia/Vientiane Asia/Vladivostok Asia/Yakutsk Asia/Yekaterinburg Asia/Yerevan ``` ------ #### [ Atlantic ] ``` Atlantic/Azores Atlantic/Bermuda Atlantic/Canary Atlantic/Cape_Verde Atlantic/Faeroe Atlantic/Jan_Mayen Atlantic/Reykjavik Atlantic/South_Georgia Atlantic/St_Helena Atlantic/Stanley ``` ------ #### [ Australia ] ``` Australia/Adelaide Australia/Brisbane Australia/Broken_Hill Australia/Darwin Australia/Hobart Australia/Lord_Howe Australia/Perth Australia/Sydney ``` ------ #### [ Europe ] ``` Europe/Amsterdam Europe/Andorra Europe/Athens Europe/Belgrade Europe/Berlin Europe/Brussels Europe/Bucharest Europe/Budapest Europe/Chisinau Europe/Copenhagen Europe/Dublin Europe/Gibraltar Europe/Helsinki Europe/Istanbul Europe/Kaliningrad Europe/Kiev Europe/Lisbon Europe/London Europe/Luxembourg Europe/Madrid Europe/Malta Europe/Minsk Europe/Monaco Europe/Moscow Europe/Oslo Europe/Paris Europe/Prague Europe/Riga Europe/Rome Europe/Samara Europe/Simferopol Europe/Sofia Europe/Stockholm Europe/Tallinn Europe/Tirane Europe/Vaduz Europe/Vienna Europe/Vilnius Europe/Warsaw Europe/Zurich ``` ------ #### [ Indian ] ``` Indian/Antananarivo Indian/Chagos Indian/Christmas Indian/Cocos Indian/Comoro Indian/Kerguelen Indian/Mahe Indian/Maldives Indian/Mauritius Indian/Mayotte Indian/Reunion ``` ------ #### [ Pacific ] ``` Pacific/Apia Pacific/Auckland Pacific/Chatham Pacific/Easter Pacific/Efate Pacific/Enderbury Pacific/Fakaofo Pacific/Fiji Pacific/Funafuti Pacific/Galapagos Pacific/Gambier Pacific/Guadalcanal Pacific/Guam Pacific/Honolulu Pacific/Kiritimati Pacific/Kosrae Pacific/Majuro Pacific/Marquesas Pacific/Nauru Pacific/Niue Pacific/Norfolk Pacific/Noumea Pacific/Pago_Pago Pacific/Palau Pacific/Pitcairn Pacific/Ponape Pacific/Port_Moresby Pacific/Rarotonga Pacific/Saipan Pacific/Tahiti Pacific/Tarawa Pacific/Tongatapu Pacific/Truk Pacific/Wake Pacific/Wallis ``` ------ Você não pode alterar o campo de sufixo, exceto **. Quando você ativa a conversão ou a compactação do formato de dados, o Firehose anexa uma extensão de arquivo com base na configuração. A tabela a seguir explica a extensão de arquivo padrão anexada pelo Firehose: | Configuração | Extensão de arquivo | | --- | --- | | Conversão de formato de dados: Parquet | .parquet | | Conversão de formato de dados: ORC | .orc | | Compactação: Gzip | .gz | | Compactação: Zip | .zip | | Compactação: Snappy | .snappy | | Compactação: Hadoop-Snappy | .hsnappy | Você também pode especificar uma extensão de arquivo de sua preferência no console ou na API do Firehose. A extensão do arquivo deve começar com um ponto (.) e pode conter os caracteres permitidos: 0-9a-z\$1-\$1.\$1' (). A extensão do arquivo não pode exceder 128 caracteres. **nota** Quando você especifica uma extensão de arquivo, ela substitui a extensão de arquivo padrão que o Firehose adiciona quando a [conversão de formato de dados](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html) ou a compactação estão habilitadas. # Noções básicas de prefixos personalizados para objetos do Amazon S3 Os objetos entregues ao Amazon S3 seguem o [formato do nome](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-namekey) . É possível especificar seu prefixo personalizado que inclui expressões que são avaliadas no runtime. O prefixo personalizado que você especificar substituirá o prefixo padrão `yyyy/MM/dd/HH`. É possível usar expressões nos seguintes formatos no seu prefixo personalizado: `!{namespace:value}`, em que `namespace` pode ser um dos que se seguem, como explicado nas próximas seções. + `firehose` + `timestamp` + `partitionKeyFromQuery` + `partitionKeyFromLambda` Se um prefixo terminar com uma barra, ele aparecerá como uma pasta no bucket do Amazon S3. Para obter mais informações, consulte [Formato de nome de objeto do Amazon S3](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name) no *Amazon Data FirehoseDeveloper Guide*. ## Namespace do `timestamp` [Os valores válidos para esse namespace são cadeias de caracteres Java válidas. DateTimeFormatter](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html) Como um exemplo, no ano 2018, a expressão `!{timestamp:yyyy}` é avaliada para `2018`. Ao avaliar carimbos de data/hora, o Firehose usa o carimbo de data/hora aproximado da chegada do registro mais antigo contido no objeto do Amazon S3 que está sendo gravado. Por padrão, o carimbo de data/hora está em UTC. Mas é possível especificar o fuso horário de sua preferência. Por exemplo, você pode configurar o fuso horário na Console de gerenciamento da AWS ou Asia/Tokyo na configuração de parâmetros da API ([CustomTimeZone](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html)) se quiser usar o horário padrão do Japão em vez do UTC. Para ver a lista de fusos horários com suporte, consulte [Formato de nome de objeto do Amazon S3](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name). Se você usar o namespace `timestamp` mais de uma vez na mesma expressão do prefixo, cada instância será avaliada no mesmo momento. ## Namespace do `firehose` Há dois valores que podem ser usados com esse namespace: `error-output-type` e `random-string`. A tabela a seguir explica como usá-los. **Os valores do namespace `firehose`.** | Conversão | Description | Exemplo de entrada | Exemplo de saída de | Observações | | --- | --- | --- | --- | --- | | error-output-type | É avaliado como uma das seguintes sequências de caracteres, dependendo da configuração do stream do Firehose e do motivo da falha: \$1processing-failed, AmazonOpenSearchService -failed, splunk-failed,,\$1. format-conversion-failed http-endpoint-failedSe você usá-lo mais de uma vez na mesma expressão, cada instância será avaliada para a mesma string de erro. | myPrefix/result=\$1\$1firehose:error-output-type\$1/\$1\$1timestamp:yyyy/MM/dd\$1 | myPrefix/result=processing-failed/2018/08/03 | O error-output-type valor só pode ser usado no ErrorOutputPrefix campo. | | random-string | Avalia para uma string aleatória de 11 caracteres. Se você usá-lo mais de uma vez na mesma expressão, cada instância será avaliada para uma nova string aleatória. | myPrefix/\$1\$1firehose:random-string\$1/ | myPrefix/046b6c7f-0b/ | É possível usá-lo com os dois tipos de prefixo.Pode ser colocado no início da string de formato para obter um prefixo aleatório, o que, às vezes, é necessário para atingir uma throughput extremamente alto com o Amazon S3. | ## Namespaces `partitionKeyFromLambda` e `partitionKeyFromQuery` Para o [particionamento dinâmico](dynamic-partitioning.md), você deve usar o seguinte formato de expressão no prefixo de bucket do S3: `!{namespace:value}`, em que o namespace pode ser `partitionKeyFromQuery`, `partitionKeyFromLambda` ou ambos. Se estiver usando análise em linha para criar as chaves de particionamento para os dados da fonte, você deverá especificar um valor de prefixo de bucket do S3 consistindo em expressões especificadas no seguinte formato: `"partitionKeyFromQuery:keyID"`. Se estiver usando função do AWS Lambda para criar as chaves de particionamento para os dados da fonte, você deverá especificar um valor de prefixo de bucket de S3 que consista em expressões especificadas no seguinte formato: `"partitionKeyFromLambda:keyID"`. Para obter mais informações, consulte "Escolha o Amazon S3 como destino" em [Criação de um fluxo do Firehose](basic-create.md#basic-create.title). ## Regras semânticas As regras a seguir se aplicam às expressões `Prefix` e `ErrorOutputPrefix`. + Para o namespace `timestamp`, qualquer caractere que não estiver em aspas simples é avaliado. Em outras palavras, qualquer string recuada com aspas simples no campo do valor é considerada literalmente. + Se você especificar um prefixo que não contenha uma expressão de namespace de carimbo de data/hora, o Firehose acrescentará a expressão `!{timestamp:yyyy/MM/dd/HH/}` ao valor no campo `Prefix`. + A sequência `!{` pode aparecer somente em expressões `!{namespace:value}`. + `ErrorOutputPrefix` poderá ser nulo somente se `Prefix` não tiver expressões; Neste caso, `Prefix` é avaliado como `yyyy/MM/DDD/HH/`, e `ErrorOutputPrefix` é avaliado como `yyyy/MM/DDD/HH/`. `DDD` representa o dia do ano. + Se você especificar uma expressão para `ErrorOutputPrefix`, deverá incluir pelo menos uma instância de `!{firehose:error-output-type}`. + `Prefix` não pode conter `!{firehose:error-output-type}`. + `Prefix` e `ErrorOutputPrefix` não podem ter mais de 512 caracteres após serem avaliados. + Se o destino for o Amazon Redshift, o `Prefix` não deverá conter expressões e o `ErrorOutputPrefix` deverá ser nulo. + Quando o destino é Amazon OpenSearch Service ou Splunk e não `ErrorOutputPrefix` é especificado, o Firehose usa `Prefix` o campo para registros com falha. + Quando o destino é o Amazon S3, o `Prefix` e o `ErrorOutputPrefix` na configuração de destino do Amazon S3 são usados para registros com êxito e registros com falha, respectivamente. Se você usar a AWS CLI ou a API, poderá usar a `ExtendedS3DestinationConfiguration` para especificar uma configuração de *backup* do Amazon S3 com seu próprio `Prefix` e `ErrorOutputPrefix`. + Quando você usa Console de gerenciamento da AWS e define o destino como Amazon S3, o Firehose usa `Prefix` e `ErrorOutputPrefix` na configuração de destino para registros bem-sucedidos e registros com falha, respectivamente. Se você especificar um prefixo usando expressões, deverá especificar o prefixo do erro, incluindo `!{firehose:error-output-type}`. + Quando você usa `ExtendedS3DestinationConfiguration` com o AWS CLI, a API ou CloudFormation, se você especificar um`S3BackupConfiguration`, o Firehose não fornece um padrão. `ErrorOutputPrefix` + Você não pode usar `partitionKeyFromLambda` `partitionKeyFromQuery` namespaces ao criar ErrorOutputPrefix expressões. ## Prefixos de exemplo **Exemplos de `Prefix` e `ErrorOutputPrefix`** | Input | Prefixo avaliado (às 10:30 AM UTC em 27 de agosto de 2018) | | --- | --- | | `Prefix`: não especificado `ErrorOutputPrefix`: `myFirehoseFailures/!{firehose:error-output-type}/` | `Prefix`: `2018/08/27/10` `ErrorOutputPrefix`: `myFirehoseFailures/processing-failed/` | | `Prefix`: `!{timestamp:yyyy/MM/dd}` `ErrorOutputPrefix`: não especificado | Entrada inválida: ErrorOutputPrefix não poderá ser nulo quando o prefixo tiver expressões | | `Prefix`: `myFirehose/DeliveredYear=!{timestamp:yyyy}/anyMonth/rand=!{firehose:random-string}` `ErrorOutputPrefix`: `myFirehoseFailures/!{firehose:error-output-type}/!{timestamp:yyyy}/anyMonth/!{timestamp:dd}` | `Prefix`: `myFirehose/DeliveredYear=2018/anyMonth/rand=5abf82daaa5` `ErrorOutputPrefix`: `myFirehoseFailures/processing-failed/2018/anyMonth/10` | | `Prefix`: `myPrefix/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/` `ErrorOutputPrefix`: `myErrorPrefix/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/!{firehose:error-output-type}` | `Prefix`: `myPrefix/year=2018/month=07/day=06/hour=23/` `ErrorOutputPrefix`: `myErrorPrefix/year=2018/month=07/day=06/hour=23/processing-failed` | | `Prefix`: `myFirehosePrefix/` `ErrorOutputPrefix`: não especificado | `Prefix`: `myFirehosePrefix/2018/08/27/` `ErrorOutputPrefix`: `myFirehosePrefix/processing-failed/2018/08/27/` | # Configurar a rotação do índice para o OpenSearch serviço Para o destino do OpenSearch serviço, você pode especificar uma opção de rotação de índice com base no tempo a partir de uma das cinco opções a seguir: **NoRotation****OneHour**,**OneDay**,**OneWeek**, ou**OneMonth**. Dependendo da opção de rotação escolhida, o Amazon Data Firehose acrescenta uma parte do carimbo de data/hora em UTC ao nome do índice especificado. Ele alterna o time stamp anexado adequadamente. O exemplo a seguir mostra o nome do índice resultante em OpenSearch Serviço para cada opção de rotação do índice, onde está o nome do índice especificado **myindex** e a data e hora de chegada. `2016-02-25T13:00:00Z` | RotationPeriod | IndexName | | --- | --- | | NoRotation | myindex | | OneHour | myindex-2016-02-25-13 | | OneDay | myindex-2016-02-25 | | OneWeek | myindex-2016-w08 | | OneMonth | myindex-2016-02 | **nota** Com a opção `OneWeek`, o Data Firehose cria índices automaticamente usando o formato -w (por exemplo,`2020-w33`), em que o número da semana é calculado usando o horário UTC e de acordo com as seguintes convenções dos EUA: A semana começa no domingo A primeira semana do ano é a primeira semana que contém um sábado naquele ano # Pausa e retomada da entrega de dados Depois que você configura um fluxo do Firehose, os dados disponíveis na fonte do fluxo são continuamente entregues ao destino. Se você se deparar com situações em que o destino do fluxo esteja temporariamente indisponível (por exemplo, durante operações de manutenção planejadas), pode ser que queira pausar temporariamente a entrega de dados e continuar quando o destino estiver disponível novamente. **Importante** Ao usar a abordagem descrita abaixo para pausar e retomar um fluxo, depois de retomar o fluxo você verá que poucos registros são entregues ao bucket de erros no Amazon S3, enquanto o restante do fluxo continua sendo entregue ao destino. Essa é uma limitação conhecida da abordagem, e ocorre porque um pequeno número de registros que não puderam ser entregues anteriormente ao destino após várias tentativas são rastreados como tendo falhado. ## Pausa de um fluxo do Firehose Para pausar a entrega de fluxo no Firehose, primeiro remova as permissões para o Firehose gravar no local de backup do S3 em caso de falhas nas entregas. Por exemplo, se quiser pausar o stream do Firehose com OpenSearch um destino, você pode fazer isso atualizando as permissões. Para obter mais informações, consulte [Conceder acesso ao Firehose a um destino de OpenSearch serviço público](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-es). Remova a permissão `"Effect": "Allow"` para a ação `s3:PutObject` e adicione explicitamente uma instrução que aplique a permissão `Effect": "Deny"` à ação `s3:PutObject` para o bucket do S3 usado para fazer backup de entregas com falha. Em seguida, desative o destino do stream (por exemplo, desative o OpenSearch domínio de destino) ou remova as permissões para que o Firehose grave no destino. Para atualizar as permissões para outros destinos, consulte a seção relativa ao destino em [Controle de acesso com o Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html). [Depois de concluir essas duas ações, o Firehose deixará de fornecer streams e você poderá monitorar isso usando CloudWatch métricas do Firehose.](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html) **Importante** Quando você pausa a entrega do fluxo no Firehose, precisa garantir que a fonte do fluxo (por exemplo, o Kinesis Data Streams ou o Managed Service for Kafka) esteja configurada para reter os dados até que a entrega do fluxo seja retomada e os dados sejam entregues ao destino. Se a fonte for DirectPUT, o Firehose reterá os dados por 24 horas. Poderá ocorrer uma perda de dados se você não retomar o fluxo de entregar os dados antes da expiração do período de retenção de dados. ## Retomada do fluxo do Firehose Para retomar a entrega, primeiro reverta a alteração feita anteriormente no destino do fluxo, ativando o destino e garantindo que o Firehose tenha permissões para entregar o fluxo ao destino. Depois, reverta as alterações feitas anteriormente nas permissões aplicadas ao bucket do S3 de backup de entregas com falha. Remova a permissão `"Effect": "Allow"` para a ação `s3:PutObject` e remova a permissão `"Effect": "Deny"` para a ação `s3:PutObject` para o bucket do S3 usado para backup das entregas com falha. Por fim, monitore usando [CloudWatch métricas do Firehose](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html) para confirmar se o stream está sendo entregue ao destino. Para visualizar e solucionar erros, use o [monitoramento do Amazon CloudWatch Logs para Firehose](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html).