Кстати хорошая идея. Ведь они сами предупреждают, что стоит использовать
только CNAME при ссылке на ELB так как адреса могут поменяться.

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

В случае с ELK стеком, думаю там тоже стоят балансировщики, судя по выводу

$ host search-production.us-west-1.es.amazonaws.com
search-production.us-west-1.es.amazonaws.com has address 52.8.xxx.xxx
search-production.us-west-1.es.amazonaws.com has address 13.57.xxx.xxx

$ host 52.8.xxx.xxx
xxx.xxx.8.52.in-addr.arpa domain name pointer
ec2-52-8-xxx-xxx.us-west-1.compute.amazonaws.com.

$ host 13.57.xxx.xxx
xxx.xxx.57.13.in-addr.arpa domain name pointer
ec2-13-57-xxx-xxx.us-west-1.compute.amazonaws.com.

В моем случае получается, что nginx при старте отрезолвил имя
search-production.us-west-1.es.amazonaws.com в одну пару ip адресов, а со
временем они поменялись. И скорее всего я и получил эту ошибку. Отслеживать
в ручную и делать reload это конечно не вариант. А как вообще стоит тогда
настраивать nginx, если он стоит перед амазоновским elb, чтобы избежать
подобных проблем в будущем?

2017-12-08 16:23 GMT+02:00 Maxim Dounin <mdounin@mdounin.ru>:

> Hello!
>
> On Fri, Dec 08, 2017 at 04:11:19PM +0200, Alex Domoradov wrote:
>
> > Да, это я знаю. Тогда у меня возникает вопрос
> >
> > Скорее всего ошибка host not found in upstream "
> > search-testing.us-west-1.es.amazonaws.com" in
> /etc/nginx/conf.d/elk.conf:46
> > действительно была вызвана попыткой сделать reload/restart. Но раз nginx
> > работал, значит restart не производился. Возможно действительно был
> reload.
> > Но он бы не применился по причине ошибки резолвинга. Сам домен был удален
> > примерно за 10 дней, до обнаружения самой ошибки, т.е. момент когда
> > перестал открываться ELK(кибана)
> >
> > Больше никаких ошибок в error.log не было. Тогда не понятно, почему
> > перестало работать проксирование из корневого локейшена, а возвращалась
> 504
> > ошибка? У меня к сожалению не удалось воспроизвести это поведение
>
> Если 504 возвращал именно nginx, а не какой-нибудь ELB перед ним,
> то a) очевидно, что nginx был запущен и работал, и б) проблема
> была в том, что он не мог добраться до конкретного бэкенда.
> Почему не мог - отдельный вопрос.
>
> Например, такое могло случиться из-за того, что IP-адреса бэкендов
> поменялись, а reload nginx'у, чтобы он подобрал эти изменившиеся
> IP-адреса, никто не сказал. В результате nginx продолжал ходить
> на старые адреса, где ему не отвечали. В логах будут подробности
> на уровне error, включая IP-адреса, куда nginx пытался ходить.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru