在https://charity.wtf/tag/observability/如何收集和构建您的数据部分中，慈善专业提供了以下方案：
- 在管道的早期初始化一个在代码中随处可访问的“blob”，每个请求都有自己的副本（实际上与
HttpContext. - 任何希望记录一些信息的代码都会向这个“blob”添加键值对
- 当请求退出时，“blob”作为结构化事件传递给可观察性服务器。
这个方案很有意义，也很优雅。它避免了常规日志的口头腹泻。但是，它也过于简单，因为它忽略了批处理请求，其中一个请求必须处理 N 条记录，这可能会产生 N 组类似的结构化事件，这些事件嵌套在与请求本身相对应的父结构化事件中。在这种情况下，我们可以选择在处理记录后立即发送批处理记录事件，或者在请求结束时将嵌套事件累积在“blob”中发送。无论如何，帖子中都没有讨论这种并发症。
在可能发明轮子之前，我试图弄清楚我们是否准备好使用这种可观察性方案。这是我到目前为止所拥有的：
- 我们正在使用 Azure，它的 Application Insights TrackEvent API 似乎是完美的低级 API。它支持
<Event Name, string-to-string map, string-to-float map>似乎足够丰富的形式的事件。然后可以在我们喜欢的所有维度上查询收集到的事件。所以，可观察性服务器对我来说不是问题。 - “blob”实现是一个问题。我正在寻找 .Net Core 的 Honeycomb 实现并遇到了这个页面 - https://docs.honeycomb.io/getting-data-in/dotnet/。然而，那里提出的 2 个选项似乎还不够成熟：
- HoneyComb .NET让我们来决定如何处理嵌套事件。
- OpenTelemetry .NET似乎根本不是关于可观察性的，而是关于“可观察性的 3 个支柱”——日志记录、度量和跟踪。根据https://www.infoq.com/news/2019/02/rethinking-observability/不提供可观察性
- Microsoft.Extensions.Logging.ILogger接口似乎提供了一个足够的接口。看起来BeginScope方法明确存在以分隔不同的批次。但它只是一个接口。
所以，我的问题是 Asp.Net Core 是否有一个实现可观察性作为结构化事件，它还以一种或另一种方式考虑嵌套事件，并且可以定制以传递到 Application Insights 存储桶？
我可以详细说明批处理的挑战，但是这个问题已经太长了，所以我停在这里。