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

Saudações,

Gostaria de pedir a opinião dos coletivos e ver os sistemas de monitoramento distribuído, o que você usa e o que sabe que pode marcar minhas caixas?

Os requisitos são bastante complexos;

Nenhum ponto único de falha. Realmente. Estou falando sério! Precisa ser capaz de tolerar falhas de nó único / múltiplo, 'mestre' e 'trabalhador' e você pode presumir que nenhum local de monitoramento ("site") possui vários nós ou está na mesma rede. Portanto, isso provavelmente exclui as técnicas tradicionais de HA, como DRBD ou Keepalive.
Lógica distribuída, eu gostaria de implantar mais de 5 nós em várias redes, em vários datacenters e em vários continentes. Quero que a visualização "Olho de pássaro" da minha rede e aplicativos da perspectiva de meus clientes, os pontos de bônus para a lógica de monitoramento não sejam afetados quando você tiver mais de 50 nós ou mais de 500 nós.
Precisa ser capaz de lidar com um número razoavelmente razoável de verificações de host / serviço, a Nagios, para valores estimados que pressupõem 1500-2500 hosts e 30 serviços por host. Seria muito bom se adicionar mais nós de monitoramento permitisse escalar de forma relativamente linear, talvez daqui a cinco anos eu esteja procurando monitorar 5000 hosts e 40 serviços por host! Adicionando a partir 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 outros $ n ou n% de nós, correlacione os resultados e 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 é algo útil. Idealmente, sua solução proposta deve gerar relatórios "prontos para uso" com o mínimo de esforço.
Deve ter uma API sólida ou sistema de plug-ins para o desenvolvimento de verificações personalizadas.
Precisa ser sensato sobre alertas. Não quero necessariamente saber (via SMS, às 03:00!) Que um nó de monitoramento calcula que meu roteador principal está inoperante. Eu não quero saber se um percentual definido deles concordam que alguma coisa divertida está acontecendo;) Basicamente o que eu estou falando aqui é "quorum" lógica, ou a aplicação de sanidade à loucura distribuídos!

Estou disposto a considerar as opções comerciais e de código aberto, embora eu prefira evitar softwares que custam milhões de libras :-) Também estou disposto a aceitar que talvez não exista nada lá fora que marque todas essas caixas, mas queria perguntar isso ao coletivo.

Ao pensar em monitorar nós e seu posicionamento, lembre-se de que muitos deles serão servidores dedicados em redes de ISPs aleatórias e, portanto, estão fora da minha esfera de controle. Soluções que dependem de feeds BGP e outras palhaçadas complexas de rede provavelmente não serão adequadas.

Devo também salientar que já avaliei, implantei ou usei / usei muito a maioria dos sabores de código aberto no passado, incluindo Nagios, Zabbix e amigos - eles não são realmente ferramentas ruins, mas são fracassos em geral " distribuído ", particularmente no que diz respeito à lógica discutida na minha pergunta e nos alertas 'inteligentes'.

É um prazer esclarecer todos os pontos necessários. Cheers rapazes e moças :-)

monitoring nagios sla

— nixgeek
fonte

Isso é realmente estranho, eu estava prestes a fazer uma pergunta semelhante. Nesta semana, tivemos algumas reclamações de clientes sobre interrupções no site, mas apenas em determinados locais. Nossos sistemas de alerta não detectaram esses problemas. Entramos em contato com nosso provedor e eles confirmaram que alguns deles tinham alguns problemas de espinha dorsal. Então, eu também estou interessado em uma solução. Obrigado!

— splattne

E qual foi a solução final?

— ewwhite

Respostas:

não é uma resposta realmente, mas algumas dicas:

definitivamente dê uma olhada na apresentação sobre nagios @ goldman sachs . eles enfrentaram problemas que você menciona - redundância, escalabilidade: milhares de hosts, também geração de configuração automatizada.
Eu tinha uma configuração redundante de nagios, mas em uma escala muito menor - 80 servidores, ~ 1k de serviços no total. um servidor mestre dedicado, um servidor escravo que puxa a configuração do mestre em intervalos regulares algumas vezes por dia. os dois servidores cobriam o monitoramento das mesmas máquinas, tinham verificação de integridade entre si. eu usei o nagios principalmente como estrutura para chamar verificações específicas de produtos personalizados [vários trabalhos cron executando scripts que executam 'controles de fluxo artificiais', resultados são registrados no sql, plugins nrpe verificam se há execuções com êxito / com falha nos últimos x minutos]. tudo funcionou muito bem.
sua lógica de quorum parece boa - um pouco semelhante aos meus 'fluxos artificiais' - basicamente continue, ipmplement your self; -]. e peça ao nrpe apenas verificar algum tipo de sinalizador [ou sql db com timestamp-status] como as coisas estão indo.
você provavelmente desejará construir uma hierarquia para escalar - terá alguns nós que reúnem uma visão geral de outros nós; observe a apresentação desde o primeiro ponto. os nagios bifurcados padrão para cada verificação são um exagero 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 de mestre-escravo [sql primário ou servidor de aplicativos + modo de espera quente], sem mestre-mestre.
minha configuração envolvia 'fator de filtragem humano' - grupo de resolvedores 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, eles recebiam 'verificação de mensagens nagios' como uma tarefa adicional que não sobrecarregava muito. e eles se encarregam de garantir que os db-admins / it-ops / app-admins realmente estejam se levantando e corrigindo problemas; -]
Eu ouvi muitas coisas boas sobre o zabbix - para alertar e traçar tendências, mas nunca o usei. Para mim, o munin faz o truque, hackeei o simples plugin do nagios, verificando se existe alguma cor [crítica] vermelha na lista de servidores do munin - apenas uma verificação adicional. você também pode ler os valores dos arquivos munin rrd para diminuir o número de consultas enviadas à máquina monitorada.

— pQd
fonte

@astinus - bom para alertas sensíveis, usei um script de notificação personalizado. em vez de confiar nos nagios notificar por correio / pager, eu armazenei a mensagem no fifo que e tinha um consumidor que despachou a mensagem com base na lógica personalizada [com base na programação de chamadas bastante flexível etc.], além disso, havia um limite de msgs enviadas por hora. não recebe 50 smses em pouco tempo. vejo abordagens semelhantes em escalas maiores - o nagios é apenas um esqueleto e as pessoas escrevem em torno dele e, na verdade, usam cada vez menos recursos.

— pQd

No que diz respeito à hierarquia, o que tenho no momento é uma instalação Nagios totalmente "modular", na qual o diretório etc / contém uma configuração 'principal' que é compartilhada (e idêntica) em todos os hosts e, em seguida, etc / modules / $ NAME : Mail, Web, Rede, DNS), que é 100% portátil entre servidores. Incluir com cfg_dir =) Você colocar em qualquer específicas do módulo comandos, plugins e tudo para esse diretório. Fazer> 1 servidor executar esses controlos é muito fácil como você acabou de copiar o módulo para tantas caixas Nagios como necessários, no entanto, mais uma vez, a lógica alerta provoca problemas :-)

— nixgeek

@ astinus # 2. no meu caso, a replicação de configuração master-> slave ocorre a cada 6h. se o mestre simplesmente morrer [falta de energia, etc] - o escravo alertará a todos sobre o mestre estar morto [verifique entre os servidores]. pode-se imaginar outro cenário - quando o mestre morre por causa de erros de configuração. se isso acontecer até 5 minutos antes da sincronização da configuração com o escravo - haverá notificação. se for um pouco antes da sincronização da configuração - infelizmente não temos sistema de monitoramento. 'quem vigiará o vigia'? bem, talvez mais um nagios muito simples.

— pQd

@ pQd - interessante, eu concordo que a implementação da lógica em scripts de notificação personalizados é provavelmente o caminho a percorrer. No entanto, fica bastante complicado evitar notificações duplicadas de mais de 2 hosts, quando você diz 50 hosts de monitoramento e ainda não vi ninguém (em público) colocar sua lógica compartilhada em um sistema de passagem de 'mensagem' adequado, como Rabbit ou Amazon SQS.

— Nixgeek 04/07/09

@ astinus # 3 no meu caso, era a solução 'Nível 8' [do modelo iso osi]: os principais nagios estavam enviando sms'es para as pessoas que estavam de plantão + e-mails para o 24/5 'resolver group', enquanto os nagios secundários estavam apenas enviando ' grupo de resolução '. coube a esse grupo filtrar duplicatas antes de escalar;

— pQd

O que você está pedindo soa muito como o que Shinken fez por Nagios.

Shinken é uma reescrita de Nagios.

Linguagem moderna (Python)
Estrutura de programação distribuída moderna (Pyro)
Domínios de monitoramento (multilocação), HA, peças de reposição
API do Livestatus
Compatível com o plugin Nagios
Execução NRPE nativa
Criticidade comercial de objetos
As regras de negócios podem ser aplicadas ao estado dos objetos (gerenciando a disponibilidade de cluster ou pool)
A criação de gráficos pode usar PNP4nagios baseados em grafite ou RRDtool
Estável e sendo implantado em grandes ambientes
Grandes implantações podem considerar emparelhá-lo com o Splunk para gerar relatórios ou analisar o Graphite, onde o RRDtool não é um bom ajuste.

Isso deve servir de reflexão.

Felicidades

— xkilian
fonte