Práticas recomendadas para Ingestão do Amazon OpenSearch

Este tópico fornece algumas das práticas recomendadas para a criação e gestão de pipelines de Ingestão do Amazon OpenSearch e contém diretrizes gerais que se aplicam a muitos casos de uso. Cada workload é única e tem características particulares, portanto, nenhuma recomendação genérica é exatamente certa para cada caso de uso.

Práticas recomendadas gerais

As práticas recomendadas gerais a seguir se aplicam à criação e gerenciamento de pipelines.

• Para garantir a alta disponibilidade, configure pipelines de VPC com duas ou três sub-redes. Se você implantar apenas um pipeline em uma sub-rede e a Zona de disponibilidade ficar inativa, você não conseguirá ingerir dados.

• Em cada pipeline, recomendamos limitar o número de subpipelines a 5 ou menos.

• Se você estiver usando o plug-in de origem do S3, use arquivos do S3 de tamanho uniforme para obter um desempenho ideal.

• Se estiver usando o plug-in de origem do S3, adicione 30 segundos de tempo limite de visibilidade adicional para cada 0,25 GB de tamanho de arquivo no bucket do S3 para obter um desempenho ideal.

• Inclua uma fila de mensagens não entregues (DLQ – fila de mensagens não entregues) na configuração do pipeline para que você possa descarregar eventos com falha e torná-los acessíveis para análise. Se seus coletores rejeitarem dados devido a mapeamentos incorretos ou outros problemas, você poderá rotear os dados para o DLQ para avaliar e corrigir o problema.

Alarmes do CloudWatch recomendados

Os alarmes do CloudWatch executam uma ação quando uma métrica do CloudWatch excede um valor especificado por algum período. Por exemplo, o AWS pode enviar um e-mail se o status de integridade do cluster permanecer red por mais do que um minuto. Esta seção inclui alguns alarmes recomendados para a Ingestão do Amazon OpenSearch e como responder a eles.

Para obter mais informações sobre configuração de alarmes, consulte Criação de alarmes do Amazon CloudWatch no Manual do usuário do Amazon CloudWatch.

Alarme	Problema
O computeUnits máximo é = o maxUnits configurado para 15 minutos, 3 vezes consecutivas	O pipeline atingiu a capacidade máxima e pode precisar de uma atualização de maxUnits. Aumente a capacidade máxima do seu pipeline
opensearch.documentErrors.count soma é = soma de {sub_pipeline_name}.opensearch.recordsIn.count por 1 minuto, 1 vez consecutiva	O pipeline não consegue gravar no coletor do OpenSearch. Verifique as permissões do pipeline e confirme se o domínio ou a coleção estão íntegros. Você também pode verificar se há eventos com falha na fila de mensagens não entregues (DLQ), se ela estiver configurada.
bulkRequestLatency.max máximo é >= x por 1 minuto, 1 vez consecutiva	O pipeline está passando por alta latência enviando dados para o coletor do OpenSearch. Provavelmente, isso se deve ao fato de a pia estar subdimensionada ou a uma estratégia de fragmentação deficiente, que está fazendo com que o coletor deixe a desejar. A alta latência sustentada pode afetar o desempenho do pipeline e provavelmente causará uma contrapressão nos clientes.
httpAuthFailure.count soma >= 1 por 1 minuto, 1 vez consecutiva	As solicitações de ingestão não estão sendo autenticadas. Confirme se todos os clientes têm a autenticação Signature versão 4 ativada corretamente.
Média de system.cpu.usage.value >= 80% por 15 minutos, 3 vezes consecutivas	A utilização elevada e sustentada da CPU pode ser problemática. Considere aumentar a capacidade máxima do pipeline.
Média de bufferUsage.value >= 80% por 15 minutos, 3 vezes consecutivas	O uso sustentado de alta bufferização pode ser problemático. Considere aumentar a capacidade máxima do pipeline.

Outros alarmes que você pode considerar

Avalie a possibilidade de configurar os seguintes alarmes, dependendo de quais recursos de Ingestão do Amazon OpenSearch você usa regularmente.

Alarme	Problema
dynamodb.exportJobFailure.count soma 1	A tentativa de acionar uma exportação para o Amazon S3 falhou.
Média de opensearch.EndtoEndLatency.avg > X por 15 minutos, 4 vezes consecutivas	EndtoEndLatency é maior do que o desejado para leitura de fluxos do DynamoDB. Isso pode ser causado por um cluster do OpenSearch subdimensionado ou por uma capacidade máxima de OCUs de pipeline muito baixa para a throughput da WCU na tabela do DynamoDB. EndtoEndLatency será maior após uma exportação, mas deve diminuir com o tempo à medida que alcança os fluxos mais recentes do DynamoDB.
dynamodb.changeEventsProcessed.count soma == 0 por X minutos	Nenhum registro está sendo coletado dos fluxos do DynamoDB. Isso pode ser causado por falta de atividade na tabela ou por um problema no acesso aos fluxos do DynamoDB.
soma opensearch.s3.dlqS3RecordsSuccess.count >= soma opensearch.documentSuccess.count por 1 minuto, 1 vez consecutiva	Um número maior de registros está sendo enviado para o DLQ do que para o coletor do OpenSearch. Analise as métricas do plug-in de coletor do OpenSearch para investigar e determinar a causa raiz.
grok.grokProcessingTimeouts.count é = soma de recordsIn.count por 1 minuto, 5 vezes consecutivas	Todos os dados atingem o tempo limite enquanto o processador Grok está tentando combinar padrões. Isso provavelmente está afetando o desempenho e diminuindo a velocidade do seu pipeline. Considere ajustar seus padrões para reduzir os tempos limite.
grok.grokProcessingErrors.count soma é >= 1 por 1 minuto, 1 vez consecutiva	O processador Grok não está conseguindo combinar os padrões com os dados no pipeline, resultando em erros. Revise seus dados e as configurações do plug-in do Grok para garantir que a correspondência de padrões seja a esperada.
grok.grokProcessingMismatch.count é = soma de recordsIn.count por 1 minuto, 5 vezes consecutivas	O processador Grok não consegue combinar padrões com os dados no pipeline. Revise seus dados e as configurações do plug-in do Grok para garantir que a correspondência de padrões seja a esperada.
date.dateProcessingMatchFailure.count soma = soma de recordsIn.count por 1 minuto, 5 vezes consecutivas	O processador de data não consegue combinar nenhum padrão com os dados no pipeline. Revise seus dados e as configurações do plug-in de data para garantir que o padrão seja o esperado.
s3.s3ObjectsFailed.count soma >= 1 por 1 minuto, 1 vez consecutiva	Esse problema está ocorrendo porque o objeto S3 não existe ou porque o pipeline não tem privilégios suficientes. Analise as métricas de s3ObjectsNotFound.count e s3ObjectsAccessDenied.count para determinar a causa raiz. Confirme se o objeto S3 existe e/ou atualize as permissões.
s3.sqsMessagesFailed.count soma >= 1 por 1 minuto, 1 vez consecutiva	O plug-in do S3 falhou ao processar uma mensagem do Amazon SQS. Se você tiver um DLQ habilitado em sua fila do SQS, revise a mensagem de falha. A fila pode estar recebendo dados inválidos que o pipeline está tentando processar.
http.badRequests.count soma >= 1 por 1 minuto, 1 vez consecutiva	O cliente está enviando uma solicitação incorreta. Confirme se todos os clientes estão enviando a carga útil adequada.
http.requestsTooLarge.count soma >= 1 por 1 minuto, 1 vez consecutiva	As solicitações do plug-in HTTP de origem contêm muitos dados, excedendo a capacidade do buffer. Ajuste o tamanho do lote para seus clientes.
http.internalServerError.count soma >=0 por 1 minuto, 1 vez consecutiva	O plug-in HTTP de origem está tendo problemas para receber eventos.
http.requestTimeouts.count soma >=0 por 1 minuto, 1 vez consecutiva	Os tempos limite de origem provavelmente são o resultado do subprovisionamento do pipeline. Considere aumentar o pipeline maxUnits para lidar com o workload (carga de trabalho) adicional.
otel_trace.badRequests.count soma >= 1 por 1 minuto, 1 vez consecutiva	O cliente está enviando uma solicitação incorreta. Confirme se todos os clientes estão enviando a carga útil adequada.
otel_trace.requestsTooLarge.count soma >= 1 por 1 minuto, 1 vez consecutiva	As solicitações do plug-in de origem do OTel Trace contêm muitos dados, excedendo a capacidade do buffer. Ajuste o tamanho do lote para seus clientes.
otel_trace.internalServerError.count soma >=0 por 1 minuto, 1 vez consecutiva	O plug-in de origem do OTel Trace está tendo problemas para receber eventos.
otel_trace.requestTimeouts.count soma >=0 por 1 minuto, 1 vez consecutiva	Os tempos limite de origem provavelmente são o resultado do subprovisionamento do pipeline. Considere aumentar o pipeline maxUnits para lidar com o workload (carga de trabalho) adicional.
otel_metrics.requestTimeouts.count soma >=0 por 1 minuto, 1 vez consecutiva	Os tempos limite de origem provavelmente são o resultado do subprovisionamento do pipeline. Considere aumentar o pipeline maxUnits para lidar com o workload (carga de trabalho) adicional.