我对 rsyslog
的理解是它是 Ubuntu 机器上常见的 syslog
服务器实现。
此外,我的理解是rsyslog
可用于 Hook /捕获STDOUT
输出以及标准 syslog
消息。
最后,我的理解是rsyslog
然后可以转发任何 捕获的消息(同样,来自STDOUT
或 syslog
客户端)到另一台服务器,例如日志聚合器或另一台 rsyslog
服务器等。
所以首先,如果任何我上面说的不正确,请首先纠正我对syslog
/rsyslog
工作原理的理解,并且他们之间的关系!
如果我的假设或多或少是正确的,那么给出以下两个选项:
- 选项 #1:登录到
STDOUT
并配置rsyslog
以捕获该流并将日志消息转发到远程进程(比如日志聚合器);或 - 选项 #2:登录到
syslog
并配置rsyslog
以捕获它并将日志消息转发到相同的远程进程
鉴于这两个选项,我更喜欢#1,因为:
- 在本地或从 IDE 运行时,
STDOUT
将打印到控制台;和 - 在任何非本地环境中运行时,
STDOUT
只会被rsyslog
“收集”
如果我选择选项 #2,我在本地运行时会失去控制台可见性。
话虽如此,登录到 STDOUT
是否存在任何安全/性能/其他问题/注意事项/陷阱,这会使选项 #2 更具吸引力/更受欢迎?如果有,它们是什么?
最佳答案
您应该使用众多记录器之一(即 java.util.logging 等),然后根据每个用例对其进行适当配置。对于本地测试,将记录器配置为 STDOUT。对于生产,为系统日志配置它。
通过简单地记录 STDOUT,您将丢失记录器提供的任何元数据,或者可能由 syslog 使用的元数据,因为您只能记录消息。
例如,在 Glassfish 中,任何运行到 STDOUT 的内容都会作为 INFO 记录到 Glassfish 日志中。
因此,如果您将 Log4j 运行到 STDOUT,则会捕获日志,但您没有捕获的是它们是 WARN 还是 DEBUG 或其他什么。 TAG 作为消息的一部分被捕获,但与通过记录器本身运行的内容相比,消息表面上是不透明的。
如果您已将 Log4j 配置为使用 Glassfish 记录器(即 java.util.logger),那么 Glassfish 日志将捕获映射到 Glassfish 日志系统(例如 Log4j DEBUG)的元信息(如级别) j.u.l 很好)。现在,日志查看者可以访问该数据并对其采取行动。
这就是为什么您不想尽可能只登录到 STDOUT 的原因。最好记录到更高级别,让后面的步骤决定如何呈现它和组织数据。
关于Java 到 rsyslog : STDOUT or syslog?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25536139/