在多个组件中记录全局 ID
我有一个系统,其中包含使用 JMS 和 Spring Integration 连接在一起的多个应用程序。消息沿着一系列应用程序发送。
[应用程序A]-> [应用程序B]-> [应用程序 C]
我们在消息头中设置了一个全局 ID,以便我们可以通过系统跟踪每个消息的生命周期。
我希望能够在系统中的任何日志消息前添加消息全局 ID。
还有其他人这样做过吗?有什么方法可以将此变量关联到线程,以便我可以在将来的方法中访问它吗?我不想在系统的方法中传递变量。
I have a system which contains multiple applications connected together using JMS and Spring Integration. Messages get sent along a chain of applications.
[App A] -> [App B] -> [App C]
We set a global id in the message header so we can trace each message lifecycle through the system.
I would like to be able to prepend any log message in the system with the message global id.
Has anyone else done this? Is there any way to associate this variable to the Thread so I can access it in future methods? I'd rather not pass the variable around in methods of the system.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我认为 ThreadLocal 可能就是您想要的,尽管有些人可能会发现这种方法滥用了 ThreadLocal 的目的或良好的设计。类似于:
这里的神奇之处在于 myID 的值实际上是特定于线程的,并且从不同线程访问时会有所不同。
然后,您可以使用 ID 执行您喜欢的操作,包括记录它。
I think ThreadLocal may be what you want here, though some may find this approach an abuse of ThreadLocal's purpose, or good design. Something like:
The magic here is that myID's value is actually specific to a Thread, and will be different when accessed from different threads.
You can then do what you like with the ID, including logging it.
我相信第一篇文章提到的另一个答案是简单地要求您的日志记录框架在日志语句中包含线程名称。例如,log4j 允许您在其 PatternLayout 中添加带有“t”的线程名称: http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html 我也在其他框架中看到了这一点。
Another answer, which I believe the first post is alluding to, is to simply ask your logging framework to include the thread name in the log statement. For example, log4j lets you add the thread name with 't' in its PatternLayout: http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html I've seen this in other frameworks too.
顺便说一句,这种方法是更广泛的企业日志记录模式的一部分。我试图在此处记录此模式。总结是:
BTW, this approach is part of a wider enterprise logging pattern. I attempted to document this pattern here. The summary is: