Gerenciamento eficiente de índices no Elasticsearch com o Index Lifecycle Management

Gerenciamento eficiente de índices no Elasticsearch com o Index Lifecycle Management

O gerenciamento dos índices no Elasticsearch é, sem dúvidas, um dos itens mais importantes para mantermos um cluster íntegro e saudável. Porém pode ser também um dos elementos mais desafiadores, pois a forma como os dados são organizados entre os nós do cluster tem um grande impacto no desempenho e na sua confiabilidade.

Neste artigo iremos conhecer um pouco do Index Lifecycle Management (ILM) presente no Elasticsearch desde a versão 6.7.0.

O que é?

O ILM é um recurso que ajuda a automatizar a criação, o gerenciamento e a exclusão dos índices no Elasticsearch.

Com ele podemos definir, por exemplo, o tamanho máximo que uma shard poderá alcançar ou por quanto tempo o índice estará disponível para escrita.

Estudo de caso

Imagine que temos um índice que recebe uma alta quantidade de leitura e escrita nos primeiros 7 dias, após esse tempo ele recebe apenas consultas esporádicas e deve ser removido após 90 dias. Poderíamos criar uma política com 3 estágios para otimizar esse índice e economizar recursos do cluster, por exemplo:

Estágio 1:

  • 1 shard | 2 réplicas
  • Alocado nos nós com melhores recursos de hardware
  • Prioridade 100

Estágio 2 (após 7 dias):

  • 1 shard | 0 réplicas
  • Alocado nos nós com hardware menos perfomático
  • Prioridade 50
  • Tornar o índice somente leitura

Estágio 3 (após 90 dias):

  • Gerar um snapshot para consultas futuras
  • Remover o índice

No Elasticsearch, esses estágios são definidos como hot, warm, cold, frozen e delete. Importante notar que não é necessário utilizar todos os estágios na mesma política.

Exemplo:

PUT _ilm/policy/4linux-ilm-policy

{

“policy”: {

“phases”: {

“hot”: {

“min_age”: “0ms”,

“actions”: {

“rollover”: {

“max_age”: “1d”

},

“set_priority”: {

“priority”: 100

}

}

},

“warm”: {

“min_age”: “7d”,

“actions”: {

“migrate” : { },

“allocate”: {

“number_of_replicas”: 0

},

“readonly” : { },

“set_priority”: {

“priority”: 50

}

}

},

“delete”: {

“min_age”: “90d”,

“actions”: {

“delete”: {

“actions”: {

“wait_for_snapshot” : {

“policy”: “snapshot-policy”

}

}

}

}

}

}

}

}

A política acima define os seguintes estágios:

Hot

Durante o estágio hot, um novo índice será criado diariamente e sua prioridade será definida como 100.

Warm

Após 7 dias, os índices entrarão no estágio warm. Nesse estágio os índices serão migrados para os nós do tipo warm, não teremos réplicas, os índices serão somente leitura e a prioridade será definida como 50.

Delete

Após 90 dias, o índice será removido desde que a política de snapshot especificada tenha sido executada.

É de extrema importância ter noção e visibilidade do tamanho e do tempo que os índices do seu ambiente estão sendo armazenados, defina a política de maneira adequada às regras da empresa e utilize ao máximo os recursos disponibilizados pela ferramenta para ter o seu ambiente o mais saudável possível.

 

Líder em Treinamento e serviços de Consultoria, Suporte e Implantação para o mundo open source. Conheça nossas soluções:

CURSOSCONSULTORIA

 

Anterior Descubra como otimizar seu banco de dados com particionamento no PostgreSQL
Próxima Proteja seu site: aprenda a identificar vulnerabilidades com WhatWeb

About author

Você pode gostar também

Monitoramento TI

Novidades do PostgreSQL 16

Com o lançamento da nova versão 16 do PostgreSQL, teremos melhorias significativas em seu desempenho, com notáveis aprimoramentos na paralelização de consultas, carregamento em massa de dados e replicação lógica.

Infraestrutura TI

Descubra como monitorar sua JVM com Prometheus e Grafana

Saiba o que ocorre com a sua JVM! O monitoramento e a visibilidade do ambiente de TI sempre foram de grande importância para seus gestores e administradores, seja para avaliação

Monitoramento TI

Guia Prático: Configurando o Prometheus em um Cluster Kubernetes

Nesse artigo faremos um guia para configurar o Prometheus em um cluster Kubernetes. Essa configuração irá coletar métricas de nó, pods e serviços automaticamente usando um auto disconvery do Prometheus.