Instance Operations - Elasticsearch: Central de Documentação do Alibaba Cloud

Monitoramento de instância

Para visualizar as métricas de execução da instância, acesse a página do product da instância no console e escolha Monitoring and Logging > Cluster Monitoring no painel de navegação à esquerda. Defina limiares de alerta com base nos objetivos de nível de service (SLOs) do seu negócio e nas linhas de base de testes de estresse. Os nomes das métricas e os pontos de entrada de alertas exibidos no console são as referências válidas.

A página Cluster Monitoring agrupa as métricas por categoria, e não por função de nó, como nós de índice ou nós de consulta. Para observar os dois tipos de nó separadamente, defina Resource Type para um nó específico e filtre pelo nome do nó. Os nomes dos nós de índice contêm -index-. Os nomes dos nós de consulta contêm -search-, embora os nomes das métricas no console usem tanto Query quanto Search. A edição Agent Engine não possui nós warm, portanto, monitore apenas os nós de índice e os nós de consulta.

A tabela a seguir mapeia alvos comuns de observação para as métricas do console, agrupadas por dimensão. Comece pelas métricas de nível de cluster, detalhe até as métricas de nível de nó e trate as rejeições de pool de threads como sinais de capacidade.

Alvo de observação	Métrica do console	Dimensão
Throughput de escrita	Cluster Write QPS	Nível de cluster
Latência de escrita	Average Cluster Write Latency	Nível de cluster
Throughput de consulta	Cluster Query QPS	Nível de cluster
Latência de consulta	Average Cluster Search Latency	Nível de cluster
Utilização de CPU	Node CPU Utilization_ES Business, Node CPU Utilization_Total	Nível de nó
Utilização de memória heap	Node Heap Memory Utilization_ES Business	Nível de nó
Rejeições	Number of Tasks Rejected by the Write Thread Pool, Number of Requests Rejected by the Query Thread Pool	Nível de pool de threads

Permissões de Collection

O acesso a Collections, Slices e Backings é controlado pelas permissões de índice e permissões de cluster configuradas nas funções.

Escopo de autorização de Collection e Backing

Ao configurar uma função, geralmente é necessário conceder permissões de acesso tanto ao nome da Collection quanto ao Backing subjacente. Configure os dois valores a seguir na função e substitua <collection> pelo nome da sua Collection:

<collection>
.sc-<collection>-*

Por exemplo, se a Collection for nomeada como knowledge-chunks, configure knowledge-chunks e .sc-knowledge-chunks-* na função. Se você configurar apenas o nome da Collection e omitir o padrão do Backing, leituras e escritas de documento único, MGet, atualização explícita, _update_by_query e _delete_by_query podem retornar HTTP 403. Para resolver esse erro, adicione o padrão correspondente do Backing à função. As permissões exigidas por cada operação de API prevalecem, e aplicações online não devem acessar o Backing diretamente.

Importante

Verifique se há sobreposição de prefixos antes de conceder permissões. O padrão .sc-knowledge-chunks-* também corresponde ao Backing de knowledge-chunks-private, portanto, esse padrão isoladamente não garante isolamento estrito entre Collections. O padrão .sc-* tem um escopo ainda mais amplo e não deve ser usado como configuração padrão de menor privilégio.

Permissões necessárias para cada operação

A tabela a seguir lista as permissões necessárias para cada operação.

Operação	Permissões necessárias
Crie, atualize ou exclua uma Collection ou Slice	A permissão de índice `manage` na Collection
Pré-criar um Backing	A permissão de índice `manage` na Collection
Chamar `POST /{collection}/_warm_slice` para aquecer uma Slice	A permissão de índice `manage` na Collection
Iniciar ou cancele Copy Slice	A permissão de índice `manage` na Collection
Crie uma Branch Slice (Beta)	A permissão de índice `manage` na Collection
Crie ou modifique um alias de Collection	A permissão de índice `manage` tanto no nome da Collection quanto no nome do alias
Obter uma Collection, consultar ou listar Slices, usar CAT ou consultar o status de cópia	A permissão de índice `monitor` na Collection
Chamar `POST /{collection}/_refresh` para atualizar explicitamente uma Collection	A permissão de índice `maintenance` na Collection. Essa permissão também inclui `flush` e `forcemerge`. Conceda-a apenas para contas de tarefas de O&M ou importação de dados, nunca para contas de aplicações online. Uma atualização explícita afeta todos os tenants de toda a Collection, e as condições de uso estão descritas em Refresh and query visibility.
Ler, escrever e consultar documentos	A permissão de índice `read` ou `write` correspondente
Usar `GET /_tasks/{taskId}` para consultar uma tarefa assíncrona de aquecimento	A permissão de cluster `monitor`

Práticas de isolamento e menor privilégio

A permissão manage abrange gerenciamento, aquecimento e exclusão de Collection simultaneamente. Conceda apenas read e write para contas online de leitura e escrita. Inicie operações de aquecimento, pré-criação de Backing, cópia, ramificação e gerenciamento de Collection ou Slice a partir de uma conta de service separada ou tarefa de O&M, limitando as Collections que a conta pode acessar. Caso seu negócio exija que uma aplicação online realize o aquecimento diretamente, aceite que a conta também terá essas capacidades de gerenciamento e restrinja as chamadas às APIs de gerenciamento na camada de aplicação.

Além disso, aplique os seguintes princípios:

Princípio de acesso da aplicação: As aplicações devem sempre acessar dados por meio do nome da Collection. Não acesse nem armazene nomes de Backing diretamente. O acesso direto a um Backing ignora o ponto de entrada lógico da Collection e a reescrita de escopo de _slice, permitindo que uma única solicitação leia os dados de todas as Slices naquele Backing.
Isolamento estrito: Para isolar estritamente credenciais entre Collections, não dependa apenas do caractere curinga do nome atual do Backing. Garanta o isolamento evitando sobreposição de prefixos entre nomes de Collection e utilizando mecanismos independentes na plataforma ou na camada de aplicação. Verifique o escopo de índice realmente acessível após cada alteração de permissão.
Isolamento de tenant e credenciais: Uma Slice não é um limite de isolamento de permissões de tenant. O modelo de permissões atual não permite emitir uma conta Elasticsearch para um único tenant que leia apenas as Slices desse tenant. Realize a autenticação e a restrição de escopo de dados no nível de tenant na camada de aplicação e nunca distribua credenciais de conta Elasticsearch diretamente aos usuários finais.

Backup e recuperação de Collection

O backup e a recuperação de Collection abrangem todo o namespace: todas as Collections de uma instância passam por backup e restauração conjuntamente. Não há suporte para restaurar apenas uma Collection ou Slice, e não é possível renomear uma Collection durante a recuperação. O Suporte Técnico realiza essas operações por meio de tickets.

Antes da recuperação, a instância de destino não deve conter nenhuma Collection, e nenhum índice subjacente com o mesmo nome do backup pode permanecer. Após definir seus requisitos de backup e antes de entrar em produção, envie um ticket informando a instância de origem, o destino da recuperação e seus requisitos de backup. O Suporte Técnico verificará a versão, as condições de armazenamento e o impacto na configuração global, agendando a janela de backup.

Durante um backup, as operações normais de leitura, consulta, escrita, atualização e exclusão de documentos nas Slices existentes podem continuar. Do início ao fim do backup, suspenda as seguintes operações de gerenciamento:

Criação, atualização ou exclusão de uma Collection
Registro ou exclusão de uma Slice, incluindo o registro automático acionado pela primeira escrita
Rollover ou troca de um Backing
Criação de uma Branch Slice (Beta)

Solicite ajuda ao Suporte Técnico para coordenar essas operações, incluindo o registro de Slice e a criação de rollover de Backing que podem ser acionados automaticamente. Se qualquer uma dessas alterações ocorrer durante um backup, crie o backup novamente.