英文:
Tap into logging events generated in this thread
问题
我们都知道日志消息在调试时有多么有用。但有时，日志消息会被大量无用的其他消息淹没；这对于一些繁忙的服务器来说尤其如此。
我计划为系统维护添加一些REST端点，并希望收集所有的日志消息并将它们通过HTTP连接发送回来。REST响应就是收集到的日志。所有的日志点已经存在。
我的想法是在REST请求的开始添加一个自定义的Appender，然后在之后移除它：
@GET
public void request (@Context HttpServletResponse response) {
Appender appender = new SpecialThisThreadOnlyAppender(response.getWriter())
rootLogger.addAppender(appender);
try {
request0();
} finally {
rootLogger.removeAppender(appender);
}
}
是否已经有一个名为SpecialThisThreadOnlyAppender的Appender可以直接使用，或者这种情况是否会被视为对log4j引擎的滥用？
英文:
We all know how useful are log messages for debugging purposes. But sometimes logging gets buried under tons of now-useless other messages; this is specially true for some busy servers.
I'm planning to have some REST endpoints for system maintenance, and would like to collect all the logging messages and send them back over the HTTP connection. The REST response IS the collected logs. All the logging points are already there.
My idea was to add a custom Appender at the very beginning of a REST request, and remove it afterwards:
@GET
public void request (@Context HttpServletResponse response) {
Appender appender = new SpecialThisThreadOnlyAppender(response.getWriter())
rootLogger.addAppender(appender);
try {
request0();
} finally {
rootLogger.removeAppender(appender);
}
}
Is there already a SpecialThisThreadOnlyAppender ready for use (whichever name it has), or would this scenario amounts to abuse of log4j engine?
答案1
得分: 2
这是一个有趣的想法，但我很难确定它的有用性。您正在创建一个返回日志作为其响应的REST请求。但在这种情况下，REST请求应该做什么呢？它不返回请求0应该执行的结果，那么对于想要使用此端点的应用程序来说，这有什么用呢？基本上，它只对curl或Postman有用。为了有用，这可能需要在URI中接受您想要调用的服务方法作为参数，但在生产环境中，您几乎肯定不想要这样的端点。
大多数人通过向日志事件添加关联器来解决这个问题。请参阅Log4j Audit Request Context，了解Log4j Audit如何支持它，但您不必使用它来实现，因为它只是使用Log4j的ThreadContext来捕获相关数据。如果您在每个请求中包含唯一的RequestId，并为每个用户包含唯一的SessionId（不是HTTP会话ID），则可以捕获所有相同的信息，假设您正在使用某种日志聚合，如ELK。
此外，如果您使用关联器，理论上可以使用RoutingAppender基于其中一个关联器将日志路由到不同的位置。
这里有一些其他关于使用关联器的链接：Fish Tagging Logs和Logging Each Action of Every User。
英文:
This is an interesting idea but I am having difficulty determining the usefulness of this. You are creating a REST request that returns the logs as its response. But in that case what is the REST request supposed to be doing? It doesn't return the results of whatever request0 is supposed to do so how is this useful to the application that wants to use this endpoint? Basically, it is only useful from curl or Postman. In order to be useful this would probably need to accept the service method you want to call as a parameter in the uri, but you would almost certainly never want an endpoint like that in a production environment.
Most people solve this problem by adding correlators to the log events. See Log4j Audit Request Context for how Log4j Audit supports it, but you don't have to use that to implement it as it simply uses Log4j's ThreadContext to capture the relevant data. If you include a unique RequestId in each request and a unique SessionId (not the HTTP session id) for each user you can capture all of the same info assuming you are using some sort of log aggregation like ELK.
Also, if you use correlators in theory you could use the RoutingAppender to route to different locations based on one of the correlators.
Here are some other links to using correlators: Fish Tagging Logs and Logging Each Action of Every User
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论