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:
About author
Você pode gostar também
ELK Stack vs OpenSearch Stack: Qual escolher?
Ter uma observabilidade completa do seu ambiente com poucas ferramentas, é o sonho de todo profissional DevOps. Diversas ferramentas no mercado atendem essa demanda prometendo entregar apenas uma solução para
Automatização de ambientes com Rundeck
Por que automatizar seu ambiente? Nos últimos anos, a automação tem crescido como um elemento imperativo em todos os negócios. Independente da área, temos observado um notável aumento no uso
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.







