Estou configurando uma configuração de Icinga distribuída da seguinte maneira. Temos 6 sites, então estou monitorando 3 em cada um dos dois nós, além de um servidor central.
Os sites a, b, c são ativamente monitorados pelo nó 1
Os sites d, e, f são ativamente monitorados pelo nó 2
nós 1 & 2 enviar cheques passivos para o servidor central
O problema que estou atingindo é que o servidor central deve ser o servidor master aqui, como seria de se esperar. Por este motivo, deve compreender a acessibilidade em toda a rede. O que não consigo descobrir é vincular os hosts dos dois nós no mapa de status e, assim, na alcançabilidade. Um exemplo abaixo:
Icinga(onócentral)estásendoexecutadoemumaVMUbuntuemumservidorvSpherenosite(a).Parachegaraosite(d)apartirdonócentral,ocaminhológicoconsistenoservidorvSphere,umcomutador,outrocomutadore,emseguida,umroteador.Esseroteadorseconectaaoutroroteadornosite(d)e,emseguida,alternae,eventualmente,hospeda.
Meuproblemaéquenãopossodefinirumhostnonó2(nestecaso,oroteadornosite(d))paraterumpaiquenãoexistanonó2(seu"pai" para acessibilidade deve seja o roteador no site (a)).
Isso foi ... incrivelmente difícil de explicar. Existe uma maneira de contornar isso? Eu tentei declarar o roteador do site (a) novamente no nó 2, esperando que as duplicatas fossem ignoradas pelo servidor central, mas usadas pelo nó, mas sem sucesso. Eu gostaria que meu mapa de status central pudesse ser visualizado logicamente e não com cada site apenas gerando a instância de Icinga de forma ilógica.
Na verdade, acabei de descobrir que isso era principalmente um problema com minha própria metodologia. A solução que tentei funcionará, mas não do jeito que eu estava fazendo:
Ter roteador definido no nó 1 e central, com o pai correto
Ter roteador definido no nó 2, sem pai
Dessa forma, nenhuma instância única de Icinga vê uma duplicata, e o servidor central agora a trata corretamente.
Tags monitoring icinga