6

I am using Logback in my application hosted on Websphere App Server. Logback is configured to log to System Out (and others are hesitant to change to a different file). The issue is that Websphere uses its own format for logging to System Out. Executing logger.debug("test") in my app yields:

[8/7/12 12:27:55:629 CDT] 0000003a SystemOut     O DEBUG com.myapp... test

where everything up to the "O" is added by Websphere. The rest is from Logback

I have set up Logback to use the following pattern: %-5level %logger{36} - %msg%n so that I don't repeat timestamp and thread info which Websphere does on its own, but I am still annoyed that I can't fully customize the logging to System Out from within Logback.

I don't know a whole lot about logging best practices. Before, I have logged to separate files by web app, but for this project, I was told the System Out files are monitored by a third party and I should not change from using System Out. Is there any way to get around my issue given these requirements and tell Websphere not to mess with my System Out logging, or is the only solution to start logging to a different file? Thanks!

stephen.hanson
  • 9,014
  • 2
  • 47
  • 53

3 Answers3

3

Your logback is configured to write messages to System.out. However, everything that is written to System.out is redirected by WebSphere and written to the SystemOut.log file with the same format as log messages produced by WebSphere, but with a severity indicator "O". It is not possible to change that.

Note that it is likely that the people who told you to use SystemOut.log actually meant that you should ensure that logging is done using WebSphere's log system so that messages are written with the correct category and severity and that log levels can be changed at runtime. Since WebSphere's log system is build on java.util.logging you should probably just replace logback by slf4j-jdk14 to satisfy their requirement.

Andreas Veithen
  • 8,868
  • 3
  • 25
  • 28
  • He said they required SystemOut.log because that file is monitored by a 3rd-party, which isn't surprising to me. We have external tools which monitor log files ourselves, although we can tell those tools to monitor other files. (It would be better, IMO, if you could persuade the 3rd-party to monitor an additional file for you, although if the format is different, their monitoring might have to change as well.) – dbreaux Aug 08 '12 at 20:11
2

I don't think you're going to be able to change the format. And if you could, it might break the current monitoring anyway.

I wonder if anyone would mind if you log to two loggers at the same time, SystemOut for the existing monitoring, and your own for a more readable format.

dbreaux
  • 4,982
  • 1
  • 25
  • 64
  • Two loggers is a good idea. It would be nice for the dev team to have their own one log file and the monitoring team a separate one. – stephen.hanson Aug 09 '12 at 13:55
0

The problem is that Logback redirects the messages to console output instead of java.util.logging. Console output has no log levels and that's why WebSphere just writes "O".

We solved this by implementing a Logback appender that redirects logs to JUL (java.util.logging) instead. We convert Logback log levels to JUL levels (e.g. Logback "ERROR" is JUL "SEVERE").

We also wanted to use Websphere's trace options. If trace is enabled for a class/package pattern, you will see Logback DEBUG and TRACE messages in Websphere's trace.log. You can also check if the trace is enabled by calling Logback's isDebugEnabled() / isTraceEnabled().

See this answer with a full implementation: https://stackoverflow.com/a/74386323/395879

fishbone
  • 3,140
  • 2
  • 37
  • 50