Aspnetcore: 事件源？ 诊断源？ 两个都？

@rynowak - 我们有这方面的指导可以分享吗？

我在内部重复了很多次的一些快速想法，但我不确定外部......

事件源

假设对 EventSource 的任何使用也意味着使用进程外日志记录机制，如 LTTNG 或 ETW。 当您想要触发一些低保真信息的数据点以便稍后查看时，EventSource 非常有用，并且更有可能编译成某种统计数据或摘要。 我说低保真度是因为 EventSource 的常见用法是将事件通过管道传输到文件 (ETW)，然后使用它们进行事后分析。 从 EventSource 中查看数据的工具（如 PerfView）对某些事件（JIT、GC）有特殊的了解，但对于您编写的事件，它们显示了一个通用视图。 显示通用视图或摘要/数据表很有效，因为它们都是简单类型。 您当然可以构建专门的工具，但常见的情况是使用 PerfView 之类的工具。

下一个声明似乎很明显，但我提到它的原因很快就会变得清晰。 使用 EventSource 可以提前确定您触发的事件的解释。 您要记录的所有数据都是由组件作者指定的，并且具有固定的含义，通常与事件名称相关联。 使用 EventSource，您经常会说“读取 4096 字节的数据”或“在 5.6 毫秒内加载文件”。 这些关于事实的小陈述可以编译成摘要，例如“150ms 花费在文件 i/o 上”，或者如果它们是异常值，则可以专门钻研。

诊断源

假设对 DiagnosticSource 的任何使用都是由“插件”或其他日志系统在进程内完成的，这些系统会将您的数据提炼成有意义的数据块。 当您想将应用程序状态的完整上下文传递给侦听器并且该侦听器将根据对应用程序状态的访问添加自己的解释时，DiagnosticSource 非常有用。 DiagnosticSource 也没有本地日志格式，也没有对其数据点的一般理解（因为它们通常不是简单类型）——它需要一个额外的系统来创建用户想要看到的东西。

DiagnosticSource 事件往往比较大块，并且会说诸如“我将要处理请求”或“我捕获到中间件抛出的异常”之类的内容。 这些仍然是事实陈述，但范围要大得多。 由于工具可以访问丰富的上下文，因此它们可以根据上下文自由捕获任何有意义的信息。 最终，由 Application Insights 之类的工具捕获的信息集不是由 ASP.NET 团队定义的。 我们为他们提供我们拥有的所有背景信息，他们会捕捉到他们认为重要的内容。

您还可以通过桥将 DiagnosticSource 数据通过管道传输到 EventSource。 我个人没有这样做过，但我似乎打算避免在某些地方将所需的诊断代码数量增加一倍。 https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L22我不会假设你会在所有的与 EventSource 相同的地方。 我不确定利用这一点的策略会如何发挥作用，我还没有尝试过。

对我们来说，这个领域已经发生了几次变化。 我们从与 Glimpse 合作开始，最终与 Application Insights 合作。 在此过程中，已经在诊断源之上构建了一些其他东西，但我不确定这些其他工具现在的状态。

我们的计划

我无法谈论围绕 EventSource 或 DiagnosticSource 的更大策略 - 但我可以回答我如何看待它们以及大多数团队如何看待我们的方法。 我们没有创建 DiagnosticSource 作为 EventSource 的替代品。 在我看来，它服务于不同的消费者和一组场景。

我们在我们认为会增加很多价值的地方添加诊断源事件。 其中一些非常有用，因为它们就像其他人构建诊断的可扩展性。 我敢说托管可能有 3-5 个诊断源点，而 MVC 有接近 10 个。我不确定我们目前是否正在跟踪添加更多的地方。 如果有人有真正的需要，我们会考虑。

我们正在构建事件源。 这是我们的现场支持工程师所熟悉的，它通常是 Microsoft 团队性能分析的重要组成部分。 我们仍在努力解决由于缺少性能计数器而留下的空白。 .NET 团队正在努力使 EventCounters（建立在 EventSource 之上）作为合适的替代品。 ASP.NET 团队延迟对 EventSource 进行更多投资的主要原因是，有一段时间不清楚非 Windows 的策略是什么。 我们希望避免另建附加的东西，将来如果EventSource的是不会是它的* nix平台。 那已经被清除了。

这里有一个很好的文档： https :

为你

嗯，听起来你可以两者兼而有之。 我不是很熟悉你在做什么，所以下面是一些一般性的建议。

首先，想想你的消费者是谁。 这是给你的吗？ (perf) 这是给应用程序开发人员的吗？ （调试和故障排除）这是给工具作者的吗？ 工具是在事后运行还是在应用程序内部运行？

其次，考虑您计划检测多少地方以及您认为哪些数据是有意义的。 消费者将如何理解和解释这些数据？ 单个数据点是否有意义还是应该汇总数据？

我们会定期关闭长时间未更新的“讨论”问题。

如果由此造成任何不便，我们深表歉意。 我们要求如果您仍然遇到问题，请用更新的信息记录一个新问题，我们将进行调查。