我正在尝试替换我的一位客户的内部编写的记录器解决方案。几乎所有事情都是直截了当的，但我需要实现一个接收器，将日志发送到我无法更改的自定义日志窗口（目前）。它使用命名管道进行通信。此管道可能已损坏或忙碌，因此当前的解决方案实际上会阻塞每个日志调用 - 我想改进。
问题是使用 serilog 时的最佳实践是什么：告诉 serilog 接收器当前已损坏的最佳方法是什么，因此它不会减慢系统速度。抛出异常就够了吗？
【问题讨论】：
标签： serilog
Serilog 本身不知道（或关心）水槽何时损坏，所以我不确定我是否理解您的目标。
写入 Serilog 记录器应该是一种安全操作，by design，因此在您的接收器中发生的任何异常都会被 Serilog 自动捕获，以确保应用程序不会崩溃。 Serilog 将确保将这些异常写入SelfLog，开发人员可以使用它来解决接收器问题。 See an example here.
因此，如果您的目标是让开发人员可以看到接收器何时出现问题，建议将错误消息写入SelfLog 并从接收器中抛出您自己的异常。
如果您可以从接收器中检测到命名管道在没有阻塞的情况下不可用，则只需写入SelfLog 并返回/短路而不尝试写入它。在您的接收器中实现任何类型的resilience policy 真的取决于您。
如果您的目标是改进阻塞调用，您可能需要考虑使接收器异步，在单独的线程上发送消息，而不阻塞应用程序的主线程。
鉴于您正在实施自己的自定义接收器，一个简单的方法是将接收器变成Periodic Batching sink 并利用它提供的基础架构。或者，您可以使用Serilog.Sinks.Async wrapper sink。
【讨论】：