Nagios / Icinga: Não mostra CRÍTICO para partições DRBD no nó de espera

Question

Eu configurei um ha-cluster de marcapasso / corosync em uma configuração de failover com dois nós: produtivo e de espera. Existem três partições DRBD. Tudo funciona bem até agora.

Estou usando o Nagios NRPE em ambos os nós para monitorar o servidor com icinga2 como ferramenta de relatório e visualização. Agora, como as partições DRBD no nó de espera não são montadas até que haja um comutador de failover, sempre recebo avisos críticos sobre isso:

Porisso,esteéumalertafalso.EujátropeceinoDISABLE_SVC_CHECKetenteiimplementá-lo,aquiestáumexemplo:

echo"['date +%s'] DISABLE_SVC_CHECK;$host_name;$service_name" >> "/var/run/icinga2/cmd/icinga2.cmd"

Não existe uma maneira fácil / prática recomendada de desabilitar essa verificação de DRBD no nó de espera no Nagios ou no Icinga2? É claro que eu quero que esta verificação entre em vigor para o modo de espera após um failover.

    

Answer 1

Eu aconselharia não monitorar isso diretamente no host. Em nosso ambiente, utilizamos o Pacemaker para automatizar os failovers. Uma das coisas que o Pacemaker faz por nós é mover um endereço IP no failover. Isso garante que nossos clientes estejam sempre apontando para o principal e ajudando a tornar os failovers transparentes do lado do cliente.

Para o Nagios, monitoramos uma série de serviços em cada host para ficar de olho nas coisas, mas temos um "host" adicional configurado para o endereço IP virtual / flutuante para monitorar os dispositivos e serviços DRBD que estão sendo executados apenas em o primário.

    

Answer 2

No meu ambiente, gerenciamos vários serviços executados em dispositivos drbd (tradicional, contêineres lxc, contêineres docker, bancos de dados, ...). Usamos a pilha opensvc ( link ) que é gratuita e opensource e fornece recursos de failover automáticos. Abaixo está um serviço de teste com drbd, e um aplicativo de redis (desativado no exemplo)

Primeiro, no nível do cluster, podemos ver na saída svcmon que:

• 2 nós cluster opensvc (nó-1-1 e nó-1-2)
• o serviço servdrbd está ativo (em maiúscula, verde O) no nó-1-1 e em espera (em minúsculas, o verde) no nó-1-2
• node-1-1 é o nó mestre preferido para este serviço (acento circunflexo próximo a O maiúsculo)

No nível de serviço svcmgr -s servdrbd print status , podemos ver:

• no nó primário (à esquerda): podemos ver que todos os recursos estão ativos (ou em espera; isso significa que eles devem permanecer ativos quando o serviço estiver sendo executado no outro nó). E sobre o dispositivo drbd, é relatado como Primário
• no nó secundário (à direita): podemos ver que apenas os recursos standby estão ativos e o dispositivo drbd está no estado Secundário .

Para simular um problema, desconectei o dispositivo drbd no nó secundário e produzi os seguintes avisos

É importante ver que o status de disponibilidade do serviço ainda está up , mas o status geral do serviço está degradado para warn , o que significa "ok, a produção ainda está funcionando bem , mas algo dá errado, dê uma olhada "

Assim que você estiver ciente de que todos os comandos opensvc podem ser usados com o seletor de saída do json ( nodemgr daemon status --format json ou svcmgr -s servdrbd print status --format json ), é fácil conectá-lo a um script NRPE e monitorar apenas os estados do serviço. E como você viu, qualquer problema no primário ou secundário é preso.

O nodemgr daemon status é melhor porque é a mesma saída em todos os nós do cluster e todas as informações de serviços do opensvc são exibidas em uma única chamada de comando.

Se você estiver interessado em um arquivo de configuração de serviço para essa configuração, eu o publiquei em pastebin aqui

    

Answer 3

Você pode usar o check_multi para executar as verificações do DRBD como uma única verificação do Nagios e configurá-lo para retornar OK se exatamente um das sub-verificações estiver OK.

É complicado quando você precisa decidir qual host anexar o cheque também. Você pode anexá-lo a um host usando o VIP ou anexar o cheque a ambos os hosts e usar NRPE / ssh em cada um para verificar o outro, etc.