Катастрофическое отключение Azure App Service после автоматического обновления платформы Azure
Относительно простая служба приложений Azure (в настоящее время .net 4.6.2, на базе Azure SQL) работает уже более 18 месяцев. Она очень надежна. Я редко вспоминаю об этом сайте и не выпускал обновлений в течение нескольких месяцев.
Проснувшись сегодня утром, я обнаружил электронные письма от клиентов, в которых говорилось, что сайт сообщает: "Указанное CGI-приложение столкнулось с ошибкой, и сервер завершил процесс". В качестве первого предположения я нажал "Перезапустить" на портале Azure против службы приложений. Примерно через минуту она ожила и с тех пор работает нормально.
Я перешел в раздел "Диагностика и решение проблем" -> "Доступность и производительность". Временная шкала "Запросы и ошибки" показала момент, когда веб-сайт упал и когда он вернулся к жизни. Я углубился во временную шкалу и выбрал "Полный отчет".
В очень спокойной форме он сообщил следующее
Обнаружены события остановки приложения Мы проанализировали 3 события платформы, 1 Пользовательское событие.
Платформа (обновление файлового сервера) Ваше приложение было остановлено из-за обновления файлового сервера. Это событие произошло несколько раз в течение дня на нескольких экземплярах. Эти события вызывают перемещение тома хранилища перемещение, что может привести к перезапуску вашего приложения. Если это событие перезапуска негативно влияет на доступность приложения, включение функции локального кэша может помочь уменьшить зависимость от хранилища файловых серверов в определенной степени. Узнайте больше: Проверка локального кэша описана в разделе Устранение неполадок и дальнейшие шаги.
Платформа (обновление инфраструктуры) Около 11/20/2019 2:09:57 PM (UTC), на инстанции xxxxxxxx, ваше приложение было переработано, поскольку подразделение масштабирования Azure проходило обновление. Периодически Microsoft производит обновления Microsoft для базовой платформы Azure, чтобы улучшить общую надежность, производительность и безопасность инфраструктуры платформы. на которой работает ваше приложение. Большинство этих обновлений выполняются без какого-либо воздействия на ваше веб-приложение. Чтобы уменьшить влияние таких событий на ваше приложение, рассмотрите возможность развертывания вашего приложение в нескольких регионах и используйте Azure Traffic Manager для распределения нагрузки между регионами.
Пользователь(Остановить сайт) Около 11/20/2019 г. 9:00:00 PM (UTC), процесс вашего приложения был перезапущен из-за пользовательского действия, например остановки сайта с портала azure.
Я в полной растерянности, что делать и как предотвратить повторение этого.
Я подозреваю, что предложение о "локальном кэше" - красная селедка. Я использую файловую систему для создания нескольких временных файлов, которые код потом удаляет.
Гугление дало мало результатов.
Я думаю, что мне нужны предложения о том, что я могу сделать, чтобы это никогда не повторилось.
Есть идеи?
Заранее спасибо.
В моем случае настройка WEBSITE_LOCAL_CACHE_OPTION на Всегда не сработала.
Вместо этого установка WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG на 1 наконец помогла.
Недавно мы столкнулись с похожей, но немного другой проблемой. В некоторых случаях после обновления приложение будет работать медленно или не будет отвечать на запросы.
В конце концов, после многих часов устранения неполадок с MS, мы сузили это до некоторых непоследовательных случаев, которые вызывали проблемы с анализом приложений (Java springboot).
getCanonicalName работал по-разному на этих экземплярах и вместо возврата IP-адреса возвращал что-то другое. Нам пришлось изменить настройки Catalina, чтобы смягчить это. Исправление, кажется, находится в последнем пакете SDK для анализа приложений.
У меня было что-то похожее (в моем случае, однако веб-приложение не запустилось из-за переполнения временного хранилища), и я вставил сюда ответ, полученный от инженера службы поддержки Microsoft, чтобы избежать проблемы в будущее.
На этом экземпляре произошла перезагрузка файлового сервера хранилища, и приложение не могло запуститься после того, как вы сделали ручной перезапуск, веб-приложение застряло, чтобы решить эту проблему, которой вы можете придерживаться лучше всего практики
Используйте 2 экземпляра все время Эти экземпляры находятся в разные домены обновления и, следовательно, не будут обновлены одновременно время. В то время как один рабочий экземпляр обновляется, другой все еще активен для обслуживания веб-запросов. Веб-приложение в настоящее время настроено на работать только на одном экземпляре. Поскольку у вас есть только один экземпляр, вы можете ожидать простоя, так как при обновлении платформы службы приложений экземпляр, на котором работает ваше веб-приложение, будет обновлен. Следовательно, процесс вашего веб-приложения будет перезапущен и будет отключен.
Использовать проверку работоспособности Эта функция автоматически удаляет экземпляр из ротации, тем самым повышая доступность. Эта функция будет пропинговать указанный путь проверки работоспособности на всех экземплярах вашего веб-приложения каждые 2 минуты. Если экземпляр не отвечает в течение 10 минут (5 pings), экземпляр определен как неработоспособный, и наша служба прекратит маршрутизацию запросов к нему. Настоятельно рекомендуется для производственных приложений, чтобы использовать эту функцию и свести к минимуму любые потенциальные время простоя, вызванное неисправным экземпляром. Примечание. Функция проверки работоспособности работает только для приложений, размещенных более чем в одном экземпляре.Для получения дополнительной информации проверьте документацию ниже. https://github.com/projectkudu/kudu/wiki/Health-Check-(Preview)
Статья о передовом опыте
https://azure.github.io/AppService/2020/05/ 15/Надежные-приложения-для-облака.html