Elasticsearch:Configure parâmetros YAML

Notas de uso

modifique a configuração

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

   1. acesse o 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 em 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 visualize 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 o sistema cria automaticamente um índice ao receber um documento 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. Ative-a de uma das seguintes maneiras: Importante Índices criados automaticamente podem não atender aos seus requisitos. Avalie o impacto antes de ativar este recurso. Ative essa configuração em Cluster Configuration no console. Essa alteração é estática e aciona a reinicialização do cluster. Ative-a dinamicamente sem reinicializar. acesse o console do Kibana e use um dos seguintes comandos para permitir a criação automática de índices: Permitir a criação automática para todos os índices PUT /_cluster/settings { "persistent": { "action": { "auto_create_index": "true" } } } Importante Esse comando permite a criação automática de todos os índices. Para desativar o recurso, altere true para false. Permitir a criação automática apenas para índices específicos. O exemplo a seguir permite a criação automática apenas de índices do sistema: PUT /_cluster/settings { "persistent": { "action": { "auto_create_index": "+.*,-*" } } }
   Index Deletion	Define a necessidade de nomear explicitamente um índice para exclua-lo. Se selecione Allow Wildcards, você poderá usar curingas para exclua índices em massa. Índices excluídos não podem ser recuperados. Use essa 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 esse recurso apenas quando necessário. Para mais informações sobre os parâmetros, consulte Configure audit logs. Importante No Elasticsearch 7.x e versões posteriores, é possível visualize os logs de auditoria no console. Esse recurso está disponível apenas em algumas regiões. Para mais informações, consulte Limitations. Para visualize os logs, ative primeiro Audit Log Indexing. Para mais informações, consulte Query logs. Em outras versões, visualize os logs de auditoria no cluster. Por exemplo, consulte os í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 o consumo excessivo de espaço em disco. Corresponde à configuração xpack.watcher.enabled no arquivo YAML. O valor padrão é false.
   Other Configurations	Os parâmetros a seguir também são suportados. Salvo indicação em contrário, essas configurações são compatíveis com as versões 5.x, 6.x e 7.x do Elasticsearch 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 Configure 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 de plugin SQL personalizado xpack.sql.enabled Por padrão, um cluster Elasticsearch ativa o plugin SQL integrado no X-Pack. Para fazer upload de um plugin SQL personalizado, defina xpack.sql.enabled como false. Configure 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 solicitações individuais de índice, processando documentos antes da gravação no índice. index.final_pipeline: Especifica o pipeline de ingestão final para um índice. Esse pipeline é executado após a conclusão de todos os outros pipelines, incluindo o default_pipeline. 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 insere um novo documento). Eles são executados em cada operação de indexação, incluindo a substituição completa de um documento existente, e não apenas na primeira gravação. Ao executar _update (uma atualização parcial ou com 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 com um pipeline de ingestão não tem suporte oficial, 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 Configure limite de resultados de consulta index.max_result_window: Controla o número máximo de resultados retornados pelo parâmetro from + size em uma consulta. Para o Elasticsearch 7.4.0 e versões posteriores, o valor padrão é 10000. modifique esse valor (até 100000) executando o seguinte comando da API REST: PUT /<index_name>/_settings { "index": { "max_result_window": 100000 } } Importante defina max_result_window com um valor alto aumenta a sobrecarga de memória e CPU. Para cenários de paginação profunda, use 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. modifique 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 significa que essa alteração é persistida na configuração do cluster e permanece efetiva mesmo após a reinicialização da instância do 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 uso 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 não exibirá mais informações de monitoramento de índices. Para visualize o status do índice, execute o comando GET _cat/indices. Otimizar consultas de correspondência exata numérica (reduzir pressão de GC) Esse parâmetro é suportado apenas no Elasticsearch 7.10 e versões posteriores. Se o seu cluster executar um grande número de consultas de correspondência exata (term ou terms) em campos numéricos e a pressão de GC estiver 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 sã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 Esse parâmetro também suporta configuração dinâmica. execute o seguinte comando no Kibana Dev Tools para que a configuração tenha efeito sem reinicializar o cluster: PUT /_cluster/settings { "persistent": { "search.numeric_exact_match_query_allow_docvalues": true } } Configure 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 solicitação recebe uma resposta compactada. O Elasticsearch retorna uma resposta compactada apenas quando a solicitação do cliente contém o cabeçalho Accept-Encoding: gzip. Portanto, além de ativar esse parâmetro no arquivo YAML, certifique-se de que seu cliente envie esse cabeçalho de solicitação. Configure o limite do disjuntor de fielddata (indices.breaker.fielddata.limit) O parâmetro indices.breaker.fielddata.limit especifica o limite superior da memória heap que o fielddata pode usar. Quando o limite é atingido, as solicitações acionam o disjuntor para proteger o nó. Importante Se você defina 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 será forçada. Valores válidos: Close: A alteração não é forçada. escolha um modo de alteração (alteração no local ou alteração azul-verde) conforme necessário. O sistema verifica a integridade do cluster, como a disponibilidade de nós e o status de alocação de shards, para garantir a segurança da alteração. Enable: A alteração é forçada. O sistema ignora o status de integridade do cluster, como falhas de nó ou shards não atribuídos, o que pode causar instabilidade durante a fase de reinicialização.
   Update Mode	Especifica como aplicar as alterações ao arquivo YAML. Valores válidos: Nota É possível configure o parâmetro Forced Update apenas quando o parâmetro Close estiver definido como Close. In-place Update (Default): O sistema realiza uma alteração em rolling 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 a mesma quantidade 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 os modos de alteração, consulte Change modes.

   Importante

   • A configuração do arquivo YAML aciona uma reinicialização em rolling do cluster. Se os índices no cluster tiverem 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 menor que o número de núcleos de CPU), o service normalmente permanece disponível durante a reinicialização. A duração da reinicialização depende do tamanho do cluster, do volume de dados e da carga. execute essa operação fora dos horários de pico.

   • Se a carga do cluster estiver alta, os índices não tiverem réplicas e sua carga de trabalho envolver um grande número de solicitações de gravação ou consulta, poderão ocorrer tempos limite de acesso ocasionais durante a alteração do cluster. Configure um mecanismo de nova tentativa em seus scripts de acesso do cliente para minimizar o impacto em seus services.

   • Se uma alteração azul-verde estiver em andamento para a configuração YAML de um cluster (como scale up ou scale down) e o status do cluster for Updating, apenas uma alteração no local é suportada para quaisquer alterações adicionais. Consulte o histórico de alterações para verifique se uma alteração azul-verde está em andamento para a configuração YAML.

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

   Após confirme, o cluster Elasticsearch é reinicializado. Durante a reinicialização, visualize 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 parâmetros a seguir não podem ser modificados.

Os parâmetros discovery.zen.* geralmente não precisam ser ajustados. O index.translog.flush_threshold_size é uma configuração no nível do índice, e não um item de configuração YAML no nível do cluster. Configure-o 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 é necessário verifique o arquivo de configuração YAML (código de erro: InvalidEsConfig).

Configure acesso CORS

Configure 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 para ES_1 e clique em Edit ao lado de Configure Private Connection. No painel lateral Configure Private Connection, clique em Endpoint ID de destino.

   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 em ícone ao lado do ID do endpoint para visualize 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 para 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 YAML configuration. No editor YAML Other configure no painel, adicione a configuração de lista de permissões anterior.

Configure 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 do 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, configure apenas o parâmetro xpack.security.audit.logfile.events.include.

   • Por padrão, a configuração do log de auditoria registra logs apenas para solicitações negadas ou com falha. Para obter logs de solicitaçõ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. Esse 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 YAML 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 com base nas necessidades do seu 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 solicitação em lote.
   xpack.security.audit.index.flush_interval	1s	Frequência com que os eventos armazenados 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. Esse recurso está disponível apenas em algumas regiões. Para mais informações, consulte Limitations. Para obter 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. Esse parâmetro é suportado apenas para clusters das versões 5.x e 6.x. Para obter 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	Especifica se deve ignorar ou incluir o corpo da solicitação enviado via REST quando um tipo de evento específico, como authentication_failed, é acionado.

   Aviso

   Se um log de auditoria contiver informações do corpo da solicitação, dados confidenciais 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 log 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 os índices de log de auditoria antigos manualmente.

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 você quiser 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.

Configure tamanho da fila

FAQ

Como configure o modo de primário único e múltiplas réplicas para o Elasticsearch?

Para configure um índice com um shard primário e múltiplas réplicas, especifique os parâmetros number_of_shards e number_of_replicas ao crie o índice. O exemplo a seguir crie 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 solicitações de pesquisa.

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

As políticas de segurança impedem a leitura direta da configuração detalhada de um cluster. 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 modifique a configuração deste tópico.