serilog - Serilog.Sinks.Console 接收器是否从包装到 Serilog.Sinks.Async 接收器中获得任何好处？

Question

我在我的 aspnet core 应用程序中使用 Serilog 进行日志记录。我需要频繁地将日志事件写入控制台(每秒 300-500 个事件)。我在 docker 容器内运行我的应用程序，并使用 Orchestrator 工具处理控制台日志。

所以我的问题:我应该为我的 Console 接收器使用 Async 包装器吗？我会从中获得任何好处吗？我阅读了文档( https://github.com/serilog/serilog-sinks-async )，但无法理解它是否真的适用于 Console 接收器。

Answer 1

Async Sink 获取已捕获的 LogEvent 项，并使用 ConcurrentQueue Producer 将它们从多个前台线程转移到单个后台处理器/消费者收藏。一般来说，这对于稳定的吞吐量来说是一件好事，尤其是对于事件的吞吐量。

此外，如果发送到 >1 个接收器，如果您有足够的可用核心和/或接收器，则转移到后台线程，该线程将根据需要进行调度，重点关注该工作负载(即传播到缓存中的接收器的路径)。甚至暂时阻止。

话虽如此，基于这些信息的任何内容都是不成熟的优化。

<小时/>

如果您不将 Async 放在前面，控制台接收器及其高效摄取且不会阻塞的能力始终取决于很多 - 例如，托管环境通常会合成 stdout code> 有效地缓冲。当效果良好时，在控制台接收器前面添加异步只会延长对象生命周期，而与允许每个线程直接提交到控制台接收器相比没有太大好处。

<小时/>

所以，这取决于 - IME 将所有内容提供给 Async 并在那里进行所有处理(例如写入缓冲文件，每隔 .5s 发出一次(可能发送到 sidecar 进程)转发到您的日志存储))可以很好地工作。最重要的是，一个好的负载生成器设备对于任何高吞吐量应用程序来说都是非常有用的。一旦你拥有了一个，你就可以进行实验 - 我已经看到通过重新组织完全相同的输出及其安排方式可以提高 30％ 的吞吐量(诚然，我也在该过渡期间切换到 Serilog - 你不太可能看到任何这样的结果)。