Java to rsyslog: STDOUT or syslog?

6
votes

My understanding of rsyslog is that it is a syslog server implementation common on Ubuntu machines.

Futhermore, my understanding is that rsyslog can be used to hook/capture STDOUT output as well as standard syslog messages.

Last, my understanding is that rsyslog can then forward any captured messages (again, either coming from STDOUT or a syslog client) on to another server, such as a log aggregator, or another rsyslog server, etc.

So first off, if anything I have stated above is incorrect, please begin by correcting my understanding of how syslog/rsyslog work and their relationship to each other!

If my assumptions are more or less correct then given the following two options:

  • Option #1: Log to STDOUT and configure rsyslog to capture that stream and forward log messages to a remote process (say a log aggregator); or
  • Option #2: Log to syslog and configure rsyslog to capture it and forward log messages to the same remote process

Given these two options, I would prefer #1 since:

  • When running locally or from an IDE, STDOUT will print to console; and
  • When running on any non-local environment, STDOUT will just get "collected" by rsyslog

If I go with Option #2, I lose console visibility when running locally.

Having said that, are there any security/performance/other concerns/caveats/pitfalls from logging to STDOUT that would make Option #2 more attractive/desirable? If so what are they?

1
javalogginglogstashsyslogrsyslog

1 Answers

5
votes

You should use one of the many loggers (i.e. java.util.logging, etc.) and then configure it as appropriate for each use case. For local testing, configure the logger to STDOUT. For production, configure it for syslog.

By simply logging STDOUT, you lose any meta data provided by the logger, or possibly useable by syslog, since all you can log is the message.

For example, in Glassfish, anything run to STDOUT is logged as INFO to the Glassfish logs.

So, if you're running Log4j to STDOUT, the logs are captured, but what you don't capture is whether they're WARN or DEBUG or whatever. The TAG is captured, as part of the message, but the message is, ostensibly, opaque compared to something run through the logger itself.

If you had configured Log4j to use the Glassfish logger, (which is java.util.logger), then the Glassfish log WOULD capture the meta information (like the level), as mapped to the Glassfish log system (e.g. Log4j DEBUG is j.u.l FINE). Now a log viewer can have access to that data, and act upon it.

This is why you don't want to just log to STDOUT if possible. Better to log to something higher level, and let a later step decide how to render it and organize the data.