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
Descubra o Opensearch: a ferramenta opensource para análise de logs e monitoramento
Heeey! Podemos nos referir ao Opensearch como um fork do Elasticsearch e Kibana 7.10. Basicamente, o Opensearch é uma ferramente de monitoração de aplicação e análise de logs totalmente opensource
Graylog – Gerenciando todos os seus Logs
Este post tem como objetivo apresentar um guia para instalação e configuração do Graylog em Debian 8 (Jessie), suportado pelos bancos de dados noSQL MongoDB e ElasticSearch e com alta
Guia completo sobre PromQL: a linguagem de consulta do Prometheus
Nesse post vamos falar sobre o PromQL, que nada mais é do que uma linguagem de consulta do Prometheus, ela nos possibilita selecionar e agregar dados de séries temporais em