Извините, это не короткий вопрос:
Фон
У меня есть веб-сайт B1 Azure, и я не могу получить исключения с помощью стека вызовов.
WebAPI размещается рядом с веб-сайтом в том же решении, что, как я слышал, необычно. Я полагаю, что почти все настройки были выполнены с помощью решения. Большинство всего на портале, вероятно, настройки по умолчанию с нового сайта.
Я признаю первым, я новичок в Azure. Ранее в прошлом я размещал несколько исключительно простых веб-сайтов ASP (в основном до .NET). Я обнаружил, что портал Azure перегружен, если не сказать больше. Следовательно, почему я здесь!
Основное место, где я ищу исключения, находится в Application Insights, на вкладке «Сбои», однако. Хотя обычно (не всегда ...) показывают, что были 500-е, в подавляющем большинстве случаев не будет стека вызовов.
Ситуации
Несколько раз он ловит стек вызовов, это ваши обычные боты, высовывающие случайные каталоги ... не исключение, которое мне нужно немедленно отладить. Я помню, что слышал, что Azure будет использовать «ИИ для определения того, какие стеки вызовов следует сохранить» или что-то подобное, но я не могу найти какие-либо настройки, касающиеся этого. Даже если эта рыночная речь верна, почему она записывает стеки вызовов для ежедневных попыток ботов, но является редким исключением, наносящим ущерб приложениям?
Примерно месяц назад я пытался отладить работающий веб-сайт через Visual Studio, но я получаю сообщение об ошибке, в котором говорится, что Internet Explorer не может быть найден. Учитывая, что это 2018 год, и Microsoft перешла на Edge, я не знаю, зачем вообще нужен Internet Explorer. Я нашел ответ на это, сказав взломать реестр и переустановить Internet Explorer, но в то время это казалось излишним.
Просмотр ошибок Azure через встроенный в Visual Studio портал Azure, похоже, показывает очень похожие данные, как и портал Azure. Столы вызовов не найдены.
Много лет назад было установлено классическое оповещение об ошибках Http-сервера, которое срабатывает и по сей день. Он не срабатывает при исключениях HttpException от ботов, ковыряющихся на сайте, но для важных 500, и это хорошо. Что интересно, это самый надежный способ услышать об ошибках, помимо пользовательских отчетов. Жаль, что у них нет стека вызовов ...
Прошлой ночью мы столкнулись с исключением, предположительно в представлении, страницы. Как и ожидалось, мы получили электронные письма из классического оповещения, но в разделе «Сбои» вообще не отображается никаких сбоев. В прошлом мы видели 500-е, но не было стека вызовов. Казалось бы, ошибки прошлой ночи не были обнаружены ничем, кроме классического предупреждения и пользователя. Я не знаю, было ли это потому, что ошибка прошлой ночи была уникальной, или теперь мы таинственным образом получаем еще меньше информации из Azure.
Попытка решения
В течение многих лет я следовал бесчисленному количеству руководств, от переключения переключателей на самом портале до FTP и просмотра необработанных журналов (которые, очевидно, на самом деле не относятся к вашему приложению, а скорее к тому, как его размещает Microsoft). Если бы я получал пенни за каждый раз, когда я читал руководство, которое гласило: «Просто нажмите на вкладку« Исключения », чтобы увидеть ваши стеки вызовов», я был бы богат: -P.
Месяц назад я так отчаялся, что реализовал Application_Error в классе HttpApplication для приложения и реализовал ExceptionLogger для WebAPI, чтобы вручную регистрировать все исключения в текстовых файлах. К сожалению, хотя это помогло мне исправить одну ошибку, последующих исключений там тоже не появилось. Как и в Application Insights, в этих журналах в основном отображаются боты, копающиеся в несуществующих каталогах.
Неделю назад я настолько отчаялся, что написал дрянное «модульное тестирование» (ха!), Которое потянуло бы копию производственных данных и проверило бы ее локально, что абсолютно безумно.
Я говорил с другими инженерами ASP.NET уровня архитектора, которые используют портал Azure с разными частотами, и они не могли прийти ни к каким предложениям. Мы посмотрели на web.configs; есть в корне и в папке Views. Мы играли с включением пользовательских ошибок, но, очевидно, мы не можем запустить их в работе, потому что они будут отображать ошибки для пользователя. При этом я бы не отказался от появления реальных сообщений об ошибках для определенных пользователей. Как можно это сделать? Если бы я догадался, проблема скрыта в этих web.configs просто потому, что они древние и их коснулось так много рук.
Заключение
Мне нужен 100% -ный пуленепробиваемый способ получения исключений и их стеков вызовов из ASP.NET, размещенного в Azure. В противном случае практически невозможно решить крайние случаи, которые неожиданно появляются в производстве. Я не помню, чтобы это было проблемой в мои дни до Azure.
Я уверен, что специалист там решит это за считанные минуты, но сейчас я совершенно ошеломлен. Спасибо за ваше время!