链锯 log4j 查看器的远程事件有什么意义？
http://logging.apache.org/chainsaw/quicktour.html
第一个功能。
我完成了教程，它只是展示了如何直观地使用 GUI，它没有详细介绍这个新功能。 我发现的最好的文档是这样的：
正如 Appender 在 log4j 环境之外发送日志事件（到文件、smtp、套接字等）一样，Receivers 将日志事件带入 log4j 环境内部。
接收器旨在支持从另一个进程接收远程日志记录事件。 例如，SocketAppender 将日志记录事件“附加”到为特定主机和端口号配置的套接字。 套接字的接收端可以是一个 SocketReceiver 对象。 SocketReceiver对象接收日志记录事件，然后将其“发布”到接收机器上的log4j环境（LoggerRepository），由配置的appender等处理。阈值）应用于接收到的日志记录事件。
接收器还可以用于将日志消息从其他日志记录包“导入”到 log4j 环境中。
接收器可以配置为将事件发布到给定的 LoggerRepository。
那么...
使用这个新组件可以实现什么样的日志记录策略，而我无法仅通过使用链锯 + 简单的 log4j 文件附加程序来使用它？
http://logging.apache.org/chainsaw/quicktour.html
First feature.
I completed the tutorial, it simply showed how to visually use the GUI, it didn't go into much detail at all regarding this new feature. The best documentation I have found is this:
Just as Appenders send logging events outside of the log4j environment (to files, to smtp, to sockets, etc), Receivers bring logging events inside the log4j environment.
Receivers are meant to support the receiving of remote logging events from another process. For example, SocketAppender "appends" a logging event to a socket, configured for a specific host and port number. On the receiving side of the socket can be a SocketReceiver object. The SocketReceiver object receives the logging event, and then "posts" it to the log4j environment (LoggerRepository) on the receiving machine, to be handled by the configured appenders, etc. The various settings in this environment (Logger levels, Appender filters & thresholds) are applied to the received logging event.
Receivers can also be used to "import" log messages from other logging packages into the log4j environment.
Receivers can be configured to post events to a given LoggerRepository.
So...
What kind of logging strategy can I achieve using this new component that I couldn't use just from using chainsaw + simple log4j file appenders?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用远程事件做许多有趣的事情：
- 避免在应用程序服务器上创建文件。 文件损坏。
- 在存在多个应用程序服务器的情况下集中日志。
- 从本地环境查看实时生产日志，即使链锯不是很性感，过滤功能也比普通的 vi/grep 更方便。
- 登录数据库而不是文件。 文件是坏的。
或许还有更多！
Their are many interesting things you can do with remote events:
- Avoid to create files on application servers. Files are bad.
- Centralize logs in case of multiple application servers.
- View live production logs from from your local environment, even if chainsaw is not very sexy, the filtering capabilities are more handy than plain vi/grep.
- Log in database instead of files. Files are bad.
And probably much more !
我过去曾在网格环境中使用远程事件。
为什么 ？ 因为我们不知道我们的代码将在哪里运行。 我们将部署“n”个作业，网格基础设施将选择在哪些机器上运行这些作业。 如果没有远程事件，我们就必须跟踪这些作业的去向，然后遇到登录、查找日志等麻烦。因为网格由用于其他目的的机器组成，所以我们无法保证这些机器稍后将进行诊断问题。
因此，一切都配置为将日志事件流回服务器，我们可以在其中为每个原始服务器创建日志文件，并自己管理这些日志。 存在一些问题，例如管理通过网络传输到一台服务器的数据量，但只要您意识到这一点，那就没问题。
I've used remote events in the past with grid environments.
Why ? Because we didn't know where our code would be running. We would deploy 'n' jobs, and the grid infrastructure would choose which machines to run those jobs on. Without remote events we would have to keep track of where those jobs had gone to, and then have the hassle of logging in, finding the logs etc. Because the grid consisted of machines used for other purposes, we couldn't guarantee that the machines would be up at a later date to diagnose issues.
So everything was configured to stream log events back to a server where we could create log files per originating server, and manage those logs ourselves. There are issues such as managing the quantity of data streaming across the network to one server, but so long as you're aware of that, that's fine.