AWS Elastic Beanstalk Спорадически не проверяет здоровье - PullRequest
Новая
       35

AWS Elastic Beanstalk Спорадически не проверяет здоровье

0 голосов
/ 23 мая 2018

кто-нибудь еще видел, что спорадические проверки работоспособности не выполнялись в их приложениях с эластичным beanstalk?

Я использую ELB для обслуживания API GraphQL.Я использую запуск конфигурации докера на одном экземпляре t2.micro с интервалом мониторинга, установленным на 1 минуту.Он настроен на масштабирование до 4 экземпляров при большой нагрузке.В хранилище данных используется Amazon RDS (PostgreSQL, не публично доступный, db.t2.micro).

Ниже приведены последние значения со страницы событий ELB: 

2018-05-23 08:24:11 UTC-0600    INFO
Environment health has transitioned from Severe to Ok.

2018-05-23 08:23:11 UTC-0600    WARN
Environment health has transitioned from Ok to Severe. None of the instances are sending data.

2018-05-21 06:28:13 UTC-0600    INFO
Environment health has transitioned from Severe to Ok.

2018-05-21 06:27:13 UTC-0600    WARN
Environment health has transitioned from Ok to Severe. 85.7 % of the requests are erroring with HTTP 4xx.

2018-05-18 14:10:51 UTC-0600    INFO
Environment health has transitioned from Severe to Ok.

Я иногда видел предупреждения HTTP 4XX с тех пор, как развернул свое приложение несколько месяцев назад.Я никогда не видел None of the instances are sending data предупреждение раньше.Я не вижу соответствующих ошибок 4XX в журналах приложений.

Не уверен, что это нормально, или что-то неправильно настроено.Amazon Compute объявляет об уровне SLA 99,99%, который указан в разделе «Обязательства по обслуживанию» здесь .Я должен ожидать увидеть время простоя в диапазоне:

  • Ежедневно: 8,6 с
  • Еженедельно: 1 м 0,5 с
  • Ежемесячно: 4 м 23,0 с
  • Ежегодно: 52 м 35,7 с

Я не вижу ошибок в своей внешней проверке работоспособности (я использую UptimeRobot, который опрашивает конечную точку работоспособности моего API каждые пять минут и ищет ключевое слово).Я не вижу ошибок в журналах приложений.

Если кто-то еще видел мерцающее состояние здоровья и нашел способ смягчить это (или хотя бы почему это происходит), я был бы признателен за некоторые советы.Спасибо за чтение!

Ответы [ 2 ]

0 голосов
/ 11 октября 2018

Несмотря на то, что Брайан правильно определил причину - я вижу это ежедневно из сканеров портов - и перечисляет некоторые разумные варианты, просто отмечая, что в Elastic Beanstalk теперь есть относительно новое правило, позволяющее игнорировать ошибки 4xx в качестве другой опции, для https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/health-enhanced-rules.html

Предостережение: вы можете пропустить ошибки 4xx из-за проблем конфигурации или ошибок приложения.

0 голосов
/ 23 мая 2018

Я часто видел сиюминутные сбои в экземплярах с низким трафиком, таких как среды тестирования.Каждый раз, когда я исследовал, ошибки 4XX были от сканера портов или некоторых других вредоносных запросов.Так как трафик на непроизводительных экземплярах низок, для запуска «85,7% запросов» не требуется много - например, это может быть всего шесть из семи запросов.

Вы можете увидетьошибки 4XX в ваших журналах ELB, если они не отображаются в журналах вашего приложения.Ведение журнала ELB по умолчанию отключено, но вы можете включить его и войти в систему на S3.

Самый простой подход - это ограничить доступ к вашему приложению, занеся белые IP-адреса в вашей группе безопасности.Однако если ваше приложение должно быть общедоступным, у вас есть несколько вариантов решения проблемы:

  1. Если запросы поступают с одного IP-адреса, вы можете заблокировать его с помощью ACLв вашем VPC.
  2. Если запросы поступают с нескольких IP-адресов, вы можете заблокировать их, если есть какой-либо непротиворечивый шаблон, например, к какому URI они пытаются получить доступ, связанный пользовательский агент,или т.п.Однако вам нужно включить WAF.
  3. Просто игнорируйте предупреждения - они, скорее всего, безвредны, и, как только у вас будет больше трафика, они будут сливаться с остальным шумом.
...