Criação de log do servidor multitier

2

Eu tenho um aplicativo multicamadas, consistindo de muitos servidores em diferentes sub-redes (cada uma dessas sub-redes dedicadas para o propósito da aplicação que elas fornecem sem outros servidores independentes do aplicativo). Esses servidores são windows, debian, freebsd e, no futuro, podem existir outros também.

Eu quero ter um mecanismo de registro centralizado para meus sistemas. O problema é que eu quero primeiro que os dados sejam coletados em uma DMZ e depois acessados pelo servidor de log que estará em uma sub-rede da rede local diferente.

Eu também preciso de log para os meus dispositivos de rede, mas isso poderia ser um servidor de log totalmente diferente para todos os que me importo (embora seria melhor se este não fosse o caso).

Como você impeliria esse tipo de registro? A arquitetura é dividida desta forma para fins de segurança e não será alterada.

Já vi o Scribe e o Logstash como soluções viáveis. Você os recomendaria para um empreendimento como o descrito anteriormente?

A implementação de scripts usando o mecanismo ssh é o caminho a seguir?

    
por Athanasios Kataras 02.05.2013 / 14:12

1 resposta

3

Você pode fazer isso com qualquer um dos servidores syslog modernos (minha recomendação seria syslog-ng porque eu estou familiarizado com isso, mas rsyslog é outra opção).
Praticamente todo sistema suporta syslog de alguma forma (todo roteador / switch de nível profissional com que trabalhei faz, máquinas Unix, e acredito que o Windows pode até mesmo enviar mensagens de log de eventos para servidores syslog), o que o torna uma boa opção .

O protocolo syslog é datagrama UDP tradicionalmente não seguro, mas os servidores syslog modernos têm suporte TCP, e eu sei syslog-ng também suporta SSL / TLS.

No que diz respeito à maneira como você coleta os dados de log, as estratégias de implementação variam.

Uma opção é simplesmente permitir que todos os seus hosts se conectem ao servidor syslog e fazer com que eles enviem suas mensagens de log para lá. Isso é relativamente simples, mas potencialmente menos seguro (você precisa dar um soco em muitos buracos de firewall ou permitir que o universo inteiro fale com seu servidor de log).

Outraopçãosãoosagregadoresdeloglocaisqueencaminhamparaumservidordelogcentral(semelhanteàarquiteturaquevocêdescreveemsuapergunta).Issogeralmenteéconsideradoumaopçãomelhorpordoismotivosprincipais:

  • Émaisfácilproteger
    Oservidordelogcentralsóprecisaaceitarconexõesdeclientes"autorizados" e os servidores de log locais só precisam aceitar conexões de sua rede local.

  • Oferece-lhe alguma redundância
    Se o servidor de log central estiver inativo para manutenção, você ainda estará coletando logs nos servidores locais e eles poderão ser encaminhados quando o servidor central estiver disponível novamente.

por 03.05.2013 / 17:26

Tags