Perguntas frequentes sobre o Amazon Data Firehose

A API do Firehose está disponível em SDKs da Amazon Web Services. Para ver uma lista das linguagens de programação ou plataformas para os SDKs da Amazon Web Services, consulte Ferramentas da Amazon Web Services.

O Kinesis Agent é uma aplicação Java predefinido que oferece uma maneira fácil de coletar e enviar dados para o seu fluxo do Firehose. Você pode instalar o atendente em ambientes de servidor baseados em Linux, como servidores Web, servidores de log e servidores de banco de dados. O atendente monitora determinados arquivos e envia continuamente dados para o seu fluxo do Firehose. No momento, o atendente do Amazon Kinesis é compatível com o Amazon Linux, o Red Hat Enterprise Linux e o Microsoft Windows. Para mais informações, consulte Gravar no Kinesis Data Firehose por meio do agente do Kinesis.

Você pode baixar e instalar o Kinesis Agent usando o comando e o link a seguir:

• No Amazon Linux: sudo yum install –y aws-kinesis-agent
• No Red Hat Enterprise Linux: sudo yum install –y https://s3.amazonaws.com/streaming-data-agent/aws-kinesis-agent-latest.amzn1.noarch.rpm
• Do GitHub: awlabs/amazon-kinesis-agent
• No Windows: https://docs.aws.amazon.com/kinesis-agent-windows/latest/userguide/getting-started.html#getting-started-installation

Você pode adicionar dados a um fluxo do Firehose com o Kinesis Agent ou com as operações PutRecord e PutRecordBatch do Firehose. A operação PutRecord permite um único registro de dados em uma chamada de API e a operação PutRecordBatch permite vários registros de dados em uma chamada de API. Para mais informações, consulte PutRecord e PutRecordBatch.

Quando você cria ou atualiza um fluxo do Firehose por meio do Console da AWS ou de APIs do Firehose, pode configurar um cluster/tópico do Amazon MSK como fonte do fluxo do Firehose. Uma vez configurado, o Firehose lerá automaticamente os dados do tópico do MSK e os carregará nos buckets do S3 especificados.

Você pode reduzir a complexidade e a sobrecarga da operação de sua aplicação transformando dados de streaming obtidos de seus tópicos do Amazon MSK e carregando-os no Amazon S3 sem precisar de código. Por exemplo, com o Amazon MSK e o Firehose, você não tem código, atributos integrados de conversão e transformação de dados, como conversão de formato Parquet/ORC, armazenamento em buffer de dados e validação de dados do lado do serviço. Você também obtém novas tentativas de entrega automática, retenção de dados, ajuste de escala automático e redundância, portanto os dados são entregues de maneira confiável.

Para usar esse atributo, os clusters do MSK devem ter endpoints públicos ou links privados habilitados.

Sim, o Firehose pode se conectar aos clusters do Amazon MSK que estão disponíveis em diferentes contas da AWS. O Firehose também pode fazer entregas em buckets do S3 que pertencem a contas diferentes.

A hora certa para começar a consumir dados do tópico do Amazon MSK é a hora de criação do fluxo do Firehose. O Firehose não lê os valores de deslocamento personalizados.

Ao criar ou atualizar seu stream do Firehose por meio do Console da AWS ou das APIs do Firehose, você pode configurar um stream do Firehose como a origem do seu stream do Firehose. Uma vez configurado, o Firehose lerá automaticamente os dados do fluxo do Firehose e os carregará para os destinos especificados.

O Firehose chama o GetRecords() do Kinesis Data Streams uma vez por segundo para cada fragmento do Kinesis.

O Firehose começa a ler os dados da posição MAIS RECENTE do seu Kinesis Data Stream quando ele é configurado como a origem de um stream do Firehose. Para mais informações sobre a posição do Kinesis Data Stream, consulte GetShardIterator na referência de APIs do serviço Kinesis Data Streams.

Sim, você pode. No entanto, a chamada ao GetRecords() do Firehose é considerada em relação ao limite geral do controle de utilização do fragmento do Kinesis. Portanto, é necessário planejar o fluxo do Firehose juntamente com outros aplicativos do Kinesis para garantir que esse limite geral não seja ultrapassado. Para mais informações, consulte Kinesis Data Streams Limits no guia do desenvolvedor do Kinesis Data Streams.

Não. Quando um Kinesis Data Stream é configurado como origem de um fluxo do Firehose, as operações PutRecord e PutRecordBatch do Firehose são desabilitadas. Em vez disso, adicione o Kinesis Data Stream por meio das operações PutRecord e PutRecords do Kinesis Data Streams.

Para adicionar dados do AWS IoT ao fluxo do Firehose, crie uma ação do AWS IoT que envia eventos ao fluxo do Firehose. Para mais informações. Consulte Escrevendo no Amazon Data Firehose usando o AWS IoT no guia do desenvolvedor do Firehose.

Quando você cria ou atualiza um fluxo do Firehose por meio do Console da AWS ou de APIs do Firehose, você pode configurar um Direct PUT como origem do fluxo do Firehose. Depois que o fluxo for criado, o fluxo do Firehose criado poderá ser configurado como seu fluxo do Firehose na seção Vended Logs do console de logs do VPC Flow.

Você adiciona dados ao seu stream Firehose a partir do CloudWatch Logs criando um filtro de assinatura do CloudWatch Logs que envia eventos para seu stream Firehose. Para mais informações, consulte Uso de filtros de assinatura do CloudWatch Logs no guia do usuário do Amazon CloudWatch.

Para adicionar dados do CloudWatch Events a um fluxo do Firehose, crie uma regra do CloudWatch Events com o fluxo do Firehose como destino. Para mais informações, consulte Gravar no Amazon Data Firehose usando o CloudWatch Events no guia do desenvolvedor do Firehose.

Você adiciona dados ao fluxo do Firehose a partir do console AWS EventBridge. Para mais informações, consulte a documentação do AWS EventBridge.

O Firehose permite que você criptografe dados depois de entregues ao seu bucket do Amazon S3. Ao criar o seu fluxo do Firehose, você pode optar por criptografar dados com uma chave do AWS Key Management Service (KMS) que seja de sua propriedade. Para mais informações sobre o KMS, consulte o AWS Key Management Service.

O Firehose assume o perfil do IAM que você especifica para acessar recursos, como o bucket do Amazon S3 e o domínio do Amazon OpenSearch. Para mais informações, consulte Como controlar o acesso com o Firehose no guia do desenvolvedor do Firehose.

Sim, o Firehose usa o AWS PrivateLink para se conectar a bancos de dados que estão dentro da VPC.

Sim, ao configurar um fluxo de entrega do Firehose, você pode selecionar tabelas e colunas específicas no banco de dados de origem. O Firehose fornece atualizações do CDC somente para as tabelas e colunas selecionadas.

Sim, quando você configura o Firehose para entregar fluxos de CDC em tabelas do Apache Iceberg no Amazon S3, você pode configurar o fluxo para entregar registros de diferentes tabelas de origem em diferentes tabelas do Apache Iceberg.

O Firehose é compatível com a conversão de formatos de dados de dados brutos ou Json para nos formatos exigidos pelos armazenamentos de dados de destino, sem precisar construir seus próprios pipelines de processamento de dados. O Firehose também permite que você particione dinamicamente dados de transmissão antes de entregá-los ao S3 usando chaves bem definidas estática ou dinamicamente como “customer_id” ou “transaction_id”. O Firehose agrupa os dados por essas chaves e entrega em prefixos exclusivos de chave do S3, facilitando a realização de análises econômicas de alta performance no S3 usando Athena, EMR e Redshift Spectrum.

Além disso, para a opção de conversão em formatos integrados no Amazon Data Firehose, você pode usar uma função do AWS Lambda para preparar e transformar dados brutos de entrada em seu fluxo do Firehose antes de carregá-los para os destinos. Você pode configurar uma função do AWS Lambda para transformação de dados ao criar um novo stream do Firehose ou ao editar um stream existente do Firehose. A Amazon criou vários esquema do Lambda que você pode escolher para um início rápido. Para a lista completa, leia o Guia do desenvolvedor do Amazon Data Firehose.

O Amazon Data Firehose permite a compactação dos seus dados antes de entregá-los ao Amazon S3. No momento, o serviço oferece suporte aos formatos de compactação GZIP, ZIP e SNAPPY. Se os dados já estiverem carregados no Amazon Redshift, somente o GZIP será compatível.

É possível usar o recurso de assinatura do CloudWatch Logs para fazer a transmissão de dados do CloudWatch Logs para o Firehose. Todos os logs de evento do CloudWatch Logs já estão compactados no formato gzip. Portanto, recomendamos desabilitar a configuração de compactação do Firehose para evitar a compactação dupla. Para mais informações sobre o recurso de assinatura do CloudWatch Logs, consulte Filtros de assinatura com o Amazon Data Firehose no manual do usuário do Amazon CloudWatch Logs.

Todos os registros transformados do Lambda devem ser retornados para o Firehose com os três parâmetros a seguir; caso contrário, o Firehose rejeitará os registros e os tratará como falha na transformação de dados.

• recordId: o Firehose envia um recordId juntamente com cada registro para o Lambda durante a invocação. Cada registro transformado deve ser retornado com o mesmo recordId. Qualquer incompatibilidade entre o recordId original e o recordId retornado será tratada como falha na transformação de dados.
   
• result: o status do resultado de transformação de cada registro. Os seguintes valores são permitidos para este parâmetro: “Ok” se o registro for transformado com êxito conforme o esperado. “Dropped” se a lógica de processamento descartar o registro intencionalmente conforme o esperado. “ProcessingFailed” se o registro não puder ser transformado conforme o esperado. O Firehose trata os registros retornados com os status “Ok” e “Dropped” como registros processados com êxito, e os registros com o status “ProcessingFailed” como registros com falha no processamento quando ele gera as métricas SucceedProcessing.Records e SucceedProcessing.Bytes.
   
• data: a carga de dados transformados após a codificação based64.

Se você habilitar a transformação de dados com o Lambda, o Firehose poderá registrar no Amazon CloudWatch Logs qualquer erro de invocação e entrega de dados do Lambda para poder visualizar os logs de erro específicos em caso de falha na invocação ou entrega de dados do Lambda. Para obter mais informações, consulte Monitoramento com o Amazon CloudWatch Logs.

Se você usar a transformação de dados com o Lambda, poderá habilitar o backup do registro de origem e o Amazon Data Firehose entregará os dados de entrada não transformados para um bucket do S3 separado. Você pode especificar um prefixo extra a ser adicionado na frente do prefixo de tempo UTC “AAAA/MM/DD/HH” gerado pelo Firehose.

O particionamento dinâmico do Firehose elimina as complexidades e os atrasos do particionamento manual na fonte ou após o armazenamento dos dados e permite análises mais rápidas para consultar conjuntos de dados otimizados. Isso torna os conjuntos de dados imediatamente disponíveis para ferramentas analíticas para executar suas consultas com eficiência e aprimora o controle de acesso refinado para os dados. Por exemplo, os clientes de automação de marketing podem particionar dados dinamicamente por ID do cliente, permitindo que consultas específicas do cliente consultem conjuntos de dados otimizados e forneçam resultados mais rapidamente. Os clientes de operações de TI ou monitoramento de segurança podem criar agrupamentos com base no carimbo de data/hora do evento embutido em logs para consultar conjuntos de dados otimizados e obter resultados mais rapidamente. Esse recurso combinado com o recurso de conversão do formato JSON-to-parquet do Amazon Data Firehose faz dele uma opção de ETL de transmissão ideal para o S3.

Você pode configurar o recurso de particionamento de dados do Firehose por meio do Console de Gerenciamento da AWS, CLIs ou SDKs. Ao criar ou atualizar um fluxo do Firehose, selecione o Amazon S3 como destino de entrega do fluxo do Firehose e habilite o particionamento dinâmico. Você pode especificar chaves ou criar uma expressão que será avaliada em runtime para definir as chaves usadas para particionamento. Por exemplo, é possível selecionar um campo de dados no fluxo de entrada, como ID do cliente, e definir uma expressão de prefixo do S3, como customer_id =!{partitionKey:customer_id}/, que será avaliado em tempo de execução com base nos registros ingeridos para definir para qual prefixo do S3 entrega os registros.

O Firehose é compatível com a conversão parquet/orc alternativa quando você grava seus dados no Amazon S3. O Firehose também se integra com a função do Lambda, para que você possa escrever seu próprio código de transformação. O Firehose também tem suporte integrado para extrair os principais campos de dados de registros que estão no formato JSON. O Firehose também oferece suporte à linguagem de análise JQ, para permitir transformações nessas chaves de partição. Para saber mais, consulte o guia do desenvolvedor do Firehose.

Sim, o Firehose pode fazer backup de todos os registros não transformados para o seu bucket S3 simultaneamente enquanto entrega registros transformados para o destino. O backup do registro de origem pode ser habilitado quando você cria ou atualiza seu fluxo do Firehose.

A frequência da entrega de dados para o Amazon S3 é determinada pelos valores de tamanho e intervalo do buffer do S3 que você configurou para o seu fluxo do Firehose. O Firehose armazena dados de entrada em buffers antes de entregá-los ao Amazon S3. Você pode configurar os valores para o tamanho do buffer (de 1 MB a 128 MB) ou o intervalo do buffer (de 0 a 900 segundos) do S3, e a condição que for atendida primeiro acionará a entrega de dados para o Amazon S3. Se você tiver parquet ou particionamento dinâmico do Apache habilitado, o tamanho do buffer está em MBs e varia de 64 MB a 128 MB para o destino Amazon S3, com 128 MB sendo o valor padrão. Observe que em circunstâncias em que a entrega de dados ao destino não consegue acompanhar a ingestão de dados do fluxo do Firehose, o Firehose aumenta dinamicamente o tamanho do buffer para recuperar o atraso e garantir que todos esses dados sejam entregues ao destino.

O tamanho do buffer é aplicado antes da compactação. Como resultado, se você escolher compactar seus dados, o tamanho dos objetos no seu bucket do Amazon S3 poderá ser menor do que o tamanho do buffer especificado.

O usuário do Redshift deve ter o privilégio INSERT do Redshift para copiar dados do bucket do Amazon S3 para a instância do Redshift.

Se sua instância do Redshift estiver em uma VPC, será necessário conceder ao Amazon Data Firehose acesso à instância do Redshift ao desbloquear os endereços IP do Firehose da VPC. Para informações sobre como desbloquear IPs para a sua VPC, consulte Conceder acesso ao Firehose para um destino do Amazon Redshift no guia do desenvolvedor do Amazon Data Firehose.

Para destinos do Redshift, primeiro o Amazon Data Firehose entrega os dados ao bucket do Amazon S3 e, em seguida, emite o comando COPY do Redshift para carregar dados do bucket do S3 para a instância do Redshift.

No momento, um único fluxo do Firehose apenas pode entregar dados para uma tabela do Snowflake. Para fornecer dados para várias tabelas do Snowflake, você precisa criar vários fluxos do Firehose.

O Firehose usa a semântica de entrega exatamente uma vez para o Snowflake. Isso significa que cada registro é entregue ao Snowflake exatamente uma vez, mesmo que haja erros ou novas tentativas. No entanto, uma entrega exata não garante que não haverá duplicatas nos dados de ponta a ponta, pois os dados podem ser duplicados pelo produtor ou por outras partes do pipeline de ETL.

Esperamos que a maioria dos fluxos de dados seja entregue em 5 segundos.

O Amazon OpenSearch Service facilita a execução de análises de log interativas, o monitoramento de aplicações em tempo real, as pesquisas em sites e muito mais. O OpenSearch é um conjunto de pesquisa e análise de código aberto distribuído derivado do Elasticsearch. O Amazon OpenSearch Service oferece as versões mais recentes do OpenSearch, suporte para 19 versões do Elasticsearch (versões de 1.5 a 7.10) e recursos de visualização fornecidos pelo OpenSearch Dashboards e Kibana (versões de 1.5 a 7.10). Clique aqui para obter mais informações sobre o Amazon OpenSearch.

O Firehose pode alternar seu índice do Amazon OpenSearch Service com base em uma duração. Você pode configurar essa duração enquanto cria seu fluxo do Firehose. Para mais informações, consulte Alternância de índice para o destino do Amazon OpenSearch no guia do desenvolvedor do Amazon Data Firehose.

Ao carregar dados no Amazon OpenSearch Service, o Firehose pode fazer o backup de todos os dados ou somente dos dados que não foram entregues. Para utilizar esse recurso e evitar qualquer perda de dados, é necessário disponibilizar um bucket do Amazon S3 para backup.

Você pode alterar a configuração do seu fluxo do Firehose a qualquer momento após a sua criação. Você pode fazer isso usando o console do Firehose ou a operação UpdateDestination. O fluxo do Firehose permanece no estado ACTIVE enquanto as configurações são atualizadas, e você pode continuar a enviar dados para o fluxo do Firehose. Normalmente, as configurações atualizadas entram em vigor em alguns minutos.

Ao fazer a entrega para um destino de VPC, você pode alterar o URL do endpoint de destino, desde que o novo destino fique acessível dentro da mesma VPC, sub-redes e grupos de segurança. Para alterações de VPC, sub-redes e grupos de segurança, você precisa recriar o fluxo do Firehose.

O Firehose só pode fazer uma entrega em uma conta diferente no Amazon OpenSearch Service quando o Firehose e o Amazon OpenSearch Service estão conectados por um endpoint público.

Se o Firehose e o Amazon OpenSearch Service estiverem conectados por uma VPC privada. o fluxo do Firehose e a VPC do domínio do Amazon OpenSearch Service de destino precisam estar na mesma conta.

Não, seu fluxo do Firehose e o domínio do Amazon OpenSearch Service de destino precisam estar na mesma região.

A frequência da entrega de dados para o Amazon OpenSearch Service é determinada pelos valores de tamanho e intervalo do buffer do OpenSearch que você configurou para o seu fluxo do Firehose. O Firehose armazena em buffer dados de entrada antes de entregá-los ao Amazon OpenSearch Service. Você pode configurar os valores para o tamanho do buffer (de 1 MB a 100 MB) ou o intervalo do buffer (de 0 a 900 segundos) do OpenSearch, e a condição que for atendida primeiro acionará a entrega de dados para o Amazon OpenSearch Service. Observe que em circunstâncias em que a entrega de dados ao destino não consegue acompanhar a ingestão de dados do fluxo do Firehose, o Amazon Data Firehose aumenta dinamicamente o tamanho do buffer para recuperar o atraso e garantir que todos esses dados sejam entregues ao destino.

Para destinos do Redshift, o Amazon Data Firehose gera arquivos de manifesto para carregar objetos do Amazon S3 em instâncias do Redshift em lotes. A pasta de manifestos armazena os arquivos de manifesto gerados pelo Firehose.

Se o modo “todos os documentos” for usado, o Amazon Data Firehose encadeará vários registros de entrada com base na configuração de armazenamento em buffer do seu fluxo do Firehose e, então, os entregará ao bucket do S3 como um objeto do S3. Independentemente de qual modo de backup esteja configurado, os documentos com falha serão entregues ao bucket do S3 usando um determinado formato JSON, que disponibiliza informações adicionais, como código de erro e horário da tentativa de entrega. Para mais informações, consulte Backup do Amazon S3 para o destino do Amazon OpenSearch no guia do desenvolvedor do Amazon Data Firehose.

No momento, um único fluxo do Firehose pode entregar dados somente para um bucket do Amazon S3. Se você desejar que os dados sejam entregues para vários buckets do S3, é possível criar vários fluxos do Firehose.

No momento, um único fluxo do Firehose pode entregar dados somente para uma instância e uma tabela do Redshift. Se você desejar que os dados sejam entregues para várias instâncias ou tabelas do Redshift, é possível criar vários fluxos do Firehose.

No momento, um único fluxo do Firehose só pode entregar dados para um domínio e um índice do Amazon OpenSearch Service. Se você desejar que dados sejam entregues para vários domínios ou índices do Amazon OpenSearch, poderá criar vários fluxos do Firehose.

Quando você habilita o Firehose a entregar dados a um destino do Amazon OpenSearch Service em uma VPC, o Amazon Data Firehose cria uma ou mais interfaces de rede elástica (ENI) entre contas em sua VPC para cada sub-rede que você escolher. O Amazon Data Firehose usa essas ENIs para entregar os dados em sua VPC. O número de ENIs é dimensionado automaticamente para atender aos requisitos do serviço.

Sim, um fluxo do Firehose pode entregar dados para várias tabelas do Apache Iceberg.

Sim, o Firehose oferece suporte à conexão com o catálogo de dados do AWS Glue em uma conta diferente ou em uma região diferente da AWS.

Sim, você pode usar a transformação de dados usando o Lambda ao entregar em tabelas do Apache Iceberg. 

Como padrão, cada fluxo do Firehose pode consumir até 2.000 transações/segundo, 5.000 registros/segundo e 5 MB/segundo. Você pode aumentar esse limite facilmente enviando um formulário de aumento de limite de serviço.

O Amazon Data Firehose usa pelo menos uma vez semântica para a entrega de dados. Em alguns casos raros, como timeout de uma solicitação em uma tentativa de entrega de dados, uma nova tentativa de entrega pelo Firehose pode resultar em duplicidades se a solicitação anterior acabar sendo processada.

Se sua fonte de dados for Direct PUT e a entrega de dados para seu bucket do Amazon S3 falhar, o Amazon Data Firehose fará novas tentativas de entregar os dados a cada cinco segundos durante um período máximo de 24 horas. Se o problema persistir além do período de retenção máximo de 24 horas, o Amazon Data Firehose descartará os dados.

Se a fonte de dados for o Kinesis Data Streams e a entrega de dados para o bucket do Amazon S3 falhar, o Amazon Data Firehose tentará novamente entregar dados a cada cinco segundos durante um período máximo que está configurado no Kinesis Data Streams.

Se a entrega de dados para a instância do Redshift falhar, o Amazon Data Firehose tentará novamente entregar dados a cada cinco minutos durante um período máximo de 120 minutos. Após 120 minutos, o Amazon Data Firehose ignora o lote atual de objetos do S3 que estão prontos para COPY e avança para o próximo lote. A informação sobre os objetos ignorados é passada para o seu bucket do S3 como um arquivo manifesto na pasta de erros, que você pode usar para preencher manualmente. Para informações sobre como usar o comando COPY nos dados manualmente com os arquivos manifesto, consulte Como usar um manifesto para especificar arquivos de dados.

Para o destino do Amazon OpenSearch Service, é possível especificar uma duração para novas tentativas entre 0 e 7200 segundos durante a criação do fluxo do Firehose. Se a entrega de dados para o seu domínio do Amazon OpenSearch falhar, o Amazon Data Firehose tenta novamente a entrega de dados durante o período especificado. Após o período de novas tentativas, o Amazon Data Firehose ignora o lote atual de dados e segue adiante para o novo lote. Detalhes sobre os documentos ignorados são entregues ao seu bucket do S3 na pasta opensearch_failed, que você pode usar para preenchimento manual.

Há dois tipos de cenários de falha quando o Firehose tenta invocar a função do Lambda para a transformação de dados:

• O primeiro tipo é quando a invocação da função falha por razões, como atingir o tempo limite da rede e atingir os limites de invocação do Lambda. Nesses cenários de falha, o Firehose repete a invocação três vezes por padrão e, em seguida, ignora esse lote específico de registros. Os registros ignorados são tratados como registros com falha no processamento. Você pode configurar o número de repetições de invocação entre 0 e 300 usando as APIs CreateDeliveryStream e UpdateDeliveryStream. Para esse tipo de falha, você também pode usar o atributo de registro em log de erros do Firehose para emitir erros de invocação para o CloudWatch Logs. Para obter mais informações, consulte Monitoramento com o Amazon CloudWatch Logs.
   
• O segundo tipo de cenário de falha ocorre quando o resultado de transformação de um registro é definido como “ProcessingFailed” quando retorna de sua função do Lambda. O Firehose trata esses registros como registros com falha no processamento. Para esse tipo de falha, você também pode usar o recurso de registro em log do Lambda para emitir logs de erro para o CloudWatch Logs. Para mais informações, consulte Como acessar o Amazon CloudWatch Logs for AWS Lambda.

Para ambos os tipos de cenários de falha, os registros com falha no processamento são entregues ao seu bucket S3 na pasta processing_failed.

O tamanho dos objetos do S3 entregues devem refletir o tamanho do buffer especificado na maior parte das vezes se a condição de tamanho de buffer for satisfeita antes da condição de intervalo do buffer. No entanto, quando a entrega de dados ao destino não consegue acompanhar a gravação de dados no fluxo do Firehose, o Firehose aumenta dinamicamente o tamanho do buffer para recuperar o atraso e garantir que todos esses dados sejam entregues ao destino. Nessas circunstâncias, o tamanho dos objetos do S3 entregues pode ser maior que o tamanho do buffer especificado.

A pasta de erros armazena arquivos de manifesto que contêm informações de objetos do S3 que falharam ao serem carregados em sua instância do Redshift. É possível recarregar esses objetos manualmente por meio do comando COPY do Redshift. Para informações sobre como usar o comando COPY nos dados manualmente com os arquivos manifesto, consulte Como usar um manifesto para especificar arquivos de dados.

A pasta opensearch_failed armazena os documentos que apresentaram falha ao serem carregados no seu Amazon OpenSearch. O que acontece se a entrega de dados ao meu domínio do Amazon OpenSearch apresentar falha?domínio. Você pode reindexar esses documentos manualmente para preenchimento.

A pasta processing_failed armazena os registros que tiveram falha na transformação em sua função do AWS Lambda. Você pode reprocessar esses registros manualmente.

O console do Firehose exibe métricas de performance essenciais, como os volumes de dados recebidos e entregues. O Amazon Data Firehose também é integrado às métricas do Amazon CloudWatch, o que permite coletar, visualizar e analisar métricas para fluxos do Firehose. Para mais informações sobre as métricas do Amazon Data Firehose, consulte Como monitorar usando as métricas do Amazon CloudWatch no guia do desenvolvedor do Amazon Data Firehose.

O Amazon Data Firehose é integrado ao Amazon CloudWatch Logs para que você possa visualizar logs de erro específicos em caso de falha na transformação ou na entrega. Você pode habilitar o registro de erros durante a criação de fluxos do Firehose. Para obter mais informações, consulte Como monitorar usando o Amazon CloudWatch Logs no guia do desenvolvedor do Amazon Data Firehose.

O Amazon Data Firehose se integra ao AWS Identity and Access Management, um serviço que permite controlar de forma segura o acesso de seus usuários aos serviços e recursos da AWS. Por exemplo, você pode criar uma política que permite que apenas um usuário ou grupo específico adicione dados a um fluxo do Firehose. Para mais informações sobre o gerenciamento e o controle de acesso à sua transmissão, consulte Como controlar o acesso com o Amazon Data Firehose.

O Amazon Data Firehose é integrado ao AWS CloudTrail, um serviço que registra as chamadas de APIs da AWS para sua conta e disponibiliza os arquivos de log. Para obter mais informações sobre o registro de chamadas de APIs e uma lista das operações compatíveis das APIs do Amazon Data Firehose, consulte Como registrar chamadas de API do Amazon Data Firehose usando o AWS CloudTrail.

Não. No momento, Firehose não está disponível no nível gratuito da AWS. O nível gratuito da AWS é um programa que oferece testes gratuito para um grupo de Serviços da AWS. Para mais detalhes, consulte Nível gratuito da AWS.

O Firehose usa preços simples, no modelo de pagamento conforme o uso. Não há custos iniciais nem taxas mínimas, e você paga apenas pelos recursos que usa. A definição de preço do Amazon Data Firehose baseia-se no volume de dados (GB) consumido pelo Firehose, com cada registro arredondado para cima para os 5 KB mais próximos para o Direct PUT e o Kinesis Data Streams como fontes. Para Vended Logs como fonte, o preço é baseado no volume de dados (GB) ingerido pelo Firehose. Para mais informações sobre os custos do Amazon Data Firehose, consulte Preços do Amazon Data Firehose.

O arredondamento de 5 KB é calculado no nível do registro e não no nível da operação de API. Por exemplo, se a sua chamada PutRecordBatch contiver dois registros de 1 KB, o volume de dados dessa chamada será medido como 10 KB. (5 KB por registro).

Não, você será cobrado separadamente pelas taxas associadas ao uso dos serviços Amazon S3, Amazon Redshift, Amazon OpenSearch Service e AWS Lambda, inclusive pelos custos de armazenamento e de solicitações. Para mais informações, consulte Preços do Amazon S3, Preços do Amazon Redshift, Preços do Amazon OpenSearch Service e Preços do AWS Lambda.

O SLA do Amazon Data Firehose garante uma porcentagem de tempo de disponibilidade de pelo menos 99,9% para o Amazon Data Firehose.

Você estará qualificado para um crédito de SLA para o Amazon Data Firehose nos termos do SLA do Amazon Data Firehose se mais de uma zona de disponibilidade na qual você executar uma tarefa, na mesma região, tiver uma porcentagem de tempo de disponibilidade inferior a 99,9% durante qualquer ciclo de faturamento mensal.

Para detalhes completos sobre todos os termos e condições do SLA, bem como detalhes sobre como enviar uma alegação, consulte a página de detalhes do SLA do Amazon Data Firehose.