如何在 Asp.Net Core 应用程序中实现可观察性如 Charity Majors 所述？

如何解决如何在 Asp.Net Core 应用程序中实现可观察性如 Charity Majors 所述？

在 https://charity.wtf/tag/observability/ 部分的如何收集和构建您的数据慈善专业提供以下方案：

1. 在管道早期初始化一个可在代码中随处访问的“blob”，每个请求都有自己的副本（实际上绑定到 HttpContext）
2. 任何希望记录一些信息的代码都会向这个“blob”添加键值对
3. 当请求退出时，“blob”作为结构化事件传送到可观察性服务器。

这个方案很有道理，也很优雅。它避免了常规日志的口头腹泻。然而，它也过于简单化，因为它忽略了批处理请求，其中一个请求必须处理 N 条记录，这可能会产生 N 组类似的结构化事件嵌套在与请求本身对应的父结构化事件中。在这种情况下，我们可以选择在处理记录后立即发送批处理记录事件，或者在请求结束时在要发送的“blob”中累积嵌套事件。在任何情况下，帖子中都不会讨论这种并发症。

在可能发明轮子之前，我想弄清楚我们是否已经准备好使用这种可观察性方案。这是我目前所拥有的：

1. 我们正在使用 Azure 及其 Application Insights TrackEvent API 作为低级 API 似乎是完美的。它支持 <Event Name,string-to-string map,string-to-float map> 形式的事件，这似乎足够丰富。然后可以在所有维度上查询收集到的事件，无论我们喜欢它。所以，可观察性服务器对我来说不是问题。
2. “blob”实现是一个问题。我正在寻找 .Net Core 的 Honeycomb 实现并遇到了这个页面 - https://docs.honeycomb.io/getting-data-in/dotnet/。然而，那里提出的 2 个选项似乎还不够成熟：
   • HoneyComb .NET 由我们来决定如何处理嵌套事件。
   • OpenTelemetry .NET 似乎根本不是关于可观察性，而是关于“可观察性的三大支柱”——日志记录、指标和跟踪。根据 https://www.infoq.com/news/2019/02/rethinking-observability/
   不提供可观察性
3. Microsoft.Extensions.Logging.ILogger 界面似乎提供了足够的界面。看起来 BeginScope 方法明确存在以分隔不同的批次。但它只是一个界面。

所以，我的问题是，Asp.Net Core 是否有一个实现作为结构化事件的可观察性，它也以一种或另一种方式考虑了嵌套事件，并且可以自定义以提供给 Application Insights 存储桶？

我可以详细说明批处理的挑战，但这个问题已经太长了，所以我就到此为止了。