Elasticsearch:Configurar parâmetros YAML

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

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 Kibana console 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 YAML. 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. Consulte Log on to the Kibana console 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 YAML. 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 Configure audit logs. 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 Limitations. Para visualizar os logs, você deve primeiro ativar Audit Log Indexing. Para mais informações, consulte Query logs. Para outras versões, visualize os logs de auditoria 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 YAML. O valor padrão é false.
   Watcher	Quando ativado, permite o uso do recurso Watcher do X-Pack. Limpe periodicamente os índices .watcher-history* para evitar que consumam espaço excessivo em disco. Corresponde à configuração xpack.watcher.enabled no arquivo YAML. O valor padrão é false.
   Other Configurations	Os seguintes parâmetros também são suportados. Salvo indicação em contrário, essas configurações são compatíveis com Elasticsearch 5.x, 6.x e 7.x por padrão. Configure CORS access http.cors.enabled http.cors.allow-origin http.cors.max-age http.cors.allow-methods http.cors.allow-headers http.cors.allow-credentials Configurar a lista de permissões de reindexação remota reindex.remote.whitelist Configure audit logs 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 Configure queue size 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. Tanto o default_pipeline quanto o final_pipeline são executados apenas quando um documento é indexado (ações index/create, as ações index/create em _bulk e quando um upsert realmente insere um novo documento); eles são executados em cada operação de indexação, incluindo uma sobrescrita completa de um documento existente, e não apenas na primeira gravação. Ao executar _update (uma atualização parcial ou via script) em um documento existente, nenhum pipeline de ingestão é acionado: nem o default_pipeline nem o final_pipeline são executados. O uso de doc_as_upsert juntamente com um pipeline de ingestão não é oficialmente suportado, portanto, não é possível usá-lo para acionar o final_pipeline. Exemplo de configuração YAML: 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 Kibana Dev Tools: 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 Kibana Dev Tools: 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. Otimizar consultas de correspondência exata numérica (reduzir pressão de GC) Este parâmetro é suportado apenas para Elasticsearch 7.10 e versões posteriores. Se o seu cluster executa um grande volume de consultas de correspondência exata (term ou terms) em campos numéricos e a pressão de GC está alta, defina search.numeric_exact_match_query_allow_docvalues como true para ativar a otimização de consulta baseada em BKD. As correspondências exatas numéricas serão então executadas em doc_values, o que reduz a pressão de GC. Exemplo de configuração YAML: search.numeric_exact_match_query_allow_docvalues: true Este parâmetro também suporta configuração dinâmica. Execute o seguinte comando no Kibana Dev Tools para aplicar a configuração sem reiniciar o cluster: PUT /_cluster/settings { "persistent": { "search.numeric_exact_match_query_allow_docvalues": true } } Configurar compressão HTTP O Elasticsearch pode comprimir respostas HTTP para reduzir a quantidade de dados transmitidos pela rede. Para ativar esse recurso, configure http.compression no arquivo YAML. Exemplo de configuração YAML: http.compression: true Após a ativação do recurso, nem toda requisição receberá uma resposta comprimida. O Elasticsearch retorna uma resposta comprimida apenas quando a requisição do cliente contém o cabeçalho Accept-Encoding: gzip. Portanto, além de ativar este parâmetro no arquivo YAML, certifique-se de que seu cliente envie esse cabeçalho de requisição. Configurar o limite do disjuntor de fielddata (indices.breaker.fielddata.limit) O parâmetro indices.breaker.fielddata.limit especifica o limite superior de memória heap que o fielddata pode utilizar. Quando o limite é atingido, as requisições acionam o disjuntor para proteger o nó. Importante Se você definir esse limite do disjuntor com um valor excessivamente alto, o fielddata poderá usar mais memória heap, o que pode causar um erro de falta de memória (OOM) no nó e afetar a estabilidade do cluster. Ajuste esse limite com cautela.
   Forced Update	Controla se a alteração de configuração YAML 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 YAML. Valores válidos: Nota É possível configurar o parâmetro Forced Update apenas 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, em seguida, alterna o tráfego perfeitamente para os novos nós. Esse processo é mais suave, mas leva mais tempo, e os endereços IP dos nós mudam. Para mais informações sobre modos de alteração, consulte Change modes.

   Importante

   • A configuração do arquivo YAML 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 service 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 tempos limite 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 YAML de um cluster (como aumento ou redução de escala) e o status do cluster for Updating, apenas uma alteração local é suportada para quaisquer alterações adicionais. Consulte view the change history para verificar se há uma alteração azul-verde em andamento para a configuração YAML.

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

   Após a confirmação, o cluster Elasticsearch é reiniciado. Durante a reinicialização, é possível acompanhar o progresso na lista Tasks. Após a conclusão da reinicialização, a configuração do arquivo YAML entra em vigor.

Parâmetros que não podem ser modificados

O Alibaba Cloud Elasticsearch suporta apenas os parâmetros YAML listados na documentação do product. Os seguintes parâmetros não podem ser modificados.

Os parâmetros discovery.zen.* geralmente não precisam ser ajustados. O parâmetro index.translog.flush_threshold_size é uma configuração de nível de índice, e não um item de configuração YAML de nível de cluster. É possível configurá-lo usando uma configuração de índice.

Se você enviar um parâmetro não suportado na seção Other Configurations, o sistema retornará um erro indicando que a configuração YAML é inválida e que você deve verificar o arquivo de configuração YAML (código de erro: InvalidEsConfig).

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 YAML do ES_1, configure a lista de permissões da API Reindex. A entrada da lista de permissões deve ser 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 no painel, adicione a configuração de lista de permissões anterior.

Configurar logs de auditoria

Versão 7.x e posteriores

1. Acesse o painel YML File Configuration.

   Para mais informações, consulte Modify the configuration.

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

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

   Após ativar o log 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, é possível configurar apenas o parâmetro xpack.security.audit.logfile.events.include.

   • Por padrão, a configuração de log de auditoria registra logs apenas para 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 log 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 Query logs. Este recurso está disponível apenas em algumas regiões. Para mais informações, consulte Limitations.

Versões 5.x e 6.x

1. Acesse o painel YML File Configuration.

   Para mais informações, consulte YML file configuration.

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

   A seguir está a configuração padrão para indexação de log de auditoria. Ajuste-a conforme suas necessidades de negócios.

   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 em buffer são liberados para o índice.
   xpack.security.audit.index.rollover	daily	Frequência com que um novo índice é criado por rollover. Os 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 Limitations. Para uma lista completa de tipos de eventos, consulte Tipos de eventos de auditoria (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 Tipos de eventos de auditoria (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 deve ignorar ou incluir o corpo da requisição enviado via REST quando um tipo específico de evento, como authentication_failed, é 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 de auditoria 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

   Os índices de log de auditoria consomem espaço de armazenamento do cluster. O Elasticsearch não os expira ou exclui automaticamente, portanto, exclua manualmente os índices de log de auditoria antigos.

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

   Para clusters das versões 5.x e 6.x, configure os shards para índices de log de auditoria usando xpack.security.audit.index.settings. A configuração a seguir 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 log de auditoria sejam criados com os parâmetros fornecidos, passe essa configuração ao ativar a indexação de log de auditoria (definindo xpack.security.audit.enabled como true). Caso contrário, os índices de log de auditoria usam 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 primário único e múltiplas réplicas para o 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 a seguir 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 em que você precisa de 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.

Como verificar se a compressão HTTP está ativada para meu cluster Elasticsearch?

Políticas de segurança impedem que a configuração detalhada de um cluster seja lida diretamente. Verifique o valor atual de http.compression por conta própria de uma das seguintes maneiras.

Método 1: Consulte as configurações do cluster executando o seguinte comando curl.

curl -u <user>:<password> -XGET "https://<your-es-endpoint>:9200/_cluster/settings?include_defaults=true&filter_path=defaults.http.compression"

Método 2: Execute o seguinte comando no Kibana Dev Tools.

GET /_cluster/settings?include_defaults=true&filter_path=defaults.http.compression

Interprete o resultado da seguinte forma: se defaults.http.compression na resposta for true, a compressão HTTP está ativada para o cluster. Se o valor for false, a compressão HTTP não está ativada. Para ativá-la, configure http.compression: true na seção Other Configurations. Para mais informações, consulte a seção Modificar a configuração deste tópico.