Sistemas de monitoramento de aplicativo / host geograficamente distribuídos, tolerantes a falhas e “inteligentes”

Question

Saudações

Gostaria de perguntar a opinião coletiva e ver sobre os sistemas de monitoramento distribuídos, o que você usa e do que você está ciente que pode marcar minhas caixas?

Os requisitos são bastante complexos;

• Nenhum ponto único de falha. Mesmo. Eu estou falando sério! Precisa ser capaz de tolerar uma falha de nó único / múltiplo, tanto 'mestre' quanto 'trabalhador', e você pode assumir que nenhum local de monitoramento ("site") possui vários nós, ou está na mesma rede. Portanto, isso provavelmente elimina as técnicas tradicionais de HA, como DRBD ou Keepalive.

• Lógica distribuída, gostaria de implantar mais de 5 nós em várias redes, em vários datacenters e em vários continentes. Eu quero a visão "Birds Eye" da minha rede e aplicações do ponto de vista dos meus clientes, pontos de bônus para a lógica de monitoramento não ficarem atolados quando você tem mais de 50 nós, ou mesmo mais de 500 nós.

• Precisa ser capaz de lidar com um número razoavelmente razoável de verificações de host / serviço, como o Nagios, pois os números de estimativa pressupõem 1500-2500 hosts e 30 serviços por host. Seria muito bom se a adição de mais nós de monitoramento permitisse que você dimensionasse de forma relativamente linear, talvez em 5 anos eu possa estar procurando monitorar 5000 hosts e 40 serviços por host! Adicionando da minha nota acima sobre "lógica distribuída" seria bom dizer:

  • Em circunstâncias normais, essas verificações devem ser executadas em $ n ou n% dos nós de monitoramento.
  • Se uma falha for detectada, execute verificações em outro $ n ou n% de nós, correlacione os resultados e, em seguida, use-os para decidir se os critérios foram atendidos para emitir um alerta.

• Gráficos e recursos amigáveis de gerenciamento. Precisamos rastrear nossos SLAs e saber se nossos aplicativos 'altamente disponíveis' estão ativos 24x7 é um pouco útil. O ideal é que sua solução proposta faça relatórios "fora da caixa" com um mínimo de desperdício.

• Deve ter um sistema sólido de API ou plug-in para o desenvolvimento de verificações personalizadas.

• Precisa ser sensível aos alertas. Eu não quero necessariamente saber (via SMS, às 3h!) Que o um nó de monitoramento calcula que meu roteador central está inativo. Eu faço quero saber se uma porcentagem definida deles concorda que algo funky está acontecendo;) Essencialmente, o que eu estou falando aqui é a lógica do quórum, ou o aplicação da sanidade à loucura distribuída!

Estou disposto a considerar as opções comerciais e de código aberto, embora eu prefira evitar o uso de software que custa milhões de libras :-) Eu também estou disposto a aceitar que pode não haver nada lá fora que agrade a todos caixas, mas queria perguntar ao coletivo que.

Ao pensar em monitorar nós e seu posicionamento, tenha em mente que a maioria deles será dedicada a servidores em redes ISPs aleatórias e, portanto, em grande parte fora de minha esfera de controle. Soluções que dependem de feeds de BGP e outras artimanhas complexas provavelmente não serão adequadas.

Eu também devo salientar que eu já avaliei, implementei ou usei muito a maioria dos sabores de código aberto no passado, incluindo o Nagios, o Zabbix e os amigos - eles não são ferramentas ruins, mas não funcionam bem. todo o aspecto "distribuído", particularmente no que diz respeito à lógica discutida na minha pergunta e alertas "inteligentes".

Feliz em esclarecer todos os pontos necessários. Felicidades, garotos e garotas: -)

    

Answer 1

não é uma resposta, mas alguns apontamentos:

• dê uma olhada na apresentação sobre nagios @ goldman sachs . eles enfrentaram problemas que você mencionou - redundância, escalabilidade: milhares de hosts, também geração de configuração automatizada.

• Eu tinha uma configuração nagios redundante, mas em escala muito menor - 80 servidores, ~ 1k de serviços no total. um servidor mestre dedicado, um servidor escravo puxando a configuração do mestre em intervalos regulares, algumas vezes por dia. ambos os servidores cobriram o monitoramento das mesmas máquinas, eles tiveram verificação cruzada de integridade entre si. Eu usei nagios principalmente como estrutura para invocar verificações específicas de produto personalizadas [bando de tarefas cron executando scripts fazendo 'controles de fluxo artificiais', resultados ware logados em sql, nrpe plugins ware verificando execuções bem-sucedidas / com falha daqueles nos últimos x minutos]. tudo funcionou muito bem.

• a sua lógica de quórum parece boa - um pouco semelhante aos meus 'fluxos artificiais' - basicamente continue, impleure seu self; -]. e ter nrpe apenas verificar algum tipo de flag [ou sql db com timestamp-status] como as coisas estão fazendo.

• você provavelmente desejará construir alguma hierarquia para escalar - você terá alguns nós que reúnem a visão geral de outros nós, olhe a apresentação do primeiro ponto. o padrão nagios bifurcando para cada cheque é exagerado em um número maior de serviços monitorados.

para responder a algumas perguntas:

• no meu caso, o ambiente monitorado era uma configuração típica mestre-escravo [servidor principal de aplicativos ou sql + hot standby], sem mestre mestre.
• minha configuração envolveu 'fator de filtragem humano' - grupo de resolução que era um 'backup' para notificação por SMS. já havia um grupo pago de técnicos que, por outras razões, tinham turnos de 24/5, e eles "checavam nagios mails" como tarefa adicional, não sobrecarregando-os. e eles se encarregam de garantir que os db-admins / it-ops / app-admins realmente se levantem e consertem os problemas; -]
• Eu ouvi muitas coisas boas sobre o zabbix - para alertar e traçar tendências, mas nunca o usei. para mim munin faz o truque, eu hackeei o plugin nagios simples verificando se há 'vermelho' [crítico] cor na munin lista de servidores - apenas uma verificação adicional. você também pode ler valores de arquivos rrd do munin para diminuir o número de consultas que você envia para a máquina monitorada.

Answer 2

O que você está pedindo parece muito com o que o Shinken fez pelo Nagios.

Shinken é uma reescrita do Nagios.

• Linguagem moderna (Python)
• Estrutura de programação distribuída moderna (Pyro)
• Monitorando reinos (multilocação), HA, peças sobressalentes
• Livestatus API
• Compatível com plug-in do Nagios
• Execução nRPE nativa
• Criticidade de negócios dos objetos
• As regras de negócios podem ser aplicadas ao estado dos objetos (gerenciando a disponibilidade do cluster ou do pool)
• A representação gráfica pode usar PNP4nagios baseados em Graphite ou RRDtool
• Estável e sendo implantado em grandes ambientes
• Implantações grandes podem considerar emparelhá-lo com o Splunk para relatórios ou pesquisar no Graphite, onde o RRDtool não é um bom ajuste.

Isso deve ser uma boa ideia.

Felicidades