Кстати хорошая идея. Ведь они сами предупреждают, что стоит использовать только 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 <mdou...@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