【问题标题】:Global exception handler in ASP.Net Core (Not UI)ASP.Net Core 中的全局异常处理程序(非 UI)
【发布时间】:2021-10-14 07:33:22
【问题描述】:

我正在开发一个将在 Kubernetes 中运行的应用程序。 Kubernetes 依靠应用程序来了解它是否健康。

所以,我需要知道何时抛出了严重异常。 “Critical”是指内存不足、堆栈溢出等。这意味着容器应该被杀死。

我在 ASP.Net Core 中看到允许您在发生异常时显示错误页面的东西,但我需要 UI 和 Web API 应用程序都发生这种情况。而且我真的不希望它与我的 UI 交互(在那些有 UI 的人上)。

在 ASP.Net Core 应用程序中引发异常时是否会引发事件(或类似事件)?

【问题讨论】:

  • 您在 .NET 中根本无法捕获 OutOfMemoryExceptionStackOverflowException。他们只是当场杀死你的程序,即使你有错误处理。
  • @Alejandro - 我认为你在OutOfMemoryException 中可能是错误的。我有一个在容器中运行的 ASP.Net Core Web API 应用程序,我将其设置为具有消耗内存的操作。该操作需要几次调用来消耗所有内存。在我打了几个电话之后,它会抛出OutOfMemoryException。但其他(低内存)操作继续正常工作。但是检查显示容器没有死,并且继续保留内存。 (另一个电话会引发另一个OutOfMemoryException。)
  • Alejandro 对 StackOverflowException 的看法绝对正确。但我同意 Vaccano 的观点,我至少能够处理 OutOfMemoryException 到记录它的地步。

标签: c# asp.net-core asp.net-core-3.1


【解决方案1】:

.NET 应用程序将无法以报告自身运行状况的方式处理“关键”问题,例如内存问题或堆栈溢出。出现意外错误基本上有两种可能的结果:应用程序可以处理问题,在这种情况下,ASP.NET Core 应用程序有望正常工作以应对未来的请求,或者进程突然终止。

观察后者应该从外部进行。例如,您可以通过检查进程在您的容器中是否仍然存在来执行此操作。

另一种选择是使用health checks,这是 ASP.NET Core 应用程序报告自身运行状况的一种方式:

容器编排器和负载平衡器可以使用运行状况探测来检查应用的状态。例如,容器编排器可以通过停止滚动部署或重新启动容器来响应失败的健康检查。负载均衡器可能会通过将流量从故障实例路由到健康实例来对不健康的应用做出反应。

因此,您的容器编排器可以检查 ASP.NET Core 应用程序是否仍然能够响应运行状况探测,以及是否假定应用程序以某种方式崩溃,需要重新启动容器。

【讨论】:

  • 我正在尝试设置健康检查。我认为内存不足异常会导致进程终止,但事实并非如此。 (操作失败,但该进程仍在运行,响应其他低内存操作,并且仍然保留所有内存。)所以我需要知道它发生了,所以我可以告诉健康检查返回unhealthy
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-01-10
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-04-17
  • 2012-12-31
相关资源
最近更新 更多