<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Да, это я знаю. Тогда у меня возникает вопрос</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Скорее всего ошибка <span class="gmail-im"> host not found in upstream "<a href="http://search-testing.us-west-1.es.amazonaws.com" rel="noreferrer" target="_blank">search-testing.us-west-1.es.<wbr>amazonaws.com</a>" in /etc/nginx/conf.d/elk.conf:46 действительно была вызвана попыткой сделать reload/restart. Но раз nginx работал, значит restart не производился. Возможно действительно был reload. Но он бы не применился по причине ошибки резолвинга. Сам домен был удален примерно за 10 дней, до обнаружения самой ошибки, т.е. момент когда перестал открываться ELK(кибана)<br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="gmail-im"><br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="gmail-im">Больше никаких ошибок в error.log не было. Тогда не понятно, почему перестало работать проксирование из корневого локейшена, а возвращалась 504 ошибка? У меня к сожалению не удалось воспроизвести это поведение<br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="gmail-im"><br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br><span class="gmail-im">> зачастую всякие скрипты вращения логов и тому подобного - делают не просто странное (скажем, HUP, то есть configuration reload,<br>
  вместо USR1), а очень странное, вплоть до restart'а или даже  просто остановки сервера без попыток его запустить обратно.</span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="gmail-im"><br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="gmail-im">Я глянул, логротейт выглядит вот так<br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="gmail-im"><br></span></div><div class="gmail_default"><span style="font-family:monospace,monospace"><span class="gmail-im"># rpm -ql nginx | grep logrotate | xargs cat<br>/var/log/nginx/*log {<br>    create 0644 nginx nginx<br>    daily<br>    rotate 10<br>    missingok<br>    notifempty<br>    compress<br>    sharedscripts<br>    postrotate<br>        /etc/init.d/nginx reopen_logs<br>    endscript<br>}<br></span></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="gmail-im"><br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="gmail-im">сама функция выглядит вот так</span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="gmail-im"><br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="gmail-im"><span style="font-family:monospace,monospace">reopen_logs() {<br>    configtest_q || return 6<br>    echo -n $"Reopening $prog logs: "<br>    killproc -p $pidfile $prog -USR1<br>    retval=$?<br>    echo<br>    return $retval<br>}</span><br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="gmail-im"><br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span class="gmail-im">Вроде как ничего необычного<br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-12-08 15:36 GMT+02:00 Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Thu, Dec 07, 2017 at 05:11:13PM +0200, Alex Domoradov wrote:<br>
<br>
> В том то и дело, что никто ни reload ни restart не делал. nginx работал с<br>
> 7го ноября без каких либо вмешательств. И перестал сегодня утром. Попробую<br>
> уточнить, когда был удален апстрим в локейшене test<br>
<br>
</span>Процитированное сообщение об ошибке:<br>
<span class=""><br>
> > > 2017/12/07 03:21:01 [emerg] 16478#0: host not found in upstream "<a href="http://search-testing.us-west-1.es.amazonaws.com" rel="noreferrer" target="_blank">search-testing.us-west-1.es.<wbr>amazonaws.com</a>" in /etc/nginx/conf.d/elk.conf:46<br>
<br>
</span>чётко и однозначно говорит о том, что nginx парсил конфигурацию и<br>
в процессе произошла ошибка.  Сам по себе nginx подобным в<br>
процессе работы не занимается - его тем или иным способом об этом<br>
попросили.<br>
<br>
Как именно и кто попросил - это уже, боюсь, разбираться вам.<br>
Чтобы было проще - стоит включить логгирование как минимум на<br>
уровне notice, там, в частности, логгируются все полученные<br>
nginx'ом сигналы (а начиная с 1.13.0 ещё и указывается PID<br>
отправившего сигнал процесса, но у вас версия старее).<br>
<br>
Отмечу также, что:<br>
<br>
- на линуксах часто в процессе обновления пакетов практикуется<br>
  restart сервиса.  Если пакет для nginx'а сделан криво и не умеет<br>
  делать upgrade - то обновление пакетов может быть причиной<br>
  restart'а и всех сопутствующих проблем.<br>
<br>
- зачастую всякие скрипты вращения логов и тому подобного - делают<br>
  не просто странное (скажем, HUP, то есть configuration reload,<br>
  вместо USR1), а очень странное, вплоть до restart'а или даже<br>
  просто остановки сервера без попыток его запустить обратно.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
______________________________<wbr>_________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-ru</a></div></div></blockquote></div><br></div>