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á.
# Melhores práticas para OpenSearch ingestão na Amazon
Este tópico fornece as melhores práticas para criar e gerenciar pipelines de OpenSearch ingestão da Amazon e inclui 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.
**Topics**
+ [Práticas recomendadas gerais](#osis-best-practices-general)
+ [CloudWatch Alarmes recomendados](#osis-cloudwatch-alarms)
## 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](https://opensearch.org/docs/latest/data-prepper/pipelines/dlq/) (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.
+ Se você estiver usando um processador agregado em um pipeline, recomendamos o uso de `“local_mode: true”` flag para otimizar o desempenho do pipeline.
## CloudWatch Alarmes recomendados
CloudWatch os alarmes realizam uma ação quando uma CloudWatch métrica excede um valor especificado por um determinado período de tempo. Por exemplo, talvez você queira AWS enviar um e-mail se o status de integridade do seu cluster `red` for superior a um minuto. Esta seção inclui alguns alarmes recomendados para o Amazon OpenSearch Ingestion e como responder a eles.
Para obter mais informações sobre a configuração de alarmes, consulte Criação de [ CloudWatchalarmes da Amazon no Guia](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) do usuário da *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 OpenSearch coletor. 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 uma alta latência enviando dados para o OpenSearch coletor. 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
Considere configurar os seguintes alarmes, dependendo dos recursos do Amazon OpenSearch Ingestion que 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 OpenSearch cluster subdimensionado ou por uma capacidade máxima de OCU de pipeline muito baixa para a taxa de transferência da WCU na tabela do DynamoDB. EndtoEndLatencyserá maior após uma exportação, mas deve diminuir com o tempo à medida que alcança os streams 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 OpenSearch coletor. Analise as métricas do plug-in OpenSearch sink 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 and/or 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. |