Невозможно записать изменения в файл журнала с помощью команды плагина nagios check_logwarn, вызванной через PHP exec (), запущенной через Jenkins

я использую nagios check_logwarn захватывать изменения в лог-файлы.

Чтобы проверить мои настройки, я вручную добавил следующую строку журнала в соответствующий файл журнала:

[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

Вышеприведенное должно быть поймано следующей командой nagios, потому что она содержит ключевое слово «Fatal»

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

Выход (как и ожидалось) —

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

Запуск этой команды напрямую работает (Случай 1), но кажется, что вызов того же самого через PHP exec, который запускается через проект Jenkins, не улавливает то же самое (случай 2).

Ниже приведен код PHP для случая 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);
}

Следующий вывод —

 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

Обратите внимание, что с той же командой nagios (/usr/local/nagios/libexec/check_logwarn), как в случае 1, ошибка журнала не обнаруживается в этом случае, неожиданно.

Ниже приведены мои наблюдения за содержимым внутреннего файла трекера, который генерирует nagios — /tmp/logwarn_hiphop_error/mnt_log_hiphop_error_20170320.log —

При обнаружении ошибки в случае 1, следующие изменения в файле —

Перед запуском команды

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

После запуска команды

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

Кроме того, ниже приведены изменения в том же файле в случае 2 —

Перед запуском php файла

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

После

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

Я не уверен, почему MATCHING Параметр true в случае 2, тогда как в случае 1 это false. На самом деле, сопоставление ошибок произошло в случае 1.

Обновить

Я попытался обернуть команду в escapeshellcmd, чтобы убедиться, что регулярное выражение не удаляется —

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

но все равно без изменений в выходе.

Обновление 2

Обнаружил, что у меня были разрывы строк в строке журнала, которую я добавлял вручную. Удаление исправлено последовательно для случая запуска PHP-файла из командной строки. Тем не менее, проблема по-прежнему воспроизводима последовательно для случая 2, где я запускаю проект через Jenkins, и этот файл вызывается в одной из ловушек развертывания кода AWS.

Ну, похоже, это не так легко решить. Проблема была исправлена ​​для ручного вызова файла PHP, но при вызове через Jenkins, я все еще получаю ту же проблему последовательно.