на этой неделе только что потратил два дня на устранение неполадок разработчика в EC2, зарегистрированный оффшорной командой.
без проблем запускали apache / tomcat версии 7.0.21 в нескольких экземплярах Dev в EC2 в течение нескольких недель.
затем основные проблемы с производительностью в D3 env. с первого раза без проблем повторно запустил сценарии на берегу.
снова зарегистрированные в офшоре дефекты в D3 env, на этот раз они запускали скрипты в клоне D2 без проблем. утром снова запускал скрипты в D3 на суше, и на этот раз возникли серьезные проблемы.
было ощущение, что это инфраструктура, но не было возможности доказать это.
настроенный контейнер сервлетов смотрит на сборку мусора, кучу, пул jdbc - в env песочницы, ничего плохого.
затем скрипты передаются в образе клона D3. все зарегистрированные дефекты пройдены. мы ничего не изменили.
это похоже на проблему с EC2 либо на виртуальных машинах Xen, либо в сети, либо на RDS. Понятия не имею, что это было.
Как можно изолировать неисправность в облаке, когда летишь вслепую? При отсутствии видимости инфраструктуры, с чего начать?
У кого-нибудь есть подобная проблема?
Можно ли контролировать инфраструктуру EC2?
Перри, похоже, вы правильно диагностировали проблему (ложное / случайное / неожиданное поведение на EC2 почти всегда является побочным эффектом деградированного оборудования хоста) - единственный способ подтвердить это - опубликовать сообщение на форумах EC2 или открыть заявку в службу поддержки и попросите их выяснить, в какой момент команда EC2 может подтвердить / опровергнуть неисправное оборудование.
Обходной путь, независимо от того, подтвердили вы это или нет, всегда должен выключить и перезапустить вашу виртуальную машину, что поместит ее на другое оборудование. (Вы можете регулярно видеть это на форумах EC2).
В будущем я сделал бы это ожидаемым первым шагом в устранении совершенно случайных проблем на EC2, чтобы сделать именно это; перезапустить экземпляр.
По-прежнему нет способа получать предупреждения в реальном времени о состоянии базового оборудования на EC2, даже несколько уведомлений по электронной почте, которые отправляются, когда оборудование выходит из строя, кажутся случайными, поскольку оборудование все еще может выйти из строя, и вы никогда не получите одно из этих электронных писем монитора .
Вы можете попробовать настроить службу мониторинга на свои отдельные экземпляры, такие как pingdom или wasitup, но это простые тесты ping, и я не знаю, подойдут ли они для вас.
В качестве альтернативы, если вы можете сузить сбои, которые вы видели, до определенных вещей, которые были случайными сбоями (например, определенная операция, которая идет глупо на EC2, когда оборудование начинает выходить из строя), вы можете написать системный скрипт / задание cron, которое просто запускает эту точную службу каждые 1мин или 10мин и сообщает об ошибке.
Это подход «канарейки в угольной шахте», в котором нет ничего научного или точного, но он может немного помочь и позволить вам обнаружить проблему до того, как это сделают пользователи.