Solução de problemas do Amazon OpenSearch Service

Este tópico 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 consigo acessar os OpenSearch painéis

O endpoint do OpenSearch Dashboards não é compatível com 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 seu domínio OpenSearch de serviço usa acesso VPC, você pode não receber esse erro, mas a solicitação pode expirar. 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 as versões anteriores do Elasticsearch OpenSearch e do Elasticsearch 7. x use 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 para 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 ocorrer 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 para 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 Serviço envia dois eventos para o seu AWS Health Dashboard. O primeiro informa sobre a perda de quorum. A segunda ocorre depois que o OpenSearch Serviço restaura com sucesso o quórum. Para obter mais informações sobre como usar o AWS Health Dashboard, consulte o Guia AWS Health do usuário.

Status de cluster vermelho

Um status de cluster vermelho significa que pelo menos um fragmento primário e suas réplicas não estão alocados em um nó. OpenSearch O serviço continua tentando tirar instantâneos automatizados de todos os índices, independentemente de seu status, mas os instantâneos falham enquanto o status vermelho do cluster persiste.

As causas mais comuns do status de um cluster vermelho são falhas nos nós do cluster e a falha do OpenSearch processo devido a uma carga de processamento contínua e pesada.

nota

OpenSearch O serviço armazena instantâneos 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 de OpenSearch serviço entrar em um status de cluster vermelho, AWS Support poderá entrar em contato com você para perguntar se você deseja resolver o problema sozinho ou se deseja que a equipe de suporte ajude. Você pode definir um CloudWatch alarme para notificá-lo quando ocorrer um status de cluster vermelho.

Em última análise, fragmentos vermelhos resultam em clusters vermelhos e índices vermelhos, em fragmentos vermelhos. Para identificar os índices que causam o status do cluster vermelho, 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 do status do cluster vermelho, você pode então escalar seu domínio de OpenSearch serviço para usar tipos de instância maiores, mais instâncias ou mais armazenamento baseado em 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 do cluster vermelho antes de reconfigurar seu domínio de OpenSearch serviço. 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 seu cluster ficar vermelho continuamente por mais de uma hora, o OpenSearch Service tentará corrigi-lo automaticamente redirecionando fragmentos não alocados ou restaurando a partir de snapshots anteriores.

Se não conseguir corrigir um ou mais índices vermelhos e o status do cluster permanecer vermelho por um total de 14 dias, o OpenSearch Serviço 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)

No 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 seu 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ê recebe notificações no painel Notificações do console de OpenSearch serviço para cada um desses eventos. Para ter 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
JVM MemoryPressure	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 de memória continuar crescendo além do que o coletor de lixo pode recuperar durante a coleta de lixo completa, ocorrerá uma OpenSearch falha com um erro de falta de memória. 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 ter mais informações, consulte JVM OutOfMemoryError. 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 são inicializados com um status de cluster amarelo porque não há outro nó ao qual o OpenSearch Serviço possa atribuir uma réplica. Para obter o status de cluster verde, aumente a contagem de nós. Para ter 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 os dados são OpenSearch replicados 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 menor que o valor mínimo de 1) 20% do espaço de armazenamento disponível ou 2) 20 GiB de espaço de armazenamento, operações básicas de gravação, como adição de documentos e criação de índices, podem começar a falhar. Cálculo de requisitos de armazenamentofornece um resumo de como o OpenSearch Serviço usa o espaço em disco.

Para evitar problemas, monitore a FreeStorageSpace métrica no console OpenSearch de serviço e crie CloudWatch alarmes para acionar quando FreeStorageSpace cair abaixo de um determinado limite. GET /_cat/allocation?vtambém fornece um resumo útil da alocação de fragmentos e do uso do disco. Para resolver problemas associados à falta de espaço de armazenamento, escale seu domínio de OpenSearch serviço para usar tipos de instância maiores, mais instâncias ou mais armazenamento baseado em EBS.

Alta pressão da memória da JVM

Quando a MemoryPressure métrica da JVM excede 92% por 30 minutos, o OpenSearch Service aciona um mecanismo de proteção e bloqueia todas as operações de gravação para evitar que o cluster alcance o 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 MemoryPressure métrica da JVM retorna para 88% ou menos por 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á.

JVM OutOfMemoryError

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 OpenSearch cluster permaneçam em uma condição de falha.

Para verificar essa condição, abra o painel do seu domínio no console OpenSearch de serviço. 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 CloudWatch alarme para notificá-lo 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 terminações e reinicializações inesperadas de nós, crie pelo menos uma réplica para cada índice em seu OpenSearch domínio de serviço.

Limite máximo de fragmentos excedido

OpenSearch bem como 7. As versões x do Elasticsearch têm uma configuração padrão de no máximo 1.000 fragmentos por nó. OpenSearch/Elasticsearch gera um erro se uma solicitação, como a criação de 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

Seu domínio OpenSearch de serviço entra no estado “Processamento” quando está no meio de uma alteração na configuração. Quando você inicia uma alteração na configuração, o status do domínio muda para “Processando” enquanto o OpenSearch Serviço cria um novo ambiente. No novo ambiente, o OpenSearch Service lança um novo conjunto de nós aplicáveis (como dados, mestre 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 meu domínio do Amazon OpenSearch Service está preso no estado “Processando”? .

O saldo de intermitência do EBS está baixo

OpenSearch O serviço envia uma notificação ao console quando o saldo máximo do EBS em um de seus volumes de uso geral (SSD) está 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 BurstBalance CloudWatch métrica.

Não é possível habilitar logs de auditoria

Você pode encontrar o seguinte erro ao tentar habilitar a publicação do registro de auditoria usando o console OpenSearch de serviço:

A política de acesso a recursos especificada para o grupo de CloudWatch registros de registros não concede permissões suficientes para que o Amazon OpenSearch Service crie um fluxo de registros. 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

OpenSearch O serviço oferece suporte à _closeAPI somente para as versões 7.4 OpenSearch e posteriores do Elasticsearch. 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 do 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 Service. OpenSearch

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 limitará as solicitações se a carga útil fizer com que o uso da memória exceda o tamanho máximo do heap Java.

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

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

Se precisar de mais informações sobre o desempenho do cluster, você pode publicar registros de erros e registros lentos no CloudWatch.

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

OpenSearch Os instantâneos de serviço não são compatíveis com a classe de armazenamento 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

OpenSearch O serviço exige que os clientes especifiquem Host nos cabeçalhos da 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 Invalid Host Header erro ao fazer uma solicitação, verifique se seu cliente ou proxy inclui o endpoint do domínio OpenSearch Service (e não, por exemplo, seu endereço IP) no Host cabeçalho.

Tipo de instância M3 inválido

OpenSearch O serviço não oferece suporte à adição ou modificação de instâncias M3 em domínios existentes em execução OpenSearch ou nas versões 6.7 e posteriores do Elasticsearch. 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 Elasticsearch 6.7 ou posterior, a seguinte restrição se aplica:

• 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.

As consultas quentes param de funcionar após a ativação UltraWarm

Quando você ativa UltraWarm em um domínio, se não houver substituições preexistentes na search.max_buckets configuração, o OpenSearch Service define automaticamente o valor como para evitar que consultas com muita memória 10000 saturem os nós quentes. Se suas hot queries estiverem usando mais de 10.000 buckets, elas poderão parar de funcionar quando você ativar. UltraWarm

Como você não pode modificar essa configuração devido à natureza gerenciada do Amazon OpenSearch Service, você precisa 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á ajudá-lo a restaurar o snapshot de pré-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 AWS CLI comando describe-regions do Amazon EC2 para criar uma lista de todas as regiões nas quais OpenSearch o serviço pode estar disponível. Em seguida, exige list-domain-namesque 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 serviço não está disponível retornam “Não foi possível conectar-se ao URL do endpoint”.

Erro do navegador ao usar OpenSearch painéis

Seu navegador agrupa mensagens de erro de serviço em objetos de resposta HTTP quando você usa painéis para visualizar dados em seu domínio de OpenSearch serviço. 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 Redes.

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 vê armazenamento de índice ou distorção de fragmentos, talvez seja necessário forçar uma realocação de fragmentos, o que ocorre com cada implantação azul/verde do seu domínio de serviço. OpenSearch

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

Ao criar um novo domínio usando o console OpenSearch de serviço, você tem a opção de selecionar VPC ou acesso público. Se você selecionar o acesso à VPC, o OpenSearch serviço consultará as 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ê usa a AWS CLI para criar e configurar um domínio com um VPC endpoint, não precisará acessar 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, você provavelmente desativou AWS Security Token Service (AWS STS) para sua região.

Para adicionar VPC endpoints à sua VPC, o OpenSearch serviço precisa assumir a função. AWSServiceRoleForAmazonOpenSearchService Portanto, AWS STS deve estar habilitado para criar novos domínios que usem o acesso VPC em uma determinada região. Para saber mais sobre como ativar e desativar AWS STS, consulte o Guia do usuário do IAM.

Solicitações negadas à OpenSearch API

Com a introdução do controle de acesso baseado em tags para a OpenSearch API, você pode começar a ver erros de acesso negado onde não via antes. 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 OpenSearch HTTP, uma política baseada em identidade do IAM, como a descrita acima, resultará na negação do acesso à ação do usuário vinculado. 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 se conectar ao seu domínio de OpenSearch serviço a partir da versão 3.18.0 ou inferior do Alpine Linux, a resolução de DNS poderá falhar se o domínio estiver em uma VPC e tiver 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 AWS os SDKs usam os certificados CA do seu computador, alterações nos certificados nos AWS servidores podem causar 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 evitar essas falhas mantendo os certificados CA e o sistema operacional do seu computador up-to-date. 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 no Amazon Trust Services, mas manter seu computador up-to-date é a solução mais simples. Para saber mais sobre os certificados fornecidos pelo ACM, consulte Perguntas frequentes sobre o AWS Certificate Manager.

nota

Atualmente, os domínios OpenSearch de serviço 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.