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.