Não foi possível capturar alterações no arquivo de log via comando do plugin nagios check_logwarn chamado via PHP exec () acionado via Jenkins

estou usandonagios check_logwarn para capturar alterações nos arquivos de log.

Para testar minha configuração, adicionei manualmente a seguinte linha de log ao arquivo de log em questão -

[Mon Mar 20 14:24:31 2017] [hphp] [12082:7f238d3ff700:32:000001] []
\nFatal error: entire web request took longer than 10 seconds and timed out in /var/cake_1.2.0.6311-beta
app/webroot/openx/www/delivery/postGetAd.php on line 483

O exemplo acima deve ser capturado pelo seguinte comando nagios, porque contém a palavra-chave "Fatal"

/usr/local/nagios/libexec/check_logwarn -d /tmp/logwarn_hiphop_error -p /mnt/log/hiphop/error_`(date +'%Y%m%d')`.log "^.*Fatal*"

Saída (conforme o esperado) -

Log errors: \nFatal error: entire web request took longer than 10 seconds and timed out in /var/cake_1.2.
0.6311-beta
\nFatal error: entire web request took longer than 10 seconds and timed out in /var/cake_1.2.0.6311-beta

A execução desse comando funciona diretamente (caso 1), mas parece invocar o mesmo por meio de um exec PHP que é acionado por um projeto Jenkins não está pegando o mesmo (caso 2)

A seguir está o código PHP do caso 2 -

$errorLogCommand = '/usr/local/nagios/libexec/check_logwarn -d /tmp/logwarn_hiphop_error -p /mnt/log/hiphop/error_'.$date.'.log "^.*Fatal*"';
$output = exec($errorLogCommand);
file_put_contents('/var/cake_1.2.0.6311-beta/deployment/deployment.log', "\n ".date("Y-m-d H:i:s")." Checked error key words in error_".$date.".log. command -> ".$errorLogCommand, FILE_APPEND);
if($output!="OK: No log errors found")
{
    file_put_contents('/var/cake_1.2.0.6311-beta/deployment/deployment.log', "\n ".date("Y-m-d H:i:s")." - Hiphop errors -> ".$output, FILE_APPEND);

    $failure=true;
    break;
}
else
{
    file_put_contents('/var/cake_1.2.0.6311-beta/deployment/deployment.log', "\n ".date("Y-m-d H:i:s")." - No Error found -> ".$output, FILE_APPEND);
}

A seguir está a saída -

 2017-03-20 14:16:45 Checked error key words in error_20170320.log. command -> /usr/local/nagios/libexec/
check_logwarn -d /tmp/logwarn_hiphop_error -p /mnt/log/hiphop/error_20170320.log "Fatal"
 2017-03-20 14:16:45 - No Error found -> OK: No log errors found

Observe que com o mesmo comando nagios (/usr/local/nagios/libexec/check_logwarn) como no caso 1, erro de log não é detectado nesse caso, inesperadamente.

A seguir, minhas observações sobre o conteúdo do arquivo rastreador interno que o nagios gera -/tmp/logwarn_hiphop_error/mnt_log_hiphop_error_20170320.log -

Quando um erro é detectado no caso 1, a seguir estão as alterações no arquivo -

Antes, e executando o comando

# logwarn 1.0.10 state for "/mnt/log/hiphop/error_20170320.log"
INODENUM="1208110246"
LINENUM="110"
POSITION="111627"
MATCHING="true"

Depois de executar o comando

# logwarn 1.0.10 state for "/mnt/log/hiphop/error_20170320.log"
INODENUM="1208110246"
LINENUM="116"
POSITION="112087"
MATCHING="false"

Além disso, a seguir estão as alterações no mesmo arquivo no caso 2 -

Antes de executar o arquivo php

# logwarn 1.0.10 state for "/mnt/log/hiphop/error_20170320.log"
INODENUM="1208110246"
LINENUM="102"
POSITION="109329"
MATCHING="true"

Depois de

# logwarn 1.0.10 state for "/mnt/log/hiphop/error_20170320.log"
INODENUM="1208110246"
LINENUM="110"
POSITION="111627"
MATCHING="true"

Não sei por que oMATCHING O parâmetro é verdadeiro no caso 2, enquanto no caso 1 é falso. De fato, a correspondência de erro ocorreu no caso 1.

Atualizar

Eu tentei agrupar o comando em umescapeshellcmd, para garantir que a regex não seja removida -

$output = exec(escapeshellcmd($errorLogCommand)); 

mas ainda não há alteração na saída.

Atualização 2

Descobri que eu tinha quebras de linha na linha de log que eu estava adicionando manualmente. Removendo aqueles corrigidos de forma consistente para o caso de executar o arquivo PHP na linha de comando. No entanto, o problema ainda é reproduzível de forma consistente no caso 2, onde estou iniciando o projeto via Jenkins e esse arquivo é chamado em um dos ganchos da implantação do código da AWS.

Bem, parece que isso não será resolvido com tanta facilidade. O problema foi corrigido para a invocação manual do arquivo PHP, mas na invocação via Jenkins, ainda estou recebendo o mesmo problema de forma consistente.

questionAnswers(1)

yourAnswerToTheQuestion