Solução de problemas do Amazon OpenSearch Service

Esta seção descreve como identificar e resolver problemas comuns do Amazon OpenSearch Service. Consulte as informações nesta seção antes de entrar em contato com o AWS Support.

Não é possível acessar o OpenSearch Dashboards

O endpoint do OpenSearch Dashboards não oferece suporte a solicitações assinadas. Se a política de controle de acesso do seu domínio apenas concede acesso a determinados perfis do IAM e, se você não tiver configurado a autenticação do Amazon Cognito, poderá receber a seguinte mensagem de erro ao tentar acessar o Dashboards:

"User: anonymous is not authorized to perform: es:ESHttpGet"

Se o domínio do OpenSearch Service usar o acesso da VPC, talvez você não receba esse erro, mas o tempo limite da solicitação poderá ser excedido. Para saber mais sobre como corrigir esse problema e as várias opções de configuração disponíveis, consulte Controle do acesso aos OpenSearch painéis, Sobre políticas de acesso em domínios da VPC e Identity and Access Management no Amazon OpenSearch Service.

Não é possível acessar o domínio da VPC

Consulte Sobre políticas de acesso em domínios da VPC e Teste dos domínios da VPC.

Cluster no estado somente leitura

Em comparação com versões anteriores do Elasticsearch, o OpenSearch e o Elasticsearch 7.xusam um sistema diferente para coordenação de clusters. Nesse novo sistema, quando o cluster perde quorum, o cluster fica indisponível até que você execute uma ação. A perda de quorum pode assumir duas formas:

• Se o cluster usar nós principais dedicados, a perda de quorum ocorrerá quando a metade ou mais estiverem indisponíveis.

• Se o cluster não usar nós principais dedicados, a perda de quorum ocorrerá quando a metade ou mais dos seus nós de dados estiverem indisponíveis.

Se ocorrer perda de quorum e seu cluster tiver mais de um nó, o OpenSearch Service restaurará o quorum e colocará o cluster em um estado somente leitura. Você tem duas opções:

• Remover o estado somente leitura e usar o cluster no estado em que se encontra.

• Restaure o cluster ou os índices individuais de um snapshot.

Se você preferir usar o cluster no estado em que se encontra, verifique se a integridade do cluster está verde usando a seguinte solicitação:

GET _cat/health?v

Se a integridade do cluster for vermelha, recomendamos restaurar o cluster a partir de um snapshot. Você também poderá consultar Status de cluster vermelho para ver as etapas de solução de problemas. Se a integridade do cluster estiver verde, verifique se todos os índices esperados estão presentes usando a seguinte solicitação:

GET _cat/indices?v

Execute algumas pesquisas para verificar se os dados esperados estão presentes. Se estiverem, você poderá remover o estado somente leitura usando a seguinte solicitação:

PUT _cluster/settings
{
  "persistent": {
    "cluster.blocks.read_only": false
  }
}

Se houver perda de quorum e seu cluster tiver apenas um nó, o OpenSearch Service substituirá o nó e não colocará o cluster em um estado somente leitura. Caso contrário, suas opções serão as mesmas: usar o cluster no estado em que se encontra ou restaurar a partir de um snapshot.

Em ambas as situações, o OpenSearch Service envia dois eventos para seu AWS Health Dashboard. O primeiro informa sobre a perda de quorum. O segundo ocorre depois que o OpenSearch Service restaura o quorum com êxito. Para obter mais informações sobre como usar o AWS Health Dashboard, consulte o Manual do usuário do AWS Health.

Status de cluster vermelho

Um status de cluster vermelho significa que pelo menos um fragmento principal e suas réplicas não estão alocados a um nó. O OpenSearch Service continua tentando obter snapshots automatizados de todos os índices, independentemente do seu status, mas os snapshots falharão enquanto o status de cluster vermelho persistir.

As causas mais comuns do status vermelho para o cluster são nós de cluster que apresentam falha e o travamento do processamento do OpenSearch devido a uma carga contínua de processos pesados.

nota

O OpenSearch Service armazena snapshots automatizados por 14 dias, independentemente do status do cluster. Portanto, se o status de cluster vermelho persistir por mais de duas semanas, o último snapshot automatizado saudável será excluído e você poderá perder permanentemente os dados do seu cluster. Se o seu domínio do OpenSearch Service entrar em um status de cluster vermelho, o AWS Support poderá entrar em contato com você para perguntar se deseja resolver o problema por conta própria ou se deseja que a equipe de suporte ajude. Você também pode definir um alarme do CloudWatch para notificá-lo quando um status de cluster vermelho ocorrer.

Em última análise, fragmentos vermelhos resultam em clusters vermelhos e índices vermelhos, em fragmentos vermelhos. Para identificar os índices que estão gerando o status de cluster vermelho, o OpenSearch tem algumas APIs úteis.

• GET /_cluster/allocation/explain escolhe o primeiro fragmento sem atribuição que ele encontrar e explica por que ele não pode ser alocado para um nó:

  {
      "index": "test4",
      "shard": 0,
      "primary": true,
      "current_state": "unassigned",
      "can_allocate": "no",
      "allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes"
  }

• GET /_cat/indices?v mostra o status de integridade, o número de documentos e o uso do disco para cada índice:

  health status index            uuid                   pri rep docs.count docs.deleted store.size pri.store.size
  green  open   test1            30h1EiMvS5uAFr2t5CEVoQ   5   0        820            0       14mb           14mb
  green  open   test2            sdIxs_WDT56afFGu5KPbFQ   1   0          0            0       233b           233b
  green  open   test3            GGRZp_TBRZuSaZpAGk2pmw   1   1          2            0     14.7kb          7.3kb
  red    open   test4            BJxfAErbTtu5HBjIXJV_7A   1   0
  green  open   test5            _8C6MIXOSxCqVYicH3jsEA   1   0          7            0     24.3kb         24.3kb

A exclusão de índices vermelhos é a maneira mais rápida de corrigir um status de cluster vermelho. Dependendo do motivo para o status de cluster vermelho, você pode escalar o domínio do OpenSearch Service para usar tipos de instância maiores, um maior número de instâncias ou mais armazenamento do EBS e tentar recriar os índices problemáticos.

Se a exclusão de um índice problemático não for viável, você pode restaurar um snapshot, excluir documentos do índice, alterar as configurações de índice, reduzir o número de réplicas ou excluir outros índices para liberar espaço em disco. A etapa importante é resolver o status de cluster vermelho antes de reconfigurar o domínio do OpenSearch Service. A reconfiguração de um domínio com um status de cluster vermelho pode agravar o problema e fazer com que o domínio fique preso em um estado de configuração Em processamento até que você resolva o status.

Correção automática de clusters vermelhos

Se o status do cluster ficar continuamente vermelho por mais de uma hora, o OpenSearch Service tentará corrigi-lo automaticamente redirecionando fragmentos não alocados ou restaurando instantâneos anteriores.

Se ele não corrigir um ou mais índices vermelhos e o status do cluster permanecer vermelho por um total de 14 dias, o OpenSearch Service tomará medidas adicionais somente se o cluster atender a pelo menos um dos seguintes critérios:

• Tem apenas uma zona de disponibilidade

• Nós principais dedicados

• Contém tipos de instância intermitentes (T2 ou T3)

Neste momento, se seu cluster atender a um desses critérios, o OpenSearch Service enviará notificações diárias nos próximos 7 dias explicando que, se você não corrigir esses índices, todos os fragmentos não atribuídos serão excluídos. Se o status do cluster ainda estiver vermelho após 21 dias, o OpenSearch Service excluirá os fragmentos não atribuídos (armazenamento e computação) em todos os índices vermelhos. Você pode visualizar notificações no painel Notificações do console do OpenSearch Service. Para obter mais informações, consulte Eventos de integridade do cluster.

Recuperação de uma carga contínua de processamento pesado

Para determinar se um status de cluster vermelho deve-se a uma carga contínua de processamento pesado em um nó de dados, monitore as métricas de cluster a seguir.

Métrica relevante	Descrição	Recuperação
JVMMemoryPressure	Especifica a porcentagem do heap do Java usada para todos os nós de dados em um cluster. Visualize a estatística Máximo para essa métrica e procure quedas ainda menores na pressão de memória enquanto o coletor de lixo Java falhar na recuperação de memória suficiente. Esse padrão provavelmente se deve a consultas complexas ou a campos de dados grandes. Os tipos de instância x86 usam o coletor de lixo Concurrent Mark Sweep (CMS), que é executado junto com os threads da aplicação para manter as pausas curtas. Se o CMS não conseguir recuperar memória suficiente durante suas coletas normais, ele acionará uma coleta de resíduos completa, o que pode levar a longas pausas na aplicação e afetar a estabilidade do cluster. Os tipos de instância Graviton baseados em ARM usam o coletor de lixo Garbage-First (G1), que é semelhante ao CMS, mas usa pausas curtas adicionais e desfragmentação de pilha para reduzir ainda mais a necessidade de coleções de lixo completas. Em ambos os casos, se o uso da memória continuar a crescer além do que o coletor de lixo pode recuperar durante as coleções de lixo completas, o OpenSearch falha com um erro de memória insuficiente. Em todos os tipos de instância, uma boa regra prática é manter o uso abaixo de 80%. A API _nodes/stats/jvm oferece um resumo útil das estatísticas do JVM, do uso do grupo de memórias e das informações sobre coleta de lixo: GET domain-endpoint/_nodes/stats/jvm?pretty	Defina disjuntores de memória para JVM. Para obter mais informações, consulte OutOfMemoryError em JVM. Se o problema persistir, exclua índices desnecessários, reduza o número ou a complexidade das solicitações para o domínio, adicione instâncias ou use tipos de instância maiores.
CPUUtilization	Especifica a porcentagem de recursos da CPU usados para nós de dados em um cluster. Visualize a estatística Maximum para essa métrica e procure um padrão contínuo de uso intenso.	Adicione nós de dados ou aumente o tamanho dos tipos de instância dos nós de dados existentes.
Nós	Especifica o número de nós em um cluster. Visualize a estatística Mínimo para essa métrica. Esse valor oscila quando o serviço implanta uma nova frota de instâncias para um cluster.	Adicione nós de dados.

Status de cluster amarelo

O status de cluster amarelo significa que os fragmentos principais de todos os índices estão alocados a nós em um cluster, mas os fragmentos de réplica de pelo menos um índice não. Os clusters de nó único sempre inicializam com um status de cluster amarelo porque não existe nenhum outro nó ao qual o OpenSearch Service possa atribuir uma réplica. Para obter o status de cluster verde, aumente a contagem de nós. Para obter mais informações, consulte Dimensionamento de domínios do Amazon OpenSearch Service.

Clusters de vários nós podem ter brevemente um status de cluster amarelo após a criação de um novo índice ou após uma falha de nó. Esse status se resolve automaticamente à medida que o OpenSearch replica dados em todo o cluster. A falta de espaço em disco também pode causar status de cluster amarelo; o cluster só poderá distribuir fragmentos de réplica se os nós tiverem espaço em disco para acomodá-los.

ClusterBlockException

Você pode receber um erro ClusterBlockException pelos motivos a seguir.

Falta de espaço de armazenamento disponível

Se um ou mais nós em seu cluster tiverem espaço de armazenamento inferior ao valor mínimo de 1) 20% do espaço de armazenamento disponível, ou 2) 20 GB de espaço de armazenamento, as operações básicas de gravação, como a adição de documentos e a criação de índices, poderão começar a falhar. O Cálculo de requisitos de armazenamento fornece um resumo de como o OpenSearch Service usa o espaço em disco.

Para evitar problemas, monitore a métrica FreeStorageSpace no console do OpenSearch Service e crie alarmes do CloudWatch para serem acionados quando o FreeStorageSpace se tornar inferior a um determinado limite. O GET /_cat/allocation?v também fornece um resumo útil de alocação de fragmentos e do uso do disco. Para resolver problemas associados à falta de espaço de armazenamento, dimensione o domínio do OpenSearch Service para usar tipos de instância maiores, um número maior de instâncias ou mais armazenamento baseado no EBS.

Alta pressão da memória da JVM

Quando a métrica JVMMemoryPressure excede 92% por 30 minutos, o OpenSearch Service aciona um mecanismo de proteção e bloqueia todas as operações de gravação para impedir que o cluster entre no status vermelho. Quando a proteção é ativada, as operações de gravação falham devido ao erro ClusterBlockException, novos índices não podem ser criados e o erro IndexCreateBlockException é lançado.

Quando a métrica JVMMemoryPressure retorna para 88% ou menos durante cinco minutos, a proteção é desativada e as operações de gravação no cluster são desbloqueadas.

A alta pressão da memória da JVM pode ser causada por picos no número de solicitações ao cluster, alocações de fragmentos não equilibradas entre os nós, excesso de fragmentos em um cluster, explosões de mapeamento de índices ou dados de campo ou tipos de instâncias que não conseguem administrar as cargas recebidas. Também pode ser causada pelo uso de agregações, curingas ou amplos intervalos de tempo nas consultas.

Para reduzir o tráfego para o cluster e resolver problemas de alta pressão da memória da JVM, experimente uma ou mais destas opções:

• Escale o domínio para que o tamanho máximo da pilha por nó seja de 32 GB.

• Reduza o número de fragmentos excluindo índices antigos ou não utilizados.

• Limpe o cache de dados com a operação da API POST index-name/_cache/clear?fielddata=true. Limpar o cache poderá interromper as consultas em andamento.

Em geral, para evitar a alta pressão da memória da JVM futuramente, siga estas práticas recomendadas:

• Evite agregações em campos de texto ou altere o tipo de mapeamento de seus índices para keyword.

• Otimize as solicitações de pesquisa e indexação escolhendo o número correto de fragmentos.

• Configure as políticas do Index State Management (ISM) para remover regularmente os índices não utilizados.

Erro ao migrar para multi-AZ com modo de espera

Os seguintes problemas podem ocorrer quando você migra um domínio existente para o Multi-AZ com modo de espera.

Criação de um índice, modelo de índice ou política do ISM durante a migração de domínios sem espera para domínios com modo de espera

Se você criar um índice ao migrar um domínio do Multi-AZ sem modo de espera para com modo de espera e o modelo de índice ou a política do ISM não seguir as diretrizes recomendadas de cópia de dados, isso pode causar uma inconsistência de dados e a migração pode falhar. Para evitar essa situação, crie o novo índice com uma contagem de cópias de dados (incluindo nós primários e réplicas) que seja múltipla de três. Você pode verificar o progresso da migração usando a API DescribeDomainChangeProgress. Se você encontrar um erro de contagem de réplicas, corrija o erro e entre em contato com o Suporte da AWS para tentar a migração novamente.

Número incorreto de cópias de dados

Se você não tiver o número certo de cópias de dados em seu domínio, a migração para o multi-AZ com modo de espera falhará.

OutOfMemoryError em JVM

Normalmente, OutOfMemoryError em JVM significa que um dos seguintes disjuntores para JVM foi atingido.

Disjuntor	Descrição	Propriedade de configuração de cluster
Disjuntor principal	Porcentagem total de memória do heap de JVM permitida para todos os disjuntores. O valor padrão é 95%.	indices.breaker.total.limit
Disjuntor de dados de campo	Porcentagem de memória do heap de JVM com permissão para carregar um único campo de dados na memória. O valor padrão é 40%. Se você carregar dados com campos grandes, talvez precise aumentar esse limite.	indices.breaker.fielddata.limit
Disjuntor de solicitações	Porcentagem de memória do heap de JVM permitida para estruturas de dados usados para responder a uma solicitação de serviço. O valor padrão é 60%. Se suas solicitações de serviço envolverem o cálculo de agregações, recomenda-se aumentar esse limite.	indices.breaker.request.limit

Nós de cluster com falha

As instâncias do Amazon EC2 podem experimentar encerramentos e reinicializações inesperados. Normalmente, o OpenSearch Service reinicia os nós para você. No entanto, é possível que um ou mais nós em um cluster do OpenSearch permaneçam em uma condição de falha.

Para verificar essa condição, abra o painel do domínio no console do OpenSearch Service. Escolha a guia Integridade do cluster e, em seguida, a métrica Total de nós. Veja se o número de nós relatado é inferior ao número que você configurou para seu cluster. Se a métrica mostrar que um ou mais nós estão inativos por mais de um dia, entre em contato com o AWS Support.

Você também pode definir um alarme do CloudWatch para ser notificado quando esse problema ocorrer.

nota

A métrica Total de nós não é precisa durante as alterações na configuração do cluster e durante a manutenção de rotina do serviço. Esse comportamento é esperado. A métrica logo informará o número correto de nós do cluster. Para saber mais, consulte Fazendo alterações de configuração no Amazon OpenSearch Service.

Para proteger seus clusters contra encerramentos e reinicializações inesperados no nó, crie pelo menos uma réplica para cada índice no domínio do OpenSearch Service.

Limite máximo de fragmentos excedido

O OpenSearch e as versões 7.x do Elasticsearch têm uma configuração padrão de até 1.000 fragmentos por nó. O OpenSearch/ElasticSearch emitirá um erro se uma solicitação, como criar um novo índice, fizer com que você exceda esse limite. Se você encontrar esse erro, terá várias opções:

• Adicionar mais nós de dados ao cluster.

• Aumentar a configuração _cluster/settings/cluster.max_shards_per_node.

• Usar a API _shrink para reduzir o número de fragmentos no nó.

Domínio paralisado no estado de processamento

O seu domínio do OpenSearch Service entra no estado “Processing” (Processamento) ao executar uma alteração de configuração. Quando você iniciar uma alteração de configuração, o status do domínio será alterado para “Processing” (Processamento) enquanto o OpenSearch Service cria um novo ambiente. No novo ambiente, o OpenSearch Service inicia um novo conjunto de nós aplicáveis (como dados, primário ou UltraWarm). Após a conclusão da migração, os nós mais antigos são encerrados.

O cluster pode ficar paralisado no estado “Processing” (Processamento) caso alguma destas situações ocorra:

• Um novo conjunto de nós de dados não possa ser iniciado.

• A migração de fragmentos para o novo conjunto de nós de dados não seja bem-sucedida.

• Ocorreu uma falha na verificação de validação com erros.

Para obter etapas detalhadas de resolução em cada uma dessas situações, consulte Por que o meu domínio do Amazon OpenSearch Service está paralisado no estado “Processing” (Processamento)?.

O saldo de intermitência do EBS está baixo

O OpenSearch Service enviará para você uma notificação de console quando o saldo de intermitência do EBS em um de seus volumes de Finalidade geral (SSD) estiver abaixo de 70% e uma notificação de acompanhamento se o saldo cair abaixo de 20%. Para corrigir esse problema, você pode aumentar a escala verticalmente do cluster ou reduzir as IOPS de leitura e gravação para que o saldo de intermitência possa ser creditado. O saldo intermitente permanece em 0 para domínios com tipos de volume gp3 e domínios com volume gp2 cujo tamanho de volume seja superior a 1000 GiB. Para obter mais informações, consulte Volumes de Finalidade geral (SSD) (gp2). Você pode monitorar o equilíbrio de intermitência do EBS com a métrica do BurstBalance CloudWatch.

Não é possível habilitar logs de auditoria

Você poderá encontrar o seguinte erro ao tentar habilitar a publicação de logs de auditoria usando o console do OpenSearch Service:

A Política de Acesso de Recursos especificada para o grupo de CloudWatch Logs não concede permissões suficientes para o Amazon OpenSearch Service criar um fluxo de registro. Verifique a Política de acesso a recursos.

Se você encontrar esse erro, verifique se o elemento resource da sua política inclui o ARN do grupo de logs correto. Se isso acontecer, faça o seguinte:

1. Espere vários minutos.

2. Atualize a página em seu navegador da Web.

3. Escolha Selecionar grupo existente.

4. Em Grupo de logs existente, escolha o grupo de logs que você criou antes de receber a mensagem de erro.

5. Na seção de política de acesso, escolha Selecionar política existente.

6. Em Política existente, escolha a política que você criou antes de receber a mensagem de erro.

7. Escolha Habilitar.

Se o erro persistir após o processo ser repetido várias vezes, entre em contato com o AWS Support.

Não é possível fechar o índice

O OpenSearch Service oferece suporte à API _close apenas para o OpenSearch e o Elasticsearch versões 7.4 e posteriores. Se você estiver usando uma versão anterior e restaurando um índice de um snapshot, poderá excluir o índice existente (antes ou depois de reindexá-lo).

Verificações de licenças do cliente

As distribuições padrão do Logstash e Beats incluem uma verificação de licença proprietária e não conseguem se conectar à versão de código aberto do OpenSearch. Certifique-se de usar as distribuições Apache 2.0 (OSS) desses clientes com o OpenSearch Service.

Controle de utilização de solicitações

Se você receber erros 403 Request throttled due to too many requests ou 429 Too Many Requests persistentes, considere a escalabilidade vertical. O Amazon OpenSearch Service controla a utilização de solicitações em situações em que a carga útil faz com que o uso da memória exceda o tamanho máximo do heap de Java.

Não é possível executar o SSH no nó

Não é possível usar o SSH para acessar qualquer um dos nós em seu cluster do OpenSearch nem modificar opensearch.yml diretamente. Em vez disso, use o console, a AWS CLI ou SDKs para configurar o domínio. Você também pode especificar algumas configurações no nível do cluster usando as APIs REST do OpenSearch. Para saber mais, consulte Referência da API do Amazon OpenSearch Service e Operações suportadas no Amazon OpenSearch Service.

Se você precisar de mais insights sobre a performance do cluster, poderá publicar logs de erro e logs lentos no CloudWatch.

Erro de snapshot "Not Valid for the Object's Storage Class" (Inválido para a classe de armazenamento do objeto)

Os snapshots do OpenSearch Service não são compatíveis com a classe de armazenamento do S3 Glacier. Você poderá encontrar esse erro ao tentar listar os snapshots se o bucket do S3 incluir uma regra de ciclo de vida que faça a transição de objetos para a classe de armazenamento do S3 Glacier.

Se você precisar restaurar um snapshot armazenado no bucket, restaure os objetos do S3 Glacier, copie-os em um novo bucket e registre o novo bucket como um repositório de snapshots.

Cabeçalho de host inválido

O OpenSearch Service exige que os clientes especifiquem Host nos cabeçalhos de solicitação. Um valor Host válido é o endpoint do domínio sem https://, como:

Host: search-my-sample-domain-ih2lhn2ew2scurji.us-west-2.es.amazonaws.com

Se você receber um erro Invalid Host Header quando fizer uma solicitação, verifique se o seu cliente ou proxy inclui o endpoint do domínio do OpenSearch Service (e não, por exemplo, seu endereço IP) no cabeçalho do Host.

Tipo de instância M3 inválido

O OpenSearch Service não oferece suporte à adição ou modificação de instâncias M3 em domínios existentes que executam o OpenSearch Service ou o Elasticsearch versão 6.7 ou posterior. Você pode continuar a usar instâncias M3 com o Elasticsearch 6.5 e anteriores.

Recomendamos escolher um tipo de instância mais recente. Para domínios que executam o OpenSearch ou Elasticsearch 6.7 ou posterior, a seguinte restrição é aplicável:

• Se o domínio existente não usar instâncias M3, você não poderá mais alterar para elas.

• Se você alterar um domínio existente de um tipo de instância M3 para outro tipo de instância, não será possível alternar novamente.

Consultas de alta atividade param de funcionar após a ativação do UltraWarm

Quando você habilita o UltraWarm em um domínio, se não houver substituições preexistentes para a configuração search.max_buckets, o OpenSearch Service definirá automaticamente o valor como 10000 para evitar que consultas com muita memória saturem nós de alta atividade. Se suas consultas de atividade muito alta usarem mais de 10.000 buckets, elas poderão parar de funcionar quando você habilitar o UltraWarm.

Como você não pode modificar essa configuração devido à natureza gerenciada do Amazon OpenSearch Service, é necessário abrir um caso de suporte para aumentar o limite. Os aumentos de limite não exigem uma assinatura do Premium Support.

Não é possível reverter para a versão anterior após a atualização.

As atualizações no local são irreversíveis, mas se você entrar em contato com o AWS Support, eles poderão ajudar a restaurar o snapshot automático anterior à atualização em um novo domínio. Por exemplo, se você atualizar um domínio do Elasticsearch 5.6 para 6.4, o AWS Support poderá ajudar a restaurar o snapshot anterior à atualização em um novo domínio do Elasticsearch 5.6. Se você tirou um snapshot manual do domínio original, pode realizar essa etapa por conta própria.

Resumo das necessidades de domínios para todas as Regiões da AWS

O script a seguir usa o comando describe-regions da AWS CLI do Amazon EC2 para criar uma lista de todas as regiões nas quais o OpenSearch Service pode estar disponível. Depois, ele chama list-domain-names para cada região:

for region in `aws ec2 describe-regions --output text | cut -f4`
do
    echo "\nListing domains in region '$region':"
    aws opensearch list-domain-names --region $region --query 'DomainNames'
done

Você recebe a seguinte saída para cada região:

Listing domains in region:'us-west-2'...
[
  {
    "DomainName": "sample-domain"
  }
]

As regiões nas quais o OpenSearch Service não está disponível retornam "Could not connect to the endpoint URL" (Não foi possível conectar ao URL do endpoint).

Erro do navegador ao usar o OpenSearch Dashboards

Seu navegador encapsula mensagens de erro do serviço em objetos de resposta HTTP quando você usa o Dashboards para visualizar dados em seu domínio do OpenSearch Service. Você pode usar ferramentas de desenvolvedor normalmente disponíveis em navegadores da web, como Modo de Desenvolvedor no Chrome, para visualizar erros de serviço subjacentes e auxiliar suas operações de depuração.

Para visualizar erros de serviço no Chrome

1. Na barra de menu superior do Chrome, escolha Visualizar, Desenvolvedor , Ferramentas do desenvolvedor.

2. Escolha a guia Network.

3. Na coluna Status, escolha qualquer sessão HTTP com status 500.

Para visualizar erros de serviço no Firefox

1. No menu, escolha Tools, Web Developer, Network.

2. Escolha qualquer sessão HTTP com status 500.

3. Escolha a guia Response para visualizar a resposta do serviço.

Distorção de armazenamento e de fragmentos do nó

A distorção de fragmentos de nós ocorre quando um ou mais nós em um cluster têm significativamente mais fragmentos do que os outros nós. A distorção de armazenamento de nós ocorre quando um ou mais nós em um cluster têm significativamente mais armazenamento (disk.indices) do que os outros nós. Embora essas duas condições possam ocorrer temporariamente, como quando um domínio substituiu um nó e ainda está alocando fragmentos a ele, você deve resolvê-las se elas persistirem.

Para identificar os dois tipos de distorção, execute a operação _cat/allocation da API e compare as entradas shards e disk.indices na resposta:

 shards    | disk.indices  | disk.used  | disk.avail   | disk.total   | disk.percent |  host     | ip       | node
    264    |      465.3mb  |   229.9mb  |      1.4tb   |      1.5tb   |            0 |  x.x.x.x  | x.x.x.x  | node1
    115    |        7.9mb  |    83.7mb  |     49.1gb   |     49.2gb   |            0 |  x.x.x.x  | x.x.x.x  | node2
    264    |      465.3mb  |   235.3mb  |      1.4tb   |      1.5tb   |            0 |  x.x.x.x  | x.x.x.x  | node3
    116    |        7.9mb  |    82.8mb  |     49.1gb   |     49.2gb   |            0 |  x.x.x.x  | x.x.x.x  | node4
    115    |        8.4mb  |      85mb  |     49.1gb   |     49.2gb   |            0 |  x.x.x.x  | x.x.x.x  | node5

Embora alguma distorção de armazenamento seja normal, qualquer coisa 10% acima da média é significativa. Quando a distribuição de fragmentos é distorcida, o uso da CPU, da rede e da largura de banda do disco também pode ficar distorcido. Como mais dados geralmente significam mais operações de indexação e pesquisa, os nós mais pesados também tendem a ser os nós com mais recursos, enquanto os nós mais leves representam capacidade subutilizada.

Correção: use contagens de fragmentos que sejam múltiplos da contagem de nós de dados para garantir que cada índice seja distribuído uniformemente entre os nós de dados.

Distorção de armazenamento e de fragmentos de índices

A distorção de fragmentos de índices ocorre quando um ou mais nós retêm mais fragmentos de um índice do que os outros nós. A distorção de armazenamento de índices ocorre quando um ou mais nós retêm uma quantidade desproporcionalmente grande do armazenamento total de um índice.

A distorção de índices é mais difícil de identificar do que a distorção de nós porque requer alguma manipulação da saída da API _cat/shards. Investigue a distorção de índices se houver alguma indicação de distorção nas métricas do cluster ou do nó. Estas são indicações comuns de distorção de índices:

• Erros HTTP 429 que ocorrem em um subconjunto de nós de dados

• Índice desigual ou enfileiramento de operações de pesquisa nos nós de dados

• Heap da JVM e/ou utilização da CPU desigual nos nós de dados

Correção: use contagens de fragmentos que sejam múltiplos da contagem de nós de dados para garantir que cada índice seja distribuído uniformemente entre os nós de dados. Se você ainda vir distorção de armazenamento ou de fragmentos de índices, talvez seja necessário realizar uma realocação de fragmentos de forma forçada, que ocorre com cada implantação azul/verde do domínio do OpenSearch Service.

Operação não autorizada após a seleção do acesso via VPC

Ao criar um novo domínio usando o console do OpenSearch Service, você tem a opção de escolher acesso via VPC ou público. Se você escolher Acesso via VPC, o OpenSearch Service realizará consultas para obter informações da VPC e falhará se você não tiver as permissões adequadas:

You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperation

Para habilitar esta consulta, você deve ter acesso às operações ec2:DescribeVpcs, ec2:DescribeSubnets e ec2:DescribeSecurityGroups. Esse requisito se aplica somente ao console. Se você usar a AWS CLI para criar e configurar um domínio com um endpoint da VPC, não precisará de acesso a essas operações.

Preso no carregamento após a criação do domínio da VPC

Depois de criar um novo domínio que usa o acesso da VPC, o Estado de configuração do domínio pode ficar travado em Carregando. Se esse problema ocorrer, provavelmente o AWS Security Token Service (AWS STS) está desativado para a sua região.

Para adicionar endpoints da VPC à sua VPC, o OpenSearch Service precisa assumir a função AWSServiceRoleForAmazonOpenSearchService. Assim, o AWS STS deve ser ativado para criar novos domínios que usam acesso da VPC em uma determinada região. Para saber mais sobre a habilitação e a desabilitação do AWS STS, consulte o Manual do usuário do IAM.

Solicitações negadas às APIs do OpenSearch

Com a introdução do controle de acesso baseado em tags para as APIs do OpenSearch, você pode começar a ver erros de acesso negado pela primeira vez. Isso pode ocorrer porque uma ou mais de suas políticas de acesso contém Deny usando a condição ResourceTag, e essas condições agora estão sendo aplicadas.

Por exemplo, a política antigamente só negava acesso à ação CreateDomain da API de configuração quando o domínio tinha a tagenvironment=production. Mesmo que a lista de ações também incluísse ESHttpPut, a declaração de negação não se aplicava a essa ação ou a qualquer outras ações ESHttp*.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Action": [
      "es:CreateDomain",
      "es:ESHttpPut"
    ],
    "Effect": "Deny",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringEquals": {
        "aws:ResourceTag/environment": [
          "production"
        ]
      }
    }
  }]
}

Com o suporte adicional de tags para métodos HTTP do OpenSearch, uma política baseada em identidade do IAM, como a acima, negará o acesso do usuário anexado à ação ESHttpPut. Anteriormente, na ausência de validação de tags, o usuário anexado ainda teria conseguido enviar solicitações PUT.

Se você começar a encontrar erros de acesso negado após atualizar os domínios para o software de serviço R20220323 ou posterior, verifique as políticas de acesso baseadas em identidade para ver se o caso descrito aqui está ocorrendo e atualize-as, se necessário, para permitir o acesso.

Não é possível conectar via Alpine Linux

O Alpine Linux limita o tamanho da resposta DNS a 512 bytes. Se você tentar conectar ao domínio do OpenSearch Service via Alpine Linux, versão 3.18.0 ou inferior, a resolução de DNS pode falhar se o domínio estiver em uma VPC e contiver mais de 20 nós. Se você usa uma versão Alpine Linux superior à 3.18.0, você deve ser capaz de resolver mais de 20 hosts. Para obter mais informações, consulte notas de lançamento do Alpine Linux 3.18.0.

Se seu domínio estiver em uma VPC, recomendamos usar outras distribuições Linux, como Debian, Ubuntu, CentOS, Red Hat Enterprise Linux ou Amazon Linux 2, para conectar a ele.

Muitas solicitações de pesquisa de contrapressão

O controle de admissão baseado em CPU é um mecanismo de controle que limita proativamente o número de solicitações a um nó com base em sua capacidade atual, tanto para aumentos orgânicos quanto para picos de tráfego. Solicitações excessivas retornam um código de status HTTP 429 “Muitas solicitações” após a rejeição. Esses erros indicam recursos de cluster insuficientes, solicitações de pesquisa que consomem muitos recursos ou um aumento não intencional na workload.

A contrapressão de pesquisa fornece o motivo da rejeição, o que pode ajudar a ajustar solicitações de pesquisa que consomem muitos recursos. Para picos de tráfego, recomendamos novas tentativas do lado do cliente com recuo e instabilidade exponenciais.

Erro de certificado ao usar o SDK

Como os AWS SDKs usam os certificados de CA do computador, as alterações feitas nos certificados nos servidores da AWS podem provocar falhas de conexão quando você tenta usar um SDK. As mensagens de erro variam, mas geralmente contêm o seguinte texto:

Failed to query OpenSearch
...
SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Você pode impedir essas falhas mantendo os certificados de CA do computador e o sistema operacional atualizados. Se encontrar esse problema em um ambiente corporativo e não gerenciar seu computador, talvez tenha de pedir a um administrador para auxiliá-lo no processo de atualização.

A lista a seguir mostra as versões mínimas de sistema operacional e Java:

• As versões do Microsoft Windows que têm atualizações de janeiro de 2005 ou superiores instaladas contêm pelo menos uma das CAs necessárias em sua lista de confiança.

• O Mac OS X 10.4 com Java para Mac OS X 10.4 Release 5 (fevereiro de 2007), Mac OS X 10.5 (outubro de 2007) e versões superiores contêm pelo menos uma das CAs necessárias em sua lista de confiança.

• O Red Hat Enterprise Linux 5 (março de 2007), 6 e 7 e o CentOS 5, 6 e 7 contêm pelo menos uma das CAs necessárias em sua lista de CAs confiáveis padrão.

• Java 1.4.2_12 (maio de 2006), 5 Update 2 (março de 2005) e todas as versões mais recentes, como Java 6 (dezembro de 2006), 7 e 8, contêm pelo menos uma das CAs necessárias em sua lista de CAs confiáveis padrão.

As três autoridades de certificação são:

• Amazon Root CA 1

• Starfield Services Root Certificate Authority – G2

• Starfield Class 2 Certification Authority

Os certificados raiz das duas primeiras autoridades estão disponíveis em Amazon Trust Services, mas manter o computador atualizado é a solução mais simples. Para saber mais sobre os certificados fornecidos pelo ACM, consulte Perguntas frequentes sobre o AWS Certificate Manager.

nota

No momento, os domínios do OpenSearch Service na região us-east-1 usam certificados de uma autoridade diferente. Pretendemos atualizar a região para usar essas novas autoridades de certificação em um futuro próximo.