O Nagios está “monitorando” a WAN como ideal?

Question

Acabei de começar em uma nova empresa e uma das minhas primeiras tarefas é procurar alternativas para o sistema de monitoramento interno.

Sua solução atual é um aplicativo .Net que verifica vários dispositivos pela WAN (já que eles são uma empresa de consultoria de TI que fornece suporte / "manutenção" 24/7). Os dispositivos variam de roteadores / switches / impressoras a servidores e serviços MS.

Depois de ler inúmeras postagens no site e pesquisar bastante, parece que o consenso é que algum tipo de combinação de Nagios / Munin é o caminho a ser seguido.

O que me leva à (s) minha (s) pergunta (s):

A) É possível ter um servidor Nagios rodando localmente na empresa e monitorar vários sites externos pela WAN? (Eles não querem um servidor Nagios local em cada site, pois a maioria dos sites são relativamente pequenos (10-25 hosts) e o número de sites é bastante grande (75-100)).

B) Em caso afirmativo, como os agentes entrariam em contato com o backend do Nagios? Através do SSH? HTTP?

C) Além do fato de que seria suscetível a falhas de link WAN, quais seriam os inconvenientes imediatos de tal solução?

Qualquer feedback é apreciado e peço desculpas antecipadamente por quaisquer conceitos errôneos, já que sou bastante novo no setor.

    

Answer 1

O monitoramento por uma WAN é possível, mas geralmente não é ideal. Isso ocorre porque, se o link da WAN cair ou desaparecer, todas as verificações falharão e você ficará cego para o que está acontecendo no local remoto. Você também aumentou a latência, tornando-a menos útil para medições de desempenho do LAN View. Dito isto, se você está indo desta maneira, você provavelmente deseja configurar dependências para que você não seja inundado com alertas quando o link da WAN tiver problemas.

A maneira mais comum de comunicação entre um sistema de monitoramento e seus serviços monitorados é ter um túnel VPN site a site. Então a comunicação não é diferente da rede local. Além disso, o Nagios geralmente é baseado em Pull (embora não precise ser). Então, o Nagios entra em contato com os serviços e servidores que monitora, e não o contrário.

Por último, uma solução mais ideal é usar uma configuração de monitoramento distribuído, com Nagios uma opção é descrita em link .

    

Answer 2

Depende do que você vai monitorar sobre o wan. Na maior parte, se você estiver apenas fazendo checagens de ping, verificações de serviços, verificações de disco, etc., e ficar com o tempo padrão de verificação de 5 min do nagios, não consigo ver isso causando um problema.

Novamente, dependendo do que você está verificando, depende do que será discutido. Se você estiver verificando os hosts do Windows, basta usar as consultas do WMI e nem precisar de um agente em execução na caixa.

    

Answer 3

Isto é certamente possível, através de vários métodos diferentes.

Se a "configuração distribuída" estiver fora de questão, será necessário pelo menos um dos seguintes procedimentos:

1. Cada caixa no site remoto envia os resultados da verificação para o Nagios (consulte NSCA )
2. Crie furos de firewall para que o Nagios possa alcançar todas as caixas em todos os sites remotos
3. Designe uma única caixa em cada site para ser uma espécie de "proxy do Nagios"

Eu sugeriria o # 3, porque ele requer menos furos de firewall e também simplifica a configuração. É uma espécie de versão mais enxuta da configuração distribuída, pois não requer uma instância completa do Nagios em cada site.

Para fazer isso, você pode configurar NRPE (ou use check_by_ssh ) e faça com que este "proxy" execute todas as outras verificações em relação aos outros hosts no rede. Isso tem o benefício adicional dos dados de desempenho que você recebe de volta em relação ao proxy, portanto, ele não será afetado pelo atraso da WAN.

Além disso, você pode usar configurações pai / filho para tornar cada host no site remoto um filho de seu proxy, para reduzir as notificações de falso positivo. Você também pode querer tornar todos os serviços dependentes de um serviço check_nrpe (ou check_ssh) do proxy. Consulte os documentos acessibilidade de rede para obter mais informações.

Não importa qual método você usar, é muito importante que você ajuste os tempos limite padrão adequadamente, para compensar o atraso de percorrer os links WAN.