Escalar o ES para o LogStash é um problema difícil, especialmente para casos com intervalos de retenção muito diferentes. Para escalonamento ES, existem dois grandes botões para girar:
- Campos no catálogo global
- Número de fragmentos (índices * partição * contagem de réplicas)
O número de campos dimensiona os requisitos do Java HEAP em tudo. Eu ouvi histórias de horror de pessoas permitindo entradas JSON que resultam em eventos como este:
http.192-168-82-19.request = "GET /"
http.192-168-82-19.verb = "GET"
http.192-168-82-19.path = "/"
http.192-168-82-19.response_time = 12022
E assim por diante. Como você pode imaginar, isso cria um número surpreendentemente grande de campos no catálogo. Levou muito tempo para sair desse buraco, então preste atenção em suas entradas e tente não entrar nele. Para uma arquitetura de vários clientes, como a sua, é uma boa ideia exercitar o controle de alterações nos campos permitidos em seus índices; você será mais feliz por isso.
O número de shards dimensiona o Java HEAP novamente, bem como o tempo de recuperação quando um nó faz failover. 8 TB em 30 fragmentos recupera de forma diferente de 8 TB em 300. Geralmente, menos é melhor, mas isso depende da sua RAM.
Uma das métricas que uso para determinar se um cluster do ElasticSearch é dimensionado corretamente é o quanto é difícil fazer manutenção nele. Se eu estiver na nuvem e meu método de correção for criar uma nova imagem de base e implantar uma nova VM, ficarei muito preocupado com o tempo necessário para preencher essa nova instância com dados. Nesse caso, estou mais propenso a adicionar nós de dados para manter meu tempo de recuperação totalmente por motivos de manutenção. Se estou em servidores reais e meu método de correção é reiniciar a caixa e continuar em execução, as recuperações de caixa cheia são muito mais raras, portanto, estou menos preocupado com vários dados de TB em meus nós de dados. Só você pode decidir onde está seu ponto de dor.
Versões mais recentes do ElasticSearch (a série 5.x especificamente) tem um recurso de reindexação que pode ser incrivelmente útil para casos como o seu, especialmente quando emparelhados com o Curator. Uma vez que seus índices envelhecem até um certo ponto, onde eles estão apenas sendo mantidos por motivos de conformidade, você pode reindexar os índices diários de uma semana em um único semanário. Isso transforma 70 fragmentos (2 réplicas * 5 partições * 7 dias) em 10 fragmentos, com o custo de desacelerar as pesquisas naquela semana.
Esse tipo de coisa pode ser muito difícil em seus servidores, então pode não ser a escolha certa. Mas é uma técnica que permite que você execute um cluster 'archive' de servidores ES com seus próprios períodos de retenção e consulta.