Существует кластер Elasti c Container Service, в котором выполняется приложение, внутренне именуемое Deltaload. Он проверяет данные в производственной базе данных Oracle и в базе данных разработчиков в Amazon RDS и загружает все, что отсутствует, в RDS. Правило CloudWatch настроено для запуска этого процесса каждый час.
Сейчас почему-то каждые 20-30 часов идет один интервал разной длины. Обычно это ~ 25 минут перерыва, но в других случаях он может составлять 80-90 минут вместо 60. Я мог понять разницу в 1-2 минуты, но отключение на 30 минут от почасового расписания звучит действительно проблематично c, особенно с учетом того, что полный пробег занимает ~ 45 мин. Есть ли у кого-нибудь идеи, что может быть причиной этого? Или, по крайней мере, как я могу понять, почему это так?
Интересно то, что этот сбой в расписании либо ломает, либо исправляет приложение Deltaload. Я имею в виду, что если он успешно работает каждый час в течение всего дня, а затем наступает 20-минутный интервал, он будет вылетать каждый час в течение следующего дня, пока не появится следующий сбой, после чего он снова будет работать (тот самый тот же процесс, тот же контейнер, все то же самое). Вылетает из-за истечения времени ожидания подключения к RDS. Этот «день аварий, день пробежек» продолжается с начала февраля. Я не слишком разбираюсь в AWS. Это приложение Deltaload написано на C#, чего я не знаю. Единственное, что мне удалось сделать, это увеличить таймаут RDS-соединения до 10 минут, что не устранило проблему. Парень, написавший приложение, ушел из компании на время go и недоступен. Других разработчиков в этом проекте нет, все были уволены из-за короны. Пока что лучшая альтернатива, которую я вижу, - это просто переписать все это в Python (что я знаю). Если у кого-то есть другие мысли о том, как это понять / исправить, я буду очень признателен за любой вклад.
Повторяю свой настоящий вопрос: почему правило CloudWatch сбрасывается с нерегулярными интервалами в обычном расписании? Как этого не допустить?