2016-10-03 3 views
2

У меня проблема, что время от времени один из экземпляров EC2 в моем кластере отключил свой ECS-агент. Это молча удаляет экземпляр EC2 из кластера (т. Е. Не имеет права запускать какие-либо службы) и бесшумно сбрасывает мой кластер с обслуживающих серверов. У меня есть кластер, поддерживаемый группой автомасштабирования, нерестилищами серверов, чтобы поддерживать здоровое количество. Но серверы, связанные с ECS-агентом, не отмечены как нездоровые, поэтому группа AS считает, что все в порядке.Что делать, если ECS-агент отключен?

У меня такое ощущение, что для смягчения этого должно быть что-то (легкое), или у меня большая проблема с выбором ECS и его использованием в производстве.

+1

Вы используете новейший ECS AMI? У меня была аналогичная проблема несколько месяцев назад, которая была исправлена ​​с помощью обновлений Docker/ECS. – mcheshier

ответ

2

У нас была эта проблема в течение длительного времени. С каждым новым AMI-оптимизированным AMI улучшилось, но по состоянию на 3 месяца назад это все еще случалось время от времени. Как mcheshier упоминалось убедитесь, что всегда использовать последнюю AMI или, по крайней мере, последних AWS Écs агенту

Единственный способ, которым мы были в состоянии решить это через:

  1. таймерных AutoScale поворотами
    1. Мы будет пытаться предотвратить его путем масштабирования вверх и вниз в случайные моменты времени
  2. Хорошие предупреждениями cloudwatch
    1. У нас получилось, что наше приложение настроено как группа микросервисов, на которых базируется вся очередь (SQS). Мы могли масштабироваться вверх и вниз на основе очередей. У нас был достойный мониторинг, который позволяет приблизиться к темпам очередей по количеству контейнеров ECS. Когда мы обнаружили, что ставка была выключена, мы будем вращать весь ECS-экземпляр. То есть. Скажем, в нашем кластере развернуты 4 запущенных контейнера worker-1. Мы приближаем, что каждый работник делает 1000 сообщений в течение 5 минут. Если бы наша ставка была 3000 в течение 5 минут, у нас было 4 работника, тогда 1 не работал должным образом. У нас было несколько скриптов, установленных в лямбда, чтобы найти неисправный и завершить весь экземпляр, который запускал этот контейнер.

Я надеюсь, что это помогает, я понимаю, что это специфичные для нашей собственной заявки, но совет, который я могу дать вам, и кто-либо другой, чтобы взять на себя инициативу и поставить столько показателей там, как вы можете , Это позволит вам сделать аккуратную аналитику и искать изломы в системе, это один из них.

+2

Замена экземпляров на последние усовершенствованные AMI с оптимизацией ECS исправила его до сих пор, но все же я получаю кошмары от идеи, что AWS не помещает свои экземпляры как ошибочные, когда ecs-agent отключен. : s – Pepster

+0

Они отрицают, что он существует, и никто не имел твердого доказательства, чтобы показать, что вызывает его, поскольку оно противоречиво. Однако эмпирическое правило заключается в том, что ** всегда ** использует последний aws linux AMI. Если у вас есть возможность, я бы написал что-то, что уведомляет вас по электронной почте/slack/однако, когда новый будет выпущен, чтобы вы могли соответственно обновить –