Azure 门户：如何查看调用堆栈

Posted 2023-04-13

【中文标题】Azure 门户：如何查看调用堆栈

【英文标题】：Azure Portal: How to See Callstacks

【发布时间】：2019-04-06 19:04:34

【问题描述】：

抱歉，这不是一个简短的问题：

背景

我有一个 B1 Azure 网站，在我的一生中，调用堆栈无法获得异常。

WebAPI 与网站在同一个解决方案中并排托管，我听说这很不寻常。我相信几乎所有的配置都是通过解决方案完成的。门户中的大多数内容可能都是来自全新站点的默认设置。

我会第一个承认，我是 Azure 的新手。我以前曾托管过一些非常简单的 ASP 网站（主要是 .NET 之前的网站）。至少可以说，我发现 Azure 门户网站是压倒性的。这就是为什么我在这里！

但是，我在 Application Insights 中查找异常的主要位置是“失败”、“异常”选项卡。虽然它通常（并非总是......）显示有 500 个，但在绝大多数情况下，它不会显示调用堆栈。

情况

它确实捕获了调用堆栈的几次，这是您的普通机器人在随机目录中戳...而不是我需要立即调试的严重异常。我记得听说 Azure 将使用“AI 来确定要保留哪些调用堆栈”或类似市场的东西，但我找不到任何有关它的设置。即使这种市场说法是正确的，为什么它会记录每日机器人尝试的调用堆栈，但却是罕见的应用程序瘫痪异常？

大约一个月前，我尝试通过 Visual Studio 调试实时网站，但我收到一条错误消息，提示找不到 Internet Explorer。鉴于现在是 2018 年，微软已经转向 Edge，我完全不知道它为什么想要 Internet Explorer。我确实找到了对此的回应，说要破解注册表并重新安装 Internet Explorer，但当时这似乎有点矫枉过正。

通过 Visual Studio 的嵌入式 Azure 门户查看 Azure 错误似乎显示的数据与 Azure 门户非常相似。找不到调用堆栈。

许多年前，为 Http Server Errors 设置了经典警报，至今仍会触发。它不会触发来自机器人在站点上戳的 HttpExceptions，但它会触发重要的 500 秒，这很好。有趣的是，除了用户报告之外，它是了解错误的最可靠方式。可惜他们没有调用堆栈...

昨晚，我们遇到了一个页面异常，大概是在视图中。正如预期的那样，我们收到了来自经典警报的电子邮件，但“失败”部分根本没有显示任何失败。过去，我们会看到 500 个，但没有调用堆栈。似乎除了经典警报和用户之外，没有其他任何东西检测到昨晚的错误。我不知道是因为昨晚的错误是独一无二的，还是我们现在神秘地从 Azure 中获取的信息更少了。

尝试的解决方案

多年来，我遵循了无数的指南，从门户本身的翻转开关到 FTP 和查看原始日志（这显然与您的应用程序无关，与 Microsoft 托管它一样多）。如果我每次阅读指南时都能得到一分钱，“只需单击例外选项卡即可查看您的调用堆栈”，我会很富有：-P。

一个月前，我非常绝望，我在应用程序的 HttpApplication 类中实现了 Application_Error，并为 WebAPI 实现了 ExceptionLogger，以手动将所有异常记录到文本文件中。不幸的是，虽然这帮助我修复了一个错误，但随后的异常也没有出现在那里。与 Application Insights 一样，这些日志中显示的大部分机器人都在不存在的目录中进行操作。

一周前，我绝望到写了一个简陋的“单元测试”（哈！），它会提取生产数据的副本并在本地进行测试，这绝对是疯狂的。

我已经与使用 Azure 门户的其他架构师级别的 ASP.NET 工程师进行了交谈，但他们无法提出任何建议。我们查看了 web.configs；在根目录和 Views 文件夹中有一个。我们尝试打开 customerrors，但显然我们不能在生产中运行它，因为它会向用户显示错误。话虽如此，我不介意向某些用户显示真正的错误消息。一个人将如何做到这一点？如果我猜的话，问题就隐藏在那些 web.config 中，仅仅是因为它们很古老，而且有很多人接触过它们。

结论

我需要一种 100% 可靠的方法来从托管在 Azure 上的 ASP.NET 获取异常及其调用堆栈。否则，几乎不可能解决生产中意外出现的边缘情况。我不记得在 Azure 之前的日子里这是一个问题。

我确信那里的专家会在几分钟内解决这个问题，但是，就目前而言，我完全被难住了。感谢您的宝贵时间！

【问题讨论】：

异常处理一直很棘手，并确保没有任何东西被淹没在不应该出现的地方。对于基于 IIS 的网站，Application Insights 在捕获堆栈方面往往非常可靠。我无法想象一个“100%”防弹的解决方案，你知道这是一件愚蠢的事情。

这就是我如此困惑的部分原因......一切都意味着“它开箱即用。通过将 ASP.NET 与 Azure 结合使用，您可以获得所有这些调试工具”，并且然而它们都被证明对我毫无用处。我不在乎我得到多少漂亮的图表，如果它们总是显示扁平线并且没有调用堆栈。显然，配置肯定有问题。我无法想象微软花了数百万美元买了一个连调用堆栈都无法捕获的东西：-P。

如果您了解哪些类型的东西可能会吞下错误，但仍会产生 500 个错误，我将不胜感激。

也许我是个傻瓜，但请解释一下为什么可靠地捕获调用堆栈是一件愚蠢的事情？在所有其他应用程序中，如果引发异常，您可以在某处看到调用堆栈。为什么 Azure 的上下文提出了一个愚蠢的要求？

你听起来好像已经在街区转了一两次。正确获取异常并非易事，也不是微不足道的。这就像要求一个“100% 有效”的线程解决方案。这只是模糊的，不可行的。 （编辑：我敢打赌，你的应用程序在某些位置不会产生漂亮的堆栈跟踪，我们都会这样做！）

【参考方案1】：

需要尝试检查的几件事：

确保您的 Application Insights NuGet 包是最新的。在过去的几年里，我的指标停止工作，或者 AppInsights 刀片上出现了我没有收集的新指标。升级到最新的 NuGet 包就可以了。

您是否在 Web 应用程序中捕获异常，然后显式返回 HTTP 500 响应？如果是这样，您将看不到堆栈跟踪。在通过未处理的控制器方法一直冒泡后捕获堆栈跟踪。

【讨论】：

1.这是 NuGet 包和错误配置的结合。我获得了最新的软件包并取消了配置并重新开始以确保没有任何问题。我刚刚确认我能够重新创建昨晚的错误并获取调用堆栈！

最后，谢谢。我知道这在配置上会是一些小而愚蠢的事情，而你第一次尝试就成功了！