<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Кстати хорошая идея. Ведь они сами предупреждают, что стоит использовать только CNAME при ссылке на ELB так как адреса могут поменяться. <br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default"><span style="font-family:monospace,monospace">Because the set of IP addresses associated with a LoadBalancer can 
change over time, you should never create an "A" record with any 
specific IP address. If you want to use a friendly DNS name for your 
load balancer instead of the name generated by the Elastic Load 
Balancing service, you should create a CNAME record for the LoadBalancer
 DNS name</span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"></div><div class="gmail_default" style="font-family:verdana,sans-serif">В случае с ELK стеком, думаю там тоже стоят балансировщики, судя по выводу<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default"><span style="font-family:monospace,monospace">$ host <a href="http://search-production.us-west-1.es.amazonaws.com">search-production.us-west-1.es.amazonaws.com</a><br><a href="http://search-production.us-west-1.es.amazonaws.com">search-production.us-west-1.es.amazonaws.com</a> has address 52.8.xxx.xxx<br><a href="http://search-production.us-west-1.es.amazonaws.com">search-production.us-west-1.es.amazonaws.com</a> has address 13.57.xxx.xxx</span></div><div class="gmail_default"><span style="font-family:monospace,monospace"><br></span></div><div class="gmail_default"><span style="font-family:monospace,monospace">$ host 52.8.xxx.xxx<br>xxx.xxx.8.52.in-addr.arpa domain name pointer <a href="http://ec2-52-8-xxx-xxx.us-west-1.compute.amazonaws.com">ec2-52-8-xxx-xxx.us-west-1.compute.amazonaws.com</a>.</span></div><div class="gmail_default"><span style="font-family:monospace,monospace"><br></span></div><div class="gmail_default"><span style="font-family:monospace,monospace">$ host 13.57.xxx.xxx<br>xxx.xxx.57.13.in-addr.arpa domain name pointer <a href="http://ec2-13-57-xxx-xxx.us-west-1.compute.amazonaws.com">ec2-13-57-xxx-xxx.us-west-1.compute.amazonaws.com</a>.<br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"></div><div class="gmail_default" style="font-family:verdana,sans-serif">В моем случае получается, что nginx при старте отрезолвил имя <a href="http://search-production.us-west-1.es.amazonaws.com">search-production.us-west-1.es.amazonaws.com</a> в одну пару ip адресов, а со временем они поменялись. И скорее всего я и получил эту ошибку. Отслеживать в ручную и делать reload это конечно не вариант. А как вообще стоит тогда настраивать nginx, если он стоит перед амазоновским elb, чтобы избежать подобных проблем в будущем?</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-12-08 16:23 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 Fri, Dec 08, 2017 at 04:11:19PM +0200, Alex Domoradov wrote:<br>
<br>
> Да, это я знаю. Тогда у меня возникает вопрос<br>
><br>
> Скорее всего ошибка  host not found in upstream "<br>
> <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>
> действительно была вызвана попыткой сделать reload/restart. Но раз nginx<br>
> работал, значит restart не производился. Возможно действительно был reload.<br>
> Но он бы не применился по причине ошибки резолвинга. Сам домен был удален<br>
> примерно за 10 дней, до обнаружения самой ошибки, т.е. момент когда<br>
> перестал открываться ELK(кибана)<br>
><br>
> Больше никаких ошибок в error.log не было. Тогда не понятно, почему<br>
> перестало работать проксирование из корневого локейшена, а возвращалась 504<br>
> ошибка? У меня к сожалению не удалось воспроизвести это поведение<br>
<br>
</span>Если 504 возвращал именно nginx, а не какой-нибудь ELB перед ним,<br>
то a) очевидно, что nginx был запущен и работал, и б) проблема<br>
была в том, что он не мог добраться до конкретного бэкенда.<br>
Почему не мог - отдельный вопрос.<br>
<br>
Например, такое могло случиться из-за того, что IP-адреса бэкендов<br>
поменялись, а reload nginx'у, чтобы он подобрал эти изменившиеся<br>
IP-адреса, никто не сказал.  В результате nginx продолжал ходить<br>
на старые адреса, где ему не отвечали.  В логах будут подробности<br>
на уровне error, включая IP-адреса, куда nginx пытался ходить.<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>