默认情况下何时不使用AsyncAppender登录 [英] When not to use AsyncAppender in logback by default

问题描述

Logback支持对类使用异步附加器 ch.qos.Logback.classic.AsyncAppender，根据文档，这将减少应用程序的日志记录开销.因此，为什么不将其设置为默认值即可.通过使用同步附加程序可以更好地服务于哪些用例.我可以通过Async附加程序看到的一个问题是，日志消息不会按时间顺序排列.还有其他限制吗?

Logback supports using an async appender with the class ch.qos.Logback.classic.AsyncAppender and according to the documentation, this will reduce the logging overhead on the application. So, why not just make it the default out of the box. What usecases are better served by using a sync appender. One problem I can see with the Async appender is that the log messages will not be chronological. Are there any other such limitations?

推荐答案

AsyncAppender充当另一个附加程序的调度程序.它缓冲日志事件并将其分派到FileAppender或ConsoleAppender等.

The AsyncAppender acts as a dispatcher to another appender. It buffers log events and dispatches them to, say, a FileAppender or a ConsoleAppender etc.

• 为什么使用AsyncAppender?

• AsyncAppender缓冲日志事件，使您的应用程序代码可以继续运行，而不必等待日志子系统完成写操作.在底层追加程序响应缓慢的情况下，例如，这可以提高应用程序的响应速度.可能易于争用的数据库或文件系统.

• The AsyncAppender buffers log events, allowing your application code to move on rather than wait for the logging sub system to complete a write. This can improve your application's responsiveness in cases where the underying appender is slow to respond e.g. a database or a file system which may be prone to contention.

为什么不使其成为默认行为?

Why not make it the default behaviour?

• AsyncAppender无法写入文件或控制台，数据库或套接字等.相反，它只是将日志事件委托给可以执行此操作的附加程序.实际上，如果没有底层附加程序，则AsyncAppender实际上是无操作的.
• 日志事件的缓冲区位于应用程序的堆上；这是潜在的资源泄漏.如果缓冲区的建立速度比耗尽缓冲区的速度快，那么缓冲区将消耗应用程序可能想要使用的资源.
• AsyncAppender需要进行配置以平衡无损和资源泄漏的竞争需求，并处理其缓冲器的关机消耗，这意味着管理和推理比简单地使用同步更为复杂.写道.因此，在优先考虑简单性而不是复杂性的基础上，使Logback的默认写策略保持同步是有意义的.

• The AsyncAppender cannot write to a file or console or a database or a socket etc. Instead, it just delegates log events to an appender which can do that. Without the underlying appender the AsyncAppender is, effectively, a no-op.
• The buffer of log events sits on your application's heap; this is a potential resource leak. If the buffer builds more quickly than it can be drained then the buffer will consume resources which your application might want to use.
• The AsyncAppender's need for configuration to balance the competing demands of no-loss and resource leakage and to handle on-shutdown draining of its buffer means that it is more complicated to manage and to reason about than simply using synchronous writes. So, on the basis of preferring simplicity over complexity it makes sense for Logback's default write strategy to be synchronous.

AsyncAppender公开了配置杠杆，可用于解决潜在的资源泄漏.例如:

The AsyncAppender exposes configuration levers which you can use to address the potential resource leakage. For example:

• 您可以增加缓冲区容量
• 您可以指示Logback在缓冲区达到最大容量后丢弃事件
• 您可以控制丢弃哪些类型的事件；在ERROR事件等之前删除TRACE事件

AsyncAppender还提供了一些配置杠杆，可用于限制(尽管不能消除)应用程序关闭期间事件的丢失.

The AsyncAppender also exposes configuration levers which you can use to limit (though not eliminate) the loss of events during application shutdown.

但是，确保日志事件成功写入的最简单安全的方法仍然是同步写入，这仍然是事实. AsyncAppender仅在您有可靠的问题在其中写入追加程序会严重影响应用程序的响应能力/吞吐量时才考虑使用.

However, it remains true that the simplest safest way of ensuring that log events are successfully writtten is to write them synchronously. The AsyncAppender should only be considered when you have a proven issue where writing to an appender materially affects your application responsiveness / throughput.

这篇关于默认情况下何时不使用AsyncAppender登录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！