Elasticsearch:Configurar parâmetros YML

Notas de uso

Modificar a configuração

1. Acesse a página de detalhes do cluster.

   1. Faça login no console do Alibaba Cloud Elasticsearch.

   2. No painel de navegação à esquerda, clique em Elasticsearch Clusters.

   3. Na barra de navegação superior, selecione um grupo de recursos e uma região. Na página Clusters, clique no ID do cluster desejado.

   4. No painel de navegação à esquerda da página exibida, clique em

2. Acesse a página de configuração do arquivo YML.

3. No painel de navegação à esquerda, clique em Configuration and Management > Cluster Configuration.

4. Na página ES Cluster Configuration, clique em Modify Configuration à direita de YML File Configuration.

5. Na caixa de diálogo YML File Configuration, configure os parâmetros necessários.

   Nota

   Para visualizar o conteúdo de elasticsearch.yml, abra o console do Kibana e execute o comando GET _cluster/settings?include_defaults.

   Parâmetro	Descrição
   Auto Indexing	Define se um índice deve ser criado automaticamente quando um documento é enviado para um índice inexistente. Corresponde à configuração action.auto_create_index no arquivo YML. O valor padrão é false. O Alibaba Cloud Elasticsearch desativa a criação automática de índices por padrão. É possível ativar essa funcionalidade das seguintes formas: Importante Índices criados automaticamente podem não atender aos seus requisitos. Avalie o impacto antes de ativar este recurso. Ative esta configuração em Cluster Configuration no console. Trata-se de uma alteração estática que aciona a reinicialização do cluster. Ative dinamicamente sem reinicialização. Faça login no console do Kibana e use um dos comandos abaixo para permitir a criação automática de índices: Permitir criação automática para todos os índices PUT /_cluster/settings { "persistent": { "action": { "auto_create_index": "true" } } } Importante Este comando permite a criação automática de todos os índices. Para desativar esse recurso, altere true para false. Permitir criação automática apenas para índices específicos. O exemplo abaixo permite que apenas índices de sistema sejam criados automaticamente: PUT /_cluster/settings { "persistent": { "action": { "auto_create_index": "+.*,-*" } } }
   Index Deletion	Define se é necessário nomear explicitamente um índice para excluí-lo. Se você selecionar Allow Wildcards, será possível usar curingas para excluir índices em massa. Índices excluídos não podem ser recuperados. Use esta configuração com cautela. Corresponde à configuração action.destructive_requires_name no arquivo YML. O valor padrão é true.
   Audit Log Indexing	Quando ativado, o sistema registra logs de auditoria para operações como criação, exclusão, atualização e consulta no cluster Elasticsearch. Logs de auditoria consomem espaço em disco e podem afetar o desempenho. Ative este recurso somente quando necessário. Para mais informações sobre os parâmetros, consulte Configurar logs de auditoria. Importante Para Elasticsearch 7.x e versões posteriores, é possível visualizar logs de auditoria no console. Este recurso está disponível apenas em algumas regiões. Para mais informações, consulte Limitações. Para visualizar os logs, você deve primeiro ativar Audit Log Indexing. Para mais informações, consulte Consultar logs. Para outras versões, visualize os logs de auditoria diretamente no cluster. Por exemplo, consulte índices cujos nomes começam com .security_audit_log-* no console do Kibana. Corresponde à configuração xpack.security.audit.enabled no arquivo YML. O valor padrão é false.
   Watcher	Quando ativado, permite utilizar o recurso Watcher do X-Pack. Limpe periodicamente os índices .watcher-history* para evitar consumo excessivo de espaço em disco. Corresponde à configuração xpack.watcher.enabled no arquivo YML. O valor padrão é false.
   Other Configurations	Os seguintes parâmetros também são suportados. Salvo especificação em contrário, essas configurações são compatíveis com Elasticsearch 5.x, 6.x e 7.x por padrão. Configurar acesso CORS http.cors.enabled http.cors.allow-origin http.cors.max-age http.cors.allow-methods http.cors.allow-headers http.cors.allow-credentials Configurar lista de permissões de reindexação remota reindex.remote.whitelist Configurar logs de auditoria As versões 7.x e 8.x do Elasticsearch suportam apenas o parâmetro xpack.security.audit.logfile.events.include. As versões 5.x e 6.x suportam os seguintes parâmetros: xpack.watcher.enabled xpack.notification xpack.security.audit.enabled xpack.security.audit.index.bulk_size xpack.security.audit.index.flush_interval xpack.security.audit.index.rollover xpack.security.audit.index.events.include xpack.security.audit.index.events.exclude xpack.security.audit.index.events.emit_request_body xpack.security.audit.index.settings.index Recurso LDAP Todas as versões, exceto a 5.x, suportam o seguinte: xpack.security.authc.realms.ldap1 xpack.security.authc.realms.active_directory1 xpack.security.authc.realms.pki1 xpack.security.authc.realms.saml1 xpack.security.authc.realms.kerberos1 xpack.security.authc.token.enabled Configurar tamanho da fila thread_pool.bulk.queue_size (para versões 5.x e 6.x) thread_pool.write.queue_size (para versões 6.x, 7.x e 8.x) thread_pool.search.queue_size Configuração personalizada do plugin SQL xpack.sql.enabled Por padrão, um cluster Elasticsearch ativa o plugin SQL integrado no X-Pack. Se desejar carregar um plugin SQL personalizado, defina xpack.sql.enabled como false. Configurar pipeline (pré-processamento) index.default_pipeline: Especifica o pipeline de ingestão padrão para um índice. Esse pipeline é executado antes de qualquer pipeline especificado em requisições individuais de índice, processando documentos antes que sejam gravados no índice. index.final_pipeline: Especifica o pipeline de ingestão final para um índice. Esse pipeline é executado após todos os outros pipelines, incluindo o default_pipeline, terem sido concluídos. Diferentemente do default_pipeline, o final_pipeline é acionado apenas durante a gravação inicial do documento. Por padrão, operações de atualização não acionam o final_pipeline. Para forçar a execução do final_pipeline durante operações de atualização, defina doc_as_upsert como true. Exemplo de configuração YML: index.default_pipeline: my_pipeline index.final_pipeline: my_final_pipeline Configurar limite de resultados de consulta index.max_result_window: Controla o número máximo de resultados que podem ser retornados pelo parâmetro from + size em uma consulta. Para Elasticsearch 7.4.0 e versões posteriores, o valor padrão é 10000. É possível modificar esse valor (até 100000) executando o seguinte comando da API REST: PUT /<index_name>/_settings { "index": { "max_result_window": 100000 } } Importante Definir max_result_window com um valor alto aumenta a sobrecarga de memória e CPU. Para cenários de paginação profunda, utilize a API scroll ou search_after em vez de aumentar esse valor. Persistir configurações de cluster.max_shards_per_node O parâmetro cluster.max_shards_per_node limita o número máximo de shards (incluindo shards primários e réplicas) por nó de dados. É possível modificar esse parâmetro executando o seguinte comando no Dev Tools do Kibana: PUT /_cluster/settings { "persistent": { "cluster.max_shards_per_node": 3000 } } A palavra-chave persistent indica que essa alteração é persistida na configuração do cluster e permanece efetiva mesmo após a reinicialização da instância Elasticsearch. Não é necessário reconfigurar esse parâmetro após uma reinicialização. Desativar coleta de dados de monitoramento Se o seu cluster não tiver consultas ativas, mas o uso de memória permanecer alto, desative a coleta de dados de monitoramento para reduzir o consumo de memória. Execute o seguinte comando no Dev Tools do Kibana: PUT _cluster/settings { "persistent": { "xpack.monitoring.collection.indices": "*,-.*" } } Importante Após desativar a coleta de dados de monitoramento, a página Monitoring no Kibana deixará de exibir informações de monitoramento de índices. Para visualizar o status dos índices, execute o comando GET _cat/indices.
   Forced Update	Controla se a alteração de configuração YML deve ser forçada. Valores válidos: Close: A alteração não é forçada. Escolha um modo de alteração (alteração local ou azul-verde) conforme necessário. O sistema verifica a integridade do cluster, como disponibilidade de nós e status de alocação de shards, para garantir que a alteração seja segura. Enable: A alteração é forçada. O sistema ignora o status de integridade do cluster, como falhas de nós ou shards não atribuídos, podendo causar instabilidade durante a fase de reinicialização.
   Update Mode	Define como aplicar as alterações ao arquivo YML. Valores válidos: Nota O parâmetro Forced Update só pode ser configurado quando o parâmetro Close estiver definido como Close. In-place Update (Padrão): O sistema realiza uma alteração contínua nos nós que precisam ser atualizados. Os dados não são copiados durante a alteração, e a duração não é afetada pelo volume de dados. No entanto, esse método pode afetar o desempenho do cluster. Blue-green Update: O sistema adiciona o mesmo número de novos nós, copia os dados e então troca o tráfego para os novos nós de forma transparente. Esse processo é mais suave, porém leva mais tempo, e os endereços IP dos nós são alterados. Para mais informações sobre modos de alteração, consulte Modos de alteração.

   Importante

   • A configuração do arquivo YML aciona uma reinicialização contínua do cluster. Se os índices no cluster possuírem réplicas e a carga do cluster estiver normal (utilização de CPU em torno de 60%, uso de memória heap em torno de 50% e load_1m inferior ao número de núcleos de CPU), o serviço geralmente permanece disponível durante a reinicialização. A duração da reinicialização depende do tamanho do cluster, volume de dados e carga. Realize esta operação em horários de baixa demanda.

   • Caso a carga do cluster esteja alta, os índices não tenham réplicas e sua carga de trabalho envolva um grande número de requisições de escrita ou consulta, podem ocorrer timeouts de acesso ocasionais durante a alteração do cluster. Configure um mecanismo de nova tentativa em seus scripts de acesso ao cliente para minimizar o impacto em seus serviços.

   • Se uma alteração azul-verde estiver em andamento para a configuração YML de um cluster (como scale up ou scale down) e o status do cluster for Updating, apenas alterações locais serão suportadas para quaisquer modificações adicionais. Consulte o histórico de alterações para verificar se há uma alteração azul-verde em andamento para a configuração YML.

6. Selecione This operation will restart the cluster. Continue? e clique em OK.

   Após a confirmação, o cluster Elasticsearch será reiniciado. Durante a reinicialização, acompanhe o progresso na lista de Tasks. Após a conclusão da reinicialização, a configuração do arquivo YML entrará em vigor.

Configurar acesso CORS

Configurar lista de permissões da API Reindex

Para garantir uma migração de dados segura entre clusters, adicione o endereço de conexão privada e a porta do cluster ES_2 à lista de permissões da API Reindex do ES_1.

1. Acesse a página Security do ES_1 e clique em Edit ao lado de Configure Private Connection. No painel lateral Configure Private Connection, clique no Endpoint ID alvo.

   Para adicionar uma nova conexão, clique em + Add Private Connection na parte inferior do painel lateral Configure instance private connection.

2. No console VPC, na aba Endpoint Connections, clique no ícone ao lado do ID do endpoint para visualizar seu nome de domínio correspondente.

   Importante

   Remova o identificador de zona de disponibilidade do nome de domínio antes de adicioná-lo à lista de permissões da API Reindex.

   Por exemplo, se o nome de domínio completo for "ep-bp1-cn-hangzhou-i.epsrv-bp1.cn-hangzhou.privatelink.aliyuncs.com", remova o identificador de zona de disponibilidade "-cn-hangzhou-i" para obter o nome de domínio final: "ep-bp1bp1.epsrv-bp1.cn-hangzhou.privatelink.aliyuncs.com".

3. No arquivo YML do ES_1, configure a lista de permissões da API Reindex. A entrada da lista de permissões deve conter o nome de domínio e a porta do endpoint.

   reindex:
     remote:
       whitelist: >-
         ep-bp1bp1****************.epsrv-bp1****************.cn-hangzhou.privatelink.aliyuncs.com:9200

   Na página ES cluster configuration, clique em Modify configuration à direita de YML configuration. No editor YAML Other configure dentro do painel, adicione a configuração de lista de permissões mencionada acima.

Configurar logs de auditoria

Versão 7.x e posteriores

1. Acesse o painel YML File Configuration.

   Para mais informações, consulte Modificar a configuração.

2. Na seção Audit Log Indexing, selecione Enable para ativar os logs de auditoria.

3. Personalize a configuração de logs de auditoria.

   Após ativar os logs de auditoria, configure o parâmetro xpack.security.audit.logfile.events.include em Other Configurations. Exemplo:

   xpack:
     security:
       audit:
         logfile:
           events:
             include: >-
               access_denied,anonymous_access_denied,authentication_failed,connection_denied,tampered_request,run_as_denied,run_as_granted

   Importante

   • Para clusters da versão 7.x e posteriores, apenas o parâmetro xpack.security.audit.logfile.events.include pode ser configurado.

   • Por padrão, a configuração de logs de auditoria registra apenas requisições negadas ou com falha. Para obter logs de requisições bem-sucedidas, adicione o evento access_granted. Isso armazena todas as informações de acesso no disco, o que pode levar a um alto uso de disco. Após a solução de problemas, desative o recurso de logs de auditoria.

4. Visualize os logs de auditoria.

   Para clusters da versão 7.x e posteriores, após ativar Audit Log Indexing, visualize os logs de auditoria na página View Logs do console. Para mais informações, consulte Consultar logs. Este recurso está disponível apenas em algumas regiões. Para mais informações, consulte Limitações.

Versões 5.x e 6.x

1. Acesse o painel YML File Configuration.

   Para mais informações, consulte Configuração do arquivo YML.

2. Na seção Audit Log Indexing, selecione Enable para ativar os logs de auditoria.

   Abaixo está a configuração padrão para indexação de logs de auditoria. Ajuste-a conforme suas necessidades de negócio.

   xpack.security.audit.index.bulk_size: 5000
   xpack.security.audit.index.events.emit_request_body: false
   xpack.security.audit.index.events.exclude: run_as_denied,anonymous_access_denied,realm_authentication_failed,access_denied,connection_denied
   xpack.security.audit.index.events.include: authentication_failed,access_granted,tampered_request,connection_granted,run_as_granted
   xpack.security.audit.index.flush_interval: 180s
   xpack.security.audit.index.rollover: hourly
   xpack.security.audit.index.settings.index.number_of_replicas: 1
   xpack.security.audit.index.settings.index.number_of_shards: 10

   Parâmetro	Padrão	Descrição
   xpack.security.audit.index.bulk_size	1000	Número de eventos de auditoria a serem gravados em um índice de log de auditoria em uma única requisição em lote.
   xpack.security.audit.index.flush_interval	1s	Frequência com que os eventos bufferizados são liberados para o índice.
   xpack.security.audit.index.rollover	daily	Frequência com que um novo índice é criado via rollover. Valores válidos são hourly, daily, weekly ou monthly.
   xpack.security.audit.logfile.events.include	access_denied,anonymous_access_denied,authentication_failed, connection_denied,tampered_request,run_as_denied,run_as_granted	Tipos de eventos de log de auditoria a serem coletados. Este recurso está disponível apenas em algumas regiões. Para mais informações, consulte Limitações. Para uma lista completa de tipos de eventos, consulte Audit event types (7.x).
   xpack.security.audit.index.events.include	access_denied, access_granted, anonymous_access_denied, authentication_failed, connection_denied, tampered_request, run_as_denied, run_as_granted	Tipos de eventos de log de auditoria a serem gravados no índice. Este parâmetro é suportado apenas para clusters das versões 5.x e 6.x. Para uma lista completa de tipos de eventos, consulte Audit event types (6.x).
   xpack.security.audit.index.events.exclude	null (nenhum evento é excluído por padrão)	Eventos de log de auditoria a serem excluídos do índice.
   xpack.security.audit.index.events.emit_request_body	false	Define se o corpo da requisição enviado via REST deve ser ignorado ou incluído quando um tipo específico de evento, como authentication_failed, for acionado.

   Aviso

   Se um log de auditoria contiver informações do corpo da requisição, dados sensíveis poderão ser expostos nos arquivos de log.

3. Visualize os logs de auditoria.

   Para clusters das versões 5.x e 6.x, quando o registro de auditoria está ativado, os logs são gravados no cluster Elasticsearch em índices cujos nomes começam com .security_audit_log-*. Portanto, visualize os logs de auditoria nos índices que começam com .security_audit_log-* no console do Kibana.

   Importante

   Índices de logs de auditoria consomem espaço de armazenamento do cluster. O Elasticsearch não expira nem exclui esses índices automaticamente, portanto, exclua manualmente os índices antigos de logs de auditoria.

4. Opcional: Configure shards para índices de logs de auditoria.

   Para clusters das versões 5.x e 6.x, configure os shards para índices de logs de auditoria usando xpack.security.audit.index.settings. A configuração abaixo define tanto o número de shards primários quanto o número de réplicas como 1.

   xpack.security.audit.index.settings:
     index:
       number_of_shards: 1
       number_of_replicas: 1

   Nota

   Se desejar que os índices de logs de auditoria sejam criados com os parâmetros fornecidos, passe essa configuração ao ativar a indexação de logs de auditoria (definindo xpack.security.audit.enabled como true). Caso contrário, os índices de logs de auditoria usarão as configurações padrão de number_of_shards: 5 e number_of_replicas: 1.

Configurar tamanho da fila

Perguntas frequentes

Como configurar o modo de shard primário único com múltiplas réplicas no Elasticsearch?

Para configurar um índice com um shard primário e múltiplas réplicas, especifique os parâmetros number_of_shards e number_of_replicas ao criar o índice. O exemplo abaixo cria um índice com 1 shard primário e 2 réplicas:

PUT /<index_name>
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 2
  }
}

Essa configuração é adequada para cenários onde é necessário um único shard primário com múltiplas réplicas para melhorar a redundância de dados e a escalabilidade de leitura. Cada réplica é uma cópia completa do shard primário e pode lidar independentemente com requisições de busca.