Como acionar uma verificação de serviço por uma mudança em um status de host?

Question

Temos uma matriz de servidores, e qualquer um deles pode diminuir, gerando uma notificação de prioridade média:

define host {
        host_name       foo1
        contacts        medium-priority
        use     default-host
}
...

No entanto, gostaríamos de uma notificação de prioridade mais alta sempre que mais de dois servidores estivessem com problemas. Para esse fim, configuramos uma definição de serviço separada usando o check_cluster -utility de Nagios / Icinga:

define service {
        service_description     foo-cluster
        servicegroups   cluster-checks
        display_name    Foo Cluster
        check_command   check_cluster_host!Foo Cluster!0!3!$HOSTSTATEID:foo1$,$HOSTSTATEID:foo2,...$HOSTSTATEID:fooN$
        contacts        high-priority
        hostgroup_name  clusters
        notes   Check, that no more than 2 hosts in group foo are in trouble
        use     default-service
}

O acima provavelmente funcionará, mas eu gostaria que essa verificação de serviço fosse disparada não pelo tempo, mas apenas por uma alteração no status de qualquer um dos hosts "subjacentes". ..

Nós geramos os arquivos de configuração do Icinga com o Ansible e assim podemos construir dependências complexas programaticamente - mas tal desencadeamento pode ser implementado em tudo ?

    

Answer 1

Você poderia definir um manipulador de eventos no host, que basicamente é um pequeno script "fazendo algo com base em parâmetros". Você pode passar os atributos de estado do host de macros de tempo de execução como parâmetros de comando.

link

Eu seguia a rota e definia um var personalizado no host que define os serviços a serem acionados quando um manipulador de eventos é disparado. Dessa forma, você não precisa codificá-los dentro do script.

Seu script pode então decidir forçar uma nova verificação de serviço através do canal de comando externo. Você provavelmente deve definir se os estados HARD ou SOFT são suficientes - lembre-se de que os manipuladores de eventos são acionados apenas em uma alteração de estado, e não em DOWN- > DOWN- > DOWN por exemplo.

Exemplo: link

Nota: Esse serviço não deve ter as verificações ativas ativadas e não usar um comando fictício, mas o comando de verificação de serviço real.

(tal submissão de resultado de verificação aconteceu no antigo mundo Nagios / Icinga1 para um monitoramento distribuído um tanto hackeado também, se você estiver procurando por mais exemplos com o comando pipe e manipuladores de evento).