Nosso problema original
No ano passado, tivemos um problema em que um software nocivo em um servidor enviou spam ao nosso servidor Graylog central com tantas mensagens que causou problemas para outros aplicativos.
O principal problema eram as mensagens úteis mais antigas de outros aplicativos que eram eliminadas antes do normal, com o índice preenchido com mensagens inúteis do aplicativo não autorizado.
Minha solução sugerida foi fornecer a cada aplicativo seu próprio índice, para que nenhum aplicativo pudesse privar qualquer outro aplicativo de espaço de armazenamento de log. Isso não exigiria nenhuma alteração nos próprios aplicativos e exigiria apenas alterações dentro do Graylog. No entanto, nada foi feito, pois uma nova solução Graylog baseada em kubernetes estava sendo planejada.
A solução que nos foi oferecida
Avançando até agora, estamos no processo de comissionamento do nosso sistema Graylog substituto.
Inicialmente, fomos informados de que cada aplicativo teria seu próprio servidor graylog independente (balanceador de carga, endpoints gelf, nós graylog, cluster de pesquisa elástica) e site front-end de graylog.
O problema é que existe um relacionamento complexo entre diferentes aplicativos e é necessário acessar diferentes servidores web graylog para logs de aplicativos diferentes (graylog-application1.site para logs do aplicativo1 e graylog-application2.site para logs do aplicativo2, em vez do que apenas acessar graylog.site) tornaria as pesquisas entre aplicativos realmente difíceis.
A solução revisada
Depois que isso foi apontado, foi proposta uma solução para agrupar aplicativos de acordo com a probabilidade de eles precisarem ser pesquisados juntos, então agora esperamos ter servidores Graylog separados por grupo (application-group-a.site para aplicativo 1 e 3, e application-group-b.site para aplicativos 2, 4 e 5 etc.).
Eu me pergunto se isso é necessário ou suficiente.
Isso significará que muitas pesquisas prováveis entre aplicações serão fáceis de fazer, mas alguns dos problemas de suporte mais difíceis de resolver são aqueles que ultrapassam os limites da aplicação, que são menos óbvios, e essas pesquisas não serão mais tão fáceis (e podem de fato será impossível, se você não souber qual aplicativo está envolvido).
As pessoas argumentam que apenas ter índices separados em um único servidor central de graylog não fornece isolamento suficiente entre grupos de aplicativos. Eles querem ter certeza de que a entrada de mensagens de um aplicativo nunca poderá interferir na entrada de mensagens de outros aplicativos, por isso desejam um isolamento completo entre os grupos.
Meu problema com isso é que não ajudaria se um aplicativo dentro de um grupo se tornasse desonesto e enviasse spam para o servidor graylog do grupo. Se pudermos encontrar uma solução que impeça a solução de negação de serviço dentro de um grupo, também teremos uma solução para um único serviço Graylog centralizado.
Eu diria que escalar um único serviço central horizontalmente com mais nós de graylog com carga balanceada, mais nós de pesquisa elásticos, mais pontos finais GELF, etc., seria uma solução melhor do que ter dezenas de servidores de graylog.
Questões
Os servidores graylog separados realmente forneceriam o nível de isolamento (mitigação de negação de serviço) que as pessoas parecem querer, quando todos estão hospedados no mesmo cluster Kubernetes?
Podemos fornecer um nível de isolamento semelhante ou melhor com um único servidor Graylog central do que com servidores Graylog de grupos separados?
Outras organizações usam o Graylog dessa forma, com muitos sites front-end, ou seria esperado um único site central para acessar todos os logs?
Essencialmente, procuro me convencer de que não estou me preocupando com nada e que essa solução é comum; ou argumentos para convencer as pessoas de que o que estamos considerando é contrário às melhores práticas e que realmente não deveríamos estar fazendo isso.
Gostaria muito de encontrar uma solução que funcionasse para todos, mas neste momento parece-me que estamos a deitar fora o bebé juntamente com a água do banho com a solução actualmente proposta.
Responder1
Suas preocupações e perguntas sobre a arquitetura da configuração do Graylog são bastante válidas. É importante encontrar uma solução que equilibre a necessidade de isolamento e gestão de recursos com facilidade de utilização e capacidade de gestão. Vamos decompô-lo como Kris Kross!
1. Os servidores Graylog separados realmente forneceriam o nível de isolamento (mitigação de negação de serviço) que as pessoas parecem desejar, quando todos estão hospedados no mesmo cluster Kubernetes?
Servidores Graylog separados executados no mesmo cluster Kubernetes podem fornecer algum nível de isolamento, mas é importante entender que eles ainda compartilham recursos no nível do cluster, incluindo largura de banda de rede, armazenamento e, potencialmente, CPU e memória. Se um aplicativo dentro de um grupo se tornar desonesto e começar a enviar mensagens de spam, isso poderá afetar potencialmente o desempenho de outros servidores Graylog no mesmo cluster devido à contenção de recursos. Embora o Kubernetes ofereça recursos de gerenciamento de recursos, não é uma solução mágica para prevenir problemas relacionados a recursos.
2. Podemos fornecer um nível de isolamento semelhante ou melhor com um único servidor Graylog central do que com servidores Graylog de grupo separados?
Um único servidor Graylog central pode fornecer isolamento entre aplicativos usando índices separados, mas, como você mencionou, pode não impedir que um aplicativo não autorizado sobrecarregue o servidor e cause problemas para outros aplicativos. Para mitigar isto, pode considerar a implementação de políticas mais rigorosas de limitação e estrangulamento de taxas nas entradas ou fontes que geram mensagens de registo. Além disso, você pode dimensionar o servidor Graylog central horizontalmente para lidar com o aumento da carga, o que pode ser mais econômico do que gerenciar vários servidores separados.
3. Outras organizações usam o Graylog dessa forma, com muitos sites front-end, ou seria esperado um único site central para acessar todos os logs?
A escolha de ter vários sites front-end para diferentes instâncias do Graylog ou um único site central depende das necessidades e preferências específicas da organização. Ambas as abordagens são válidas e têm as suas próprias vantagens e compromissos.
Vários sites front-end: esta abordagem é adequada quando diferentes equipes ou aplicativos exigem instâncias separadas do Graylog para melhor isolamento, controle e organização. Pode simplificar o controle de acesso e dar autonomia a diferentes equipes. No entanto, pode exigir que os usuários alternem entre diferentes interfaces para pesquisas entre aplicativos.
Site central único: um site central único para acessar todos os logs fornece uma visão unificada de toda a infraestrutura de log, facilitando pesquisas entre aplicativos. Essa abordagem simplifica o acesso do usuário, mas pode exigir controle de acesso e gerenciamento de permissões mais robustos para garantir a separação de dados entre diferentes equipes ou aplicativos.
Em última análise, a escolha entre estas abordagens depende das prioridades da sua organização relativamente ao isolamento, à facilidade de utilização, à gestão de recursos e aos requisitos específicos das suas aplicações e equipas.
Para encontrar uma solução equilibrada que funcione para todos, considere o seguinte:
- Implemente políticas rígidas de limitação e aceleração de taxa em cada instância do Graylog para evitar que aplicativos não autorizados sobrecarreguem o sistema.
- Monitore e alerte sobre o uso e desempenho de recursos em todas as instâncias do Graylog para detectar e resolver problemas de forma proativa.
- Documente e comunique as melhores práticas para gerenciamento e uso de logs a todas as equipes.
- Continue a explorar a possibilidade de uma solução Graylog centralizada com escalonamento de recursos e mecanismos de controle de acesso adequados.
Em suma, a melhor abordagem pode envolver uma combinação. Você pode usar instâncias separadas do Graylog para grupos lógicos de aplicativos enquanto implementa práticas robustas de gerenciamento e monitoramento de recursos para garantir a estabilidade geral de sua infraestrutura de gerenciamento de logs. Também é importante envolver stakeholders de diferentes equipes no processo de tomada de decisão para garantir que a solução escolhida esteja alinhada com suas necessidades e expectativas, apenas uma sugestão para evitar problemas de wiggity wiggity wiggity whack, sabe? ;)
Responder2
A grande vantagem oferecida pelo Graylog (e produtos similares) não é o armazenamento de logs isoladamente, mas ocorrelação entre diferentes fontes de log e eventos registrados.Ao usar vários servidores Graylog separados, cada um coletando fontes diferentes, a correlação de várias fontes se torna muito mais difícil.
Eu sugeriria usar um único servidor Graylog (ou uma configuração de vários nós em cluster, se um único nó não for suficiente) e vários índices específicos, com políticas de rotação diferentes (e apropriadas). Você pode rotear o tráfego para esses índices por meio deRegras de transmissão(e selecionando "Remover correspondências do fluxo padrão").