ASP.Net Web Api 2 中内置的跟踪是否仅适用于非生产环境？答案

【问题标题】：Is the tracing built in to ASP.Net Web Api 2 only meant for a non-production environment?ASP.Net Web Api 2 中内置的跟踪是否仅适用于非生产环境？
【发布时间】：2018-01-12 23:37:48
【问题描述】：

我阅读了Global Error Handling 的建议和Tracing in Web API 2 的文章，并且了解如何设置这些内容。但是，我在错误处理部分注意到它指出：

虽然 Web API 确实具有捕获错误情况的跟踪基础架构，但该跟踪基础架构用于诊断目的，不适合在生产环境中运行。全局异常处理和日志记录应该是可以在生产期间运行并插入现有监控解决方案的服务

我正在寻求对此的澄清。这句话是说错误只应在不生产时作为跟踪的一部分记录，还是ITraceWriter 的自定义实现只应在不生产时向HttpConfiguration 注册？

我会假设文章说

不适合在生产环境中运行

只是为了性能影响，但是通过查看TraceRecord 上的Exception 与传递到IExceptionLogger 的Exception 相比，我可以看到一些不同的上下文信息以了解特定错误?

【问题讨论】：

标签： c# asp.net .net asp.net-web-api2

【解决方案1】：

按照所写的内容，它是一种基本的跟踪和日志记录形式，虽然对于开发人员和诊断环境来说很好，但由于性能和功能原因，它不适用于生产环境。

为了尽职尽责，建议使用进程外服务（例如，在单独的进程中使用 log4net 或从 Azure 中选择），以减少由于核心进程故障而导致日志记录失败的可能性；扩展性能的空间；以及默认设计中未提供的功能更丰富的日志记录系统的潜力。

【讨论】：

那么，人们通常会将调试编译器指令放在注册跟踪器周围，还是有其他方法可以做到这一点？
@CShark 我不知道这种情况下的标准是什么，但不想有两种不同的日志记录系统——一个用于 DEV，另一个用于 PROD，选择一个并使用它更有意义全线。了解 log4net 在全球范围内的流行程度，它是您作为首选引擎的良好初始选择
是的，我不是在谈论日志库，我只会使用 log4net。我只是在谈论在这部分周围放置编译器指令：config.Services.Replace(typeof(ITraceManager), new MyTraceManager());
@CShark 我已经回答过了。抛弃他们的机制，从一开始就使用 log4net。不需要抽象，在代码中使用 #if 会增加测试负担，因为现在根据程序的编译方式会出现不同的行为
这个问题不是关于使用什么日志框架。我已经说过我正在使用 log4net，但这与我的问题无关。我在问我是否应该只在开发环境中注册我自己的ITraceWriter。看来你已经回答了，如果我的评论让你感到困惑，我很抱歉。