Игнорирование ложного предупреждения, выдаваемого журналом ошибок сервера сразу после автоматического развертывания

Мы настроили конвейер автоматического развертывания на сервере Nginx, работающем под управлением Hiphop PHP, с использованием развертывания кода AWS, запущенного Jenkins.

В настоящее время сталкивается с проблемой, при которой во время развертывания некоторых основных файлов запросы к серверу, похоже, ставятся в очередь, а затем, когда система начинает восстанавливаться, возникают задержки в обработке запросов, и некоторые из них получают тайм-аут (что хорошо) и мы хотели бы игнорировать это. Однако это регистрирует фатальные ошибки в файле журнала ошибок хип-хопа, и поскольку наша логика проверки исправности после развертывания ищет слово «Fatal», она перехватывает то же самое и отмечает общий сбой развертывания —

2017-03-08 11:25:17 - Error found -> [Wed Mar  8 11: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
we can ignore this error on Hiphop Error Check Status (edited)

Однако мы не хотели бы игнорировать любую допустимую ошибку, вызванную развертыванием, приводящим к задержке в обработке запросов. Мы предполагаем, что в этом случае ошибки будут продолжать появляться и не исчезнут, в отличие от того, что мы наблюдали, с ложными предупреждениями.

До сих пор мы вводили задержку между этапом установки (где изменения файлов фактически выполняются на производственных серверах) и этапом после установки (где выполняются проверки работоспособности), однако, похоже, что задержка была выбрана нами. пока что не достаточно. Теперь проблема в том, что, если задержка будет увеличена еще больше, это увеличит общее время развертывания, так как у нас есть несколько пакетов (каждая развертывается на нескольких производственных серверах). Мы еще недостаточно изучили тенденцию этих ошибок.

Мы думали о возможности отображения количества раз, когда происходит задержка по времени, и исходя из этого, человек, выполняющий развертывание, может определить успех. Однако нам необходимо выяснить, имеет ли используемая нами утилита nagios logwarn такую ​​же возможность. В настоящее время мы используем его, чтобы поддерживать указатель на каждый файл журнала, соответствующий последнему времени, когда была выполнена проверка, и в следующий раз, когда он сканирует этот указатель и далее.