Eu preciso configurar o registro centralizado para um conjunto de servidores (10-20) em um Amazon VPC. O registro deve ser como não perder nenhuma mensagem de log no caso de um único servidor ficar offline - ou no caso de uma zona de disponibilidade inteira ficar off-line. Ele também deve tolerar a perda de pacotes e outras condições normais de rede sem perder ou duplicar mensagens. Ele deve armazenar as mensagens de forma durável, no mínimo, em dois volumes diferentes do EBS em duas zonas de disponibilidade, mas o S3 também é um bom local. Também deve ser em tempo real para que as mensagens cheguem dentro de segundos de sua geração para duas zonas de disponibilidade diferentes. Eu também preciso sincronizar arquivos de log não gerados via syslog, portanto, uma solução de log centralizado somente syslog não atenderia a todas as necessidades, embora eu ache que essa limitação poderia ser contornada.
Eu já revisei algumas soluções, e vou listá-las aqui:
Flume to Flume para S3 : Eu poderia configurar dois servidores de logs como hosts Flume que armazenariam mensagens de log localmente ou no S3, e configuraria todos os servidores com o Flume para enviar todas as mensagens para ambos os servidores , usando as opções de confiabilidade end-to-end. Dessa forma, a perda de um único servidor não deveria causar perda de mensagens e todas as mensagens chegariam em duas zonas de disponibilidade em tempo real. No entanto, precisaria haver alguma maneira de unir os logs dos dois servidores, desduplicando todas as mensagens entregues a ambos. Isso pode ser feito adicionando um ID exclusivo no lado de envio a cada mensagem e, em seguida, gravando algumas execuções de deduplicação manual nos arquivos de log. Não encontrei uma solução fácil para o problema de duplicação.
Faça o Logstash para o Logstash para o ElasticSearch : Eu poderia instalar o Logstash nos servidores e fazer com que eles entreguem para um servidor central via AMQP, com as opções de durabilidade ativadas. No entanto, para que isso funcione, eu precisaria usar algumas das implementações do AMQP com capacidade de armazenamento em cluster ou distribuir a entrega como no caso do Flume. O AMQP parece ser mais uma parte móvel com várias implementações e nenhuma orientação real sobre o que funciona melhor nesse tipo de configuração. E eu não estou totalmente convencido de que eu poderia obter a durabilidade completa do logstash para o elasticsearch, assumindo que os servidores falham entre eles. As soluções de fan-out são executadas novamente no problema de desduplicação. A melhor solução que parece lidar com todos os casos, seria Beetle, que parece fornecer alta disponibilidade e desduplicação através de uma loja de redis. No entanto, eu não vi nenhuma orientação sobre como configurar isso com o Logstash e Redis é mais uma parte móvel novamente para algo que não deveria ser terrivelmente difícil.
Logstash para ElasticSearch : Eu poderia executar o Logstash em todos os servidores, ter todas as regras de filtragem e processamento nos próprios servidores e fazer com que eles registrem diretamente em um servidor ElasticSearch de remoção. Eu acho que isso deve me trazer log confiável e eu posso usar os recursos de cluster ElasticSearch para compartilhar o banco de dados de forma transparente. No entanto, não tenho certeza se a configuração realmente sobrevive às reinicializações do Logstash e a problemas de rede intermitentes sem duplicar mensagens em um caso de failover ou semelhante. Mas esta abordagem parece bastante promissora.
rsync : Eu poderia apenas rsync todos os arquivos de log relevantes para dois servidores diferentes. O aspecto de confiabilidade deve ser perfeito aqui, já que os arquivos devem ser idênticos aos arquivos de origem depois que uma sincronização é feita. No entanto, fazer um rsync várias vezes por segundo não parece divertido. Além disso, eu preciso que os logs não sejam controláveis depois de terem sido enviados, portanto, os rsyncs precisariam estar no modo somente de anexação. E as rotações de log bagunçam as coisas, a menos que eu seja cuidadoso.
rsyslog com RELP : Eu poderia configurar o rsyslog para enviar mensagens para dois hosts remotos via RELP e ter uma fila local para armazenar as mensagens. Há o problema de desduplicação novamente, e o próprio RELP também pode duplicar algumas mensagens. No entanto, isso só lida com as coisas que são registradas via syslog.
Nenhuma dessas soluções parece muito boa, e elas ainda têm muitas incógnitas, por isso estou pedindo mais informações aqui de pessoas que criaram registros confiáveis centralizados sobre quais são as melhores ferramentas para alcançar esse objetivo.