Pelo menos na minha instalação do NAGIOS, check_host-alive na verdade executa check-ping :
define command{
command_name check-host-alive
command_line $USER1$/check_ping -H $HOSTADDRESS$ -w 3000.0,80% -c 5000.0,100% -p 5
}
Há duas coisas que me fazem pensar que definir isso como uma verificação separada do estoque check_ping não é redundante.
Em primeiro lugar, esses limites são loucamente altos. Para nenhum servidor normal estou feliz com um RTT de 2900ms ou perdas de pacotes de 70%. Esses limites são realmente úteis apenas como um teste para saber se um servidor está, na verdade, realmente inoperante. Aqui está um exemplo de limites quando realmente me importo com os valores retornados:
check_ping!200.0,20%!600.0,60%
Portanto, há uma diferença quantitativa entre o modo como o PING é usado para verificar a disponibilidade do host e quando usa um serviço por si só, e isso justifica a distinção entre o ping-como-host- up-test e ping-as-link-quality-test.
Em segundo lugar, alguns dos meus hosts monitorados não podem ser PINGed, às vezes por razões fora do meu controle. Nesses casos, usarei uma verificação de conectividade TCP simples para uma porta monitorada ou, em um caso, a saída do traceroute .
Editar : ocorreu-me que você pode estar se perguntando " por que um host do PING para verificar se está ativo, se estivermos apenas enviando o PING novamente como uma verificação de serviço ". Se essa for sua pergunta, a razão 1 acima ainda se aplica. Mas também, muitas vezes eu não me importo com o PING como uma verificação de serviço - links de má qualidade aparecerão nos muitos outros serviços que são monitorados. Então, o PING não é redundante na maioria dos casos. Se você não se importa com a saída do PING além de um teste para o host-up, não o execute como uma verificação de serviço.