Amazon ELB не может служить ответом

Question

У меня есть веб-сайт, работающий на веб-сервисах Amazon, который развертывается с использованием Elastic Beanstalk и работает на одном экземпляре EC2 micro. Это промежуточная среда, и я единственный, у кого есть доступ к ней. Используя Apache JMeter, я имитирую шесть пользователей, перемещающихся по веб-сайту, в среднем по запросу каждые 3 секунды (изображения, CSS, JS и другие статические ресурсы обслуживаются CloudFront и не делают трафик на экземпляр EC2).

Проблема заключается в том, что через некоторое время (обычно 30-60 минут после установки среды) веб-сайт перестает отвечать на запросы. Я уверен, что Tomcat все еще работает правильно, так как я вижу в журнале (catalina.out), что cronjobs все еще выполняется. Кажется, что только ELB не может служить ответом.

При анализе журналов на Tomcat отсутствуют ошибки (нет в /opt/tomcat7/logs/tail_catalina.log или /opt/tomcat7/logs/catalina.out). Следующие ошибки начинают появляться на/и т.д./HTTPD/журналы/elasticbeanstalk-error_log как только сайт становится недоступным:

[Thu Jun 14 20:26:42 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:26:42 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:26:50 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:26:50 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:27:20 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:27:20 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:27:43 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:27:43 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:27:50 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:27:50 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:28:20 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:28:20 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:28:42 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:28:42 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:28:50 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:28:50 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:29:20 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:29:20 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:29:42 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:29:42 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:29:50 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:29:50 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:30:20 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:30:20 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:30:43 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:30:43 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:30:50 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:30:50 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:31:20 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:31:20 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:31:43 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:31:43 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:31:50 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:31:50 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 
[Thu Jun 14 20:32:20 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:32:20 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 

... пока экземпляр EC2 не получает, наконец, завершается (и новый автоматически запускается) ,

Эта проблема не возникает, если я не делаю никаких запросов (или если я делаю меньше).

Любая помощь очень ценится.

Спасибо!

Answer 1

Позвольте мне начать с предположения:

• Ваше приложение Tomcat должен быть прослушивает 127.0.0.1:8999

Если это правда, то в журнале событий:

[Thu Jun 14 20:26:42 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:26:42 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 

.. отпустите, что слушатель приложения умер. Вы можете подтвердить это с:

curl -v http://127.0.0.1:8999/ 

Это curl команда должна возвращать правильный ответ HTTP, когда сайт работает нормально, и, вероятно, возвращать Connection refused или couldn't connect to host, когда вы испытываете отключения. Кроме того, можно использовать следующую команду для проверки действительного слушателя на порт приложения:

netstat -an | grep LISTEN | grep 8999 

Есть целый ряд причин, почему слушатель приложения может умереть, в том числе, но не ограничиваясь ими:

• жесткий крах виртуальной машины Java (использование ps, чтобы увидеть, если процесс JVM все еще работает)
• мягкий сбой приложения (смотрите на журналы приложений Tomcat)
• Запуск из дескрипторов файлов (используйте lsof | wc -l в d сравните ulimit -n пользователя приложения)

Тем не менее, большинство ошибок должны привести к сообщению об ошибке записываются в процессе виртуальной машины Java-х stderr, который обычно регистрируется. Это лучшее место для просмотра.Если все остальное не удается, вы можете попробовать запустить приложение Tomcat на переднем плане с включенным протоколом отладки.

Answer 2

Я только что провел день, сражаясь с аналогичной проблемой с этим. У меня есть файл WAR, развернутый в среде Amazon Elastic Beanstalk. Разница со мной заключалась в том, что экземпляр, созданный средой AEBS, длился всего 5 минут, прежде чем он был прерван и заменен новым экземпляром AEBS.

После довольно много рыть (в 5 минут куски, а мой экземпляр был еще жив), и некоторые light reading я обнаружил, что экземпляры AEBS Tomcat создаются с помощью Apache получает запросы на порт 80. Просьбы о /_hostmanager повторно направляется порт 8999 и все остальное порт 8080 (Tomcat). Приложение Ruby, называемое «hostmanager», развернутое в экземпляре, прослушивает порт 8999. Это приложение, по-видимому, сообщает об этом администратору узла AWAS Elastic Beanstalk с трафиком & другой статистикой, чтобы позволить среде Elastic Beanstalk получить изображение нагрузки на окружающую среду и увеличьте или уменьшите количество экземпляров соответствующим образом.

Если AWS Elastic Beanstalk Host Manager не получает ответа от приложения-хозяина экземпляра, он завершает экземпляр и запускает новый. Возможно, поэтому ваш сайт длится 30 минут, а затем умирает.

Так что я думаю, что проблема здесь заключается не в приложение Java, обслуживаемых на порт 8080, но с приложением hostmanager не прослушивает порт 8999. Это, вероятно, что является причиной:

[Thu Jun 14 20:26:42 2012] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8999 (localhost) failed 
[Thu Jun 14 20:26:42 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) 

Заканчивать /opt/elasticbeanstalk/var/log/hostmanager.log поскольку это может дать вам больше информации о том, что происходит, и почему приложение hostmanager недовольство.

В моем случае оказалось, что мое приложение-хозяин запускало wget в ведро Amazon S3 Storage и получало ответ 404 (я нашел это, посмотрев на hostmanager.log, упомянутый выше). Это заставило hostmanager не запускать. Следовательно, когда входящий запрос был перенаправлен на порт 8999, ничего не слушало. Потерпеть неудачу. Экземпляр завершен.

Вместо того, чтобы пытаться выяснить, почему приложение хост-менеджера оказалось неудачным, я решил обработать AMI, используемый средой Elastic Beanstalk как потерянное дело. Я в конечном итоге отказаться от его и следуя следующие шаги, чтобы получить новую среду Elastic Beanstalk убегал пользовательский AMI:

1. Создать новую Elastic Beanstalk среды с моей WAR файл
2. создал AMI из экземпляра, который был созданный им
3. создал обычный экземпляр EC2 от AMI, созданный на шаге 2
4. Добавлено несколько дополнительных битов, которые мне нужно было (Tomcat менеджер, например)
5. создал AMI из обычного экземпляра, созданного на шаге 3
6. Применяется, что AMI к среде эластичного бобового стебля

Не зная точно, что именно вы настроили, это немного сложно помочь точно. Хотя, надеюсь, сочетание знания о том, что hostmanager слушает порт 8999, местоположение hostmanager.log и некоторая удача доставят вас туда, где вы хотите быть!