У меня есть балансировщик нагрузки приложений AWS, настроенный с EC2 и группой автоматического масштабирования. Экземпляры EC2 работают под управлением веб-сервера Windows+IIS. Веб-сервер подключается к базе данных.
В некоторых ситуациях (раз в 2 месяца) случалось, что проверка работоспособности для ALB начинала определять приложение как неработоспособное и отключать инстансы EC2. Всегда запущено как минимум 2 экземпляра, и это происходит для всех экземпляров одновременно.Я пытаюсь понять, почему это происходит, и я не могу найти какие-либо полезные журналы или указания на то, откуда это происходит.
Посмотрите, как количество экземпляров внезапно падает до нуля 6 декабря:

Увеличение:

Экземпляры EC2 завершаются как:

Проверка работоспособности настроена на проверку связи со страницей, которая нет запрашивать базу данных, поэтому узкое место в базе данных не кажется вероятной причиной.
Когда это происходит, время отклика резко возрастает:

А также по измерениям NewRelic:

Обратите внимание на несколько вещей:
- все фазы ответа медленнее (время Redis, время .NET и т. д.)
- бывает, что все серверы работают в одно и то же время, так что вряд ли проблема внутри сервера
- это всегда происходило в нерабочее время, когда нагрузка низкая
Конфигурации автоматического масштабирования:
Минимальная вместимость=2
Максимальная вместимость=15
Распределение экземпляров = 50 % по запросу, 50 % спот
Включить базовую емкость по требованию = Назначить первый 1 экземпляр как по требованию.
Стратегия распределения по запросу = приоритетная
Стратегия распределения спотов = Самая низкая цена — диверсификация по 10 пулам с самой низкой ценой
Перебалансировка емкости=Выкл.
Защита экземпляра от масштабирования = Не защищено от масштабирования
Политики прекращения = По умолчанию
Время восстановления по умолчанию = 300
Конфигурации целевой группы:
Протокол=HTTPS
Путь=/путь/к/логину/странице
Порт = Транспортный порт
Порог работоспособности = 2 последовательных успешных проверки работоспособности
Порог неработоспособности = 4 последовательных сбоя проверки работоспособности
Таймаут=20 секунд
Интервал=25 секунд
Коды успеха = 200