用Retrace获取详细的异常情况

260 阅读8分钟

功能有限的异常处理工具往往寿命很短。值 得庆幸的是, 用Retrace获取详细的 异常 是开发团队的一个不错的选择,尤其是与ELMAH相比。让我们来看看。

日志工具在市场上已经存在很多年了。一个例子是ASP.NET的常用日志工具ELMAH。捕捉通过IIS响应管道出现的异常,ELMAH将异常与背景信息一起记录下来。ELMAH还在你的网站上放了一个子页面,你可以访问这个页面来查看记录的异常,这使得它成为捕捉、记录和查看 单体ASP.NET应用程序的未处理异常的好工具 。但现在我们已经转移到了分布式应用架构,你和你的IT团队需要一个不同的功能集。

当你寻找一个日志工具来满足你作为一个负责维护系统的软件开发人员的不同需求时,你可以去找 Retrace。Retrace不仅仅是一个错误表,它还提供 指标监控、跟踪日志汇总。你还可以将ELMAH日志、log4net和NLog源送入Retrace,仅举几例。

虽然你不必完全埋没ELMAH,但你想转向ASP.NET Core之类的东西,甚至对于你的多语言者来说,Retrace让你走得更远!


Try this before your next .NET push


使用Retrace与ELMAH获取异常信息

ELMAH 给你一个错误列表,你可以直观地扫描。在你真正看到你需要的东西之前,你必须把它全部看完。另一方面,Retrace扫描你的错误并给你图表和指标。有了这些视觉效果,你可以把注意力集中在重要的事情上。

由于一图胜千言,让我们看看你从Retrace得到了什么。

Retrace scans your errors and gives you graphs and metrics

错误仪表板显示了所选应用程序中的若干错误细分。你可以看到过去四小时内每个时间段的错误图表,以及每分钟和每小时记录的错误数量。每种类型的错误计数列在底部,并很好地分组,这样你就不会滚动浏览一个长长的列表。

灵活性

由于您可以使用如此多的记录客户端向Retrace发送数据,您在.NET应用程序中使用的工具具有更大的灵活性。ELMAH并不自动与.NET核心兼容,但其他日志工具是兼容的。例如,你可以使用 这个NuGet 包来处理.NET Core的配置。NLog只需按照 GitHub维基 上的说明就可以使用 了。当然,你也可以随时将日志条目发送到REST端点。

除了在.NET标准和.NET核心中灵活使用各种日志工具外,你还可以从各种平台上向Retrace日志,包括 Node.js、Java、PHP和Ruby。理论上说,你可以从任何有HTTP客户端的地方记录,有了Retrace,你可以得到更多的功能。

语境信息

在Retrace中,你可以得到比ELMAH更多的上下文信息,ELMAH在提供堆栈跟踪和请求信息的同时还提供一些关于服务器的信息。你没有得到的是周围的环境或关于请求 "内部 "发生的细节。

从Retrace Errors仪表板上,你可以查看整个应用程序,以了解在特定的应用程序异常周围,系统中还发生了什么。也许有不止一个应用程序同时记录了一个错误。这可能表明一个网络问题,一个共享数据库问题,或者在一个共同的依赖关系上发生的事情,比如一个共享的API。从仪表板上,你会清楚地看到这种类型的问题的证据。

除了在一个屏幕上看到多个应用程序以提供背景外,你还可以围绕出现问题的具体调用获得更多的背景。Retrace为您提供更多背景的另一种方式是 自动跟踪。

自动跟踪

使用Retrace,你可以启用轻量级跟踪,以获得更好的细节。ELMAH不包括与错误日志一起的集成APM解决方案,但Retrace包括。现在,当你有一个错误,你有跟踪,你可以看到错误发生时还发生了什么。

对当今应用程序中最常见的资源进行自动追踪--调用 SQL Server、Redis缓存、DynamoDB和其他。当你把错误日志与追踪结合起来时,你会从错误日志中受益更多。

最好的办法是自己看一下差别,所以这里有一个例子。下面的图片取自一个错误文档,其中包含了从日志客户端发送的所有信息。这里是关于网络请求本身的部分。

Error detail

我们从网页请求中知道这个错误来自于索引路由,但是我们并没有得到完整的信息。

下面是跟踪日志中的同一个错误。

Error in Retrace's trace log

正如你所看到的,服务器响应了用户,好像一切都很好。然而,在请求过程中出现了一个错误。有了这些信息,你甚至可能发现你甚至不知道你有的问题这就是性能监控真正发挥作用的地方。

应用性能

看到错误和堆栈跟踪是一回事,但这些只能给我们提供用户看到的一小部分情况。错误只告诉我们什么时候出了问题 _,_什么时候 抛出了 异常。但是,当我们只看那些类型的问题时,我们会错过很多。还有其他问题需要考虑,比如当一个页面停滞不前时,会发生什么。此外,当一个特定的组件需要永远加载时,又该怎么办?

从用户体验的角度来看,这些也是问题。虽然这些问题可能不会导致蓝屏死亡或错误响应,但这些故障仍然影响着用户体验。

当你衡量应用程序的性能时,你通常会关注HTTP响应时间等事情。那是第一道防线。是的,你可以直接从服务器日志中获得这些信息。但是,当你发现一个缓慢的请求时会发生什么?你要采取什么措施来进一步了解潜在的问题?

在这一点上,你可能会问各种问题。它是一个特定的SQL调用吗?是页面生成的问题吗?是并发性问题吗?当时的服务器资源利用情况如何?你可以去找各种资源来回答其中的一些问题,但那会花费很长的时间。除非你准备好了,否则你不会回答所有这些问题。我们已经看到,追踪给我们提供了围绕请求的更多信息。现在让我们来看看它是如何帮助发现资源时间的问题的。

响应时间细分

下面是一个耗时超过200秒的网络请求的例子。

Sample of a web request that took more than 200 seconds

你不会期望用户在刷新页面之前等待这么长时间。通过跟踪视图,你可以准确地看到每个操作对糟糕的响应时间有多大影响。在这种情况下,你可以看到,MySQL查询是罪魁祸首。从这一点来看,你可以把响应时间归结为一个死锁。

用户界面

Retrace中最好的功能之一,特别是对产品经理来说,是全面的仪表盘。Retrace不仅仅是一个供技术人员查看错误的工具。Retrace 是通过让您真正了解您的应用程序并用于规划,从而最大限度地利用您的应用程序。

Retrace 仪表板视图在一个地方显示所有这些信息,让您即时了解服务器健康状况、应用程序性能,当然还有错误。Retrace 甚至会给您的应用程序性能打分,并提供提高分数的提示!

使用Retrace来处理异常!

虽然ELMAH是一个简单、有效的解决方案,用于记录单个ASP.NET网络应用程序中的错误,但它有其局限性。使用Retrace来代替发送日志,并享受一个能给你带来更好的功能和指标的解决方案。

如果您对Retrace仍持观望态度,您可以通过 注册14天的免费试用来尝试一下,不需要任何承诺 。一旦你这样做,你可能已经准备好让ELMAH永远消失了。

关于Phil Vuollet

Phil Vuollet使用软件来实现流程自动化,以提高效率和可重复性。他撰写与技术和商业相关的主题,偶尔就同样的主题发表演讲,他是一个喜欢和孩子们一起踢足球和玩棋盘游戏的居家男人。