使用 Log4J 进行结构化/组合日志记录
我希望你可以帮助我。
我有一个需要记录交易的网络服务。 由于有很多命中，日志语句在日志文件中显得不相交/碎片。
我考虑过在各层中传递一个 StringBuilder 实例并将语句附加到该实例，然后在向客户端返回响应之前在最后（主控制器中的finally子句）记录一次其内容。 这似乎没有必要，而且我确信有一种更简洁的方法可以使用 Log4J 来做到这一点。
谁能阐明这个问题？
谢谢
I hope you can help me.
I have a web service that needs to log transactions. Since there are many hits, the log statements appears disjoint/fragmented in the log file.
I've considered passing a StringBuilder instance through-out the layers and appending the statements to this instance, then I log its contents once at the very end (finally clause in the main controller) before returning a response to the client.
This seems unnecessary and I'm sure there's a cleaner way to do it with Log4J.
Can anyone shed light on the issue?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
还有一个想法，您可以考虑使用
java.lang.ThreadLocal来保存 当前 上下文可以在最后转储到日志中。One more idea, instead of passing a StringBuilder instance through-out the layers, which might lead to pretty awkward API (additional method parameters), you could consider using
java.lang.ThreadLocalto hold the current context that could be dumped to the log at the very end.好处是您正在使用 Log4j。 该库本身实现了嵌套诊断上下文 (
org.apache.log4j.NDC) 和映射诊断上下文 (org. apache.log4j.MDC）。 我认为您绝对应该看看两者，因为它们允许您构建某种可以在日志输出布局中使用的上下文。the good things is that you are using Log4j. The library itself implements the concept of nested diagnostic context (
org.apache.log4j.NDC) and mapped diagnostic context (org.apache.log4j.MDC). I reckon you should definitely have a look at both, because those allows you to build some sort of the context that you can use in your log output layout.您可能会考虑扭转问题：不要在运行时记录时合并条目的所有部分，而是稍后在数据分析期间合并它们。
例如，我们有一个记录大量数据的应用程序，其中快速响应非常重要。 我们最近实现了一个（定制的）系统，该系统有效地记录到关系数据库。 但是，它的日志记录部分针对日志记录进行了优化； 我们只需按照应用程序生成元组数据的顺序将元组数据附加到日志文件中即可。 我们拥有可以针对这种格式进行查询的工具，并且当我们开始对针对日志格式的每个查询实际上都需要对数据库中的每个表进行表扫描感到恼火时，还计划生成以不同格式存储的数据库的新版本。
即使您无法直接使用此技术，只要考虑一下它就可能会给您在 Log4J 中做得更好的想法。
You might consider turning the problem around: instead of consolidating all of the pieces of an entry when logging at runtime, consolidate them later during the analysis of the data.
For example, we have an application that logs a lot of data, where fast response is important. We recently implemented a (custom-built) system that logs to what is effictively a relational database. However, the logging portion of it is optomized for logging; we simply append tuple data to the logfile in the order that the application generates it. We have tools that can do queries against this format, and also plan to generate new versions of the database stored in a different format when we start getting annoyed that every query against the log format effectively requires a table scan of every table in the database.
Even if you can't make direct use of this technique, just considering it may give you ideas for doing something better within Log4J.
您真的需要按顺序排列所有日志语句吗？我的意思是它们在发生时就被记录下来。 如果更改顺序，您可能会错过某些事件的顺序，您可能需要这些事件来追踪棘手的错误。
您能否不向消息中添加标识符，例如使用发出请求的线程 ID 或用户 ID 来启动消息，这样您就可以使用 grep 之类的工具在日志上运行查询。
该语句将以正确的顺序快速返回该用户的所有日志语句。
我们在高吞吐量交易平台上使用此技术，这是通过日志文件中的系统跟踪交易或用户请求的最简单方法。
它也不需要扩展或编写您自己的记录器。
Do you really need to have all the log statements in order I mean they are being logged as they occur. If you change the order you might miss the sequence of some events which you may need to track down tricky bugs.
Can you not add an identifier to your messages like start them with a thread id or user id from which the request is originating, this way you can then run queries on the logs using something like grep.
the statement will return all the log statements for that user in the correct order and its fast.
We use this technique on a high throughput trading platform and it is the easiest way of following a trade or user request through the system in the log files.
It also doesn't require extending or writing your own logger.
我们过去需要解决类似的问题。 我们创建了一个封装的消息对象，其中还包含有关消息的元数据（例如用户事务 ID）和自定义附加程序类。 在这个appender类中，我们使用instanceof语句从信封中获取元数据，而不是简单地调用toString（这应该为一般appender返回一个不错的日志）。
或者您可以考虑使用 SLF4J，它的标准功能是传递 Marker 对象与日志消息。 例如，请参阅 Javadoc 的 debug(Markermarker, String msg) 方法重载。
We needed to solve something similar in the past. We have created an enveloped message object holding also metadata about message (e.g. user transaction id) and a custom appender class. In this appender class we are using instanceof statement to get the metadata from the envelope instead just simply calling toString (which should return a nice log for general appenders).
Or you can consider using SLF4J and it's standard capability to pass Marker objects with log messages. E.g. see Javadoc for their debug(Marker marker, String msg) method overload.