Nagios (código de retorno de 141 está fora dos limites) em serviços aleatórios

Question

Tivemos o Nagios rodando em um de nossos servidores sem problemas por algum tempo, mas ultimamente ficamos (o código de retorno 141 está fora dos limites).

A carga no servidor aumentou porque ficamos online com o nosso serviço, mas ainda não é muito alto (carga média máxima: 0,7). Antes do lançamento, tudo no Nagios funciona bem.

Veja na imagem, Current Load retorna o código 141. 2 Minutos atrás o Beancounters VZ retornou 141. Isso acontece irregular. Apenas HTTP & O PING não retorna 141, eles não transmitem o nrpe.

link

Notei que, se eu executar o comando do meu host Nagios contra o cliente problemático, às vezes o retorno se perde:

root@xxx23:/usr/local/nagios/libexec# ./check_nrpe -H 123.123.123.123 -c check_apt 
APT OK: 0 packages available for upgrade (0 critical updates). 
root@xxx23:/usr/local/nagios/libexec# ./check_nrpe -H 123.123.123.123 -c check_apt 
root@xxx23:/usr/local/nagios/libexec# ./check_nrpe -H 123.123.123.123 -c check_apt 
APT OK: 0 packages available for upgrade (0 critical updates). 

Isso não acontece se eu o executar diretamente no cliente.

O que eu fiz:

• Eu aumentei a memória do OpenVZ e CPUUnit para esse contêiner.
• atualizei para o Nagios 3.4.1 mais recente (da origem)
• eu executei os testes do Nagios localmente através do nrpe - nunca consegui 141 de volta ou algo assim

Eu tive o mesmo problema há alguns meses com outro servidor. Não encontrou o problema e reinstalou o servidor. Funciona agora.

Alguém com uma ideia?

UPDATE

Acho que encontrei, não aconteceu por uma hora.

SIGPIPE foi uma boa dica, eu assumi algo com o sistema não com nagios.

Eu ajustei a configuração e os limites do openvz. Vou relatar de volta, se permanecer estável.

    

Answer 1

Tivemos um problema semelhante em que um serviço verificado via NRPE em um contêiner retornou um WARNING esperado e, depois de alguns minutos, o mesmo serviço retornou CRITICAL com o erro 141 / SIGPIPE. Na próxima verificação, ele retornou WARNING , depois CRITICAL , depois WARNING e assim por diante.

Eu realizei uma captura de tráfego para o erro e descobri a questão # 305 do Nagios para descrever com precisão Eu tinha observado. Parece ser causado por uma conexão impura perto do lado do servidor NRPE ao usar SSL ( SSL_shutdown() ) que faz com que ele envie um TCP RST para o cliente que causa uma leitura abortada e, portanto, o SIGPIPE.

A aplicação do patch nrpe-ssl_shutdown-2.patch anexado ao relatório de problemas para a fonte NRPE, a reconstrução e a reinstalação / reinicialização pareciam impedir que o problema se repetisse, e os avisos agora são relatados normalmente sem erros críticos.

    

Answer 2

Tivemos esse problema em várias ocasiões; parece ser causado pelo plugin morrer inesperadamente.

As ações que realizamos:

1. Aumentar o tempo limite do plug-in no Nagios para 120
2. Em alguns plug-ins perl complexos, desative a EPN (Adicionar à segunda linha do script #nagios: -epn)
3. Onde checagem usou NRPE, assegura que o NRPE estava usando / dev / urandom para que ele nunca fosse bloqueado por falta de entropia
4. Defina um command_timeout (30 seg.) razoável em nrpe.cfg
5. Certifique-se de que o servidor Nagios tenha memória / CPU suficiente para executar todas as verificações que precisam ser executadas simultaneamente.

Entre eles, estes pareciam resolver o problema.

    

Answer 3

Um código de saída de 141 corresponde ao sinal 141 - 128 = 13. O sinal 7 do homem nos diz que o sinal 13 é SIGPIPE (isto é, o processo com o qual estávamos conversando foi embora). Há um relatório de bug sobre isso relacionado ao OpenVZ não enviar sinais anteriores no link