Notes on StreamBase logging

Note: This article was written for StreamBase® 7.x and previous, and does reflect all changes to the logging subsystem in StreamBase 10 and later.

Use logback rather than log4j

The default slf4j logging backend is logback, and you should keep it that way unless you've got a very good reason not to. It's easy to change the logging backend, but if it's even slightly misconfigured (easy to do), you'll get absolutely no logging output at all so simple things will look mysterious. Also, when using log4j, be aware of various security incidents and mitigations such as https://www.tibco.com/support/notices/2021/12/apache-log4j-vulnerability-update.

Consider turning on configuration file scanning

Another nice thing to do in your logger configuration file is to turn scanning on. This will cause logback to reread your config file so you can do things like increase the log level for everything or just for specific named loggers without restarting the server. So if you pay a little attention to this while you're developing your application you'll use logger names for each subsystem so you can independently change the logging by subsystem to give you more insight into your running application as you need it.

Sample file appender logback.xml file

Here's a simple sbd-logback.xml config file that rolls the logfile hourly, compressing when it logs and also writes to the console. If you want no console output, just comment out the line indicated.

<?xmlversion="1.0"encoding="UTF-8"?>

<configuration scan="true" scanPeriod="30 seconds">
  <appender name="RootFileAppender" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <FileNamePattern>sbd-%d{yyyy-MM-dd_HH}:00.log.gz</FileNamePattern>
    </rollingPolicy>
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
      <level>info</level>
    </filter>
    <encoder>
      <pattern>%d{yyyy-MM-dd HH:mm:ss}, %p, %c, %t %m%n</pattern>
    </encoder>
  </appender>
  <appender name="RootConsoleAppender" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%d{yyyy-MM-dd HH:mm:ss}, %p, %c, %t %m%n</pattern>
    </encoder>
  </appender>
  <root>
    <level value="info"/>
    <appender-refref="RootFileAppender"/>
    <!-- comment out the console appender if you want no output to go to the console -->
    <appender-refref="RootConsoleAppender"/>
  </root>
</configuration>

There are more StreamBase logging examples in the TIBCO Product Support Knowledge Base.

Logback is more powerful than you think

Logback is a wonderfully powerful subsystem in its own right, and generously rewards study when designing logging infrastructures to support production applications. Application architects could do far worse than read the logback docs like a book: you will find yourself leveraging already existing logback facilities rather than re-building them inadvertently using other products. You can often find yourself answering "Yes, no problem" to lots of operations, monitoring, and management kinds of non-functional requirements just by really understanding what logback can do out of the box. You can also do some absolutely crazy stuff using markers and Janino-based code injection via the logback config file. Not for the faint of heart. Yes, really, the logging subsystem -- not quite as boring as you thought.

Read the correct version of the logback documentation

When using logback with StreamBase, you need to be reading the version of the logback docs that ships with the version of StreamBase you are using. This is because if you read the latest logback docs, things will have changed and there will be new great features you will get all excited about that you won't be able to use and, worse, will try to use and spend time wondering why they don't work for you. Have I been there? Yes I have. The logback folks don't keep old versions of the logback docs live on the web, so you have to go download the corresponding logback distribution from https://github.com/qos-ch/logback unpack it, and read the docs included in the logback distribution. We document this process more at http://docs.streambase.com/latest/topic/com.streambase.sb.ide.help/data/html/admin/logging.html#logging_logback-default-config

Consider using JMX to alter logback configuration at runtime

JMX and logback. Another way to tweak the config at runtime is via JMX. Which one is better kind of depends on the policies in place at the user's site. With some foresight and planning you can put together a way to alter log levels dynamically and perhaps use that to gather information about systems running in deployment environments that might otherwise be out of reach or even require a whole change control cycle to tweak. This method also gives the ops team a way to investigate problems without taking drastic action. 

Yes, You Can Use Logback to log to the Windows Event Log

StreamBase 10 ships with a Windows Event Log appender for logback (https://docs.streambase.com/latest/topic/com.streambase.sb.ide.help/data/html/admin/logging-windows.html).

For StreamBase 7.x and prior, one of the historical reasons to use log4j rather than logback has been that log4j had a Windows Event log appender, and logback didn't.There is a Windows Event Log appender for logback of unknown quality, so evaluate on your own: http://ykchee.blogspot.com/2012/09/logback-nt-event-log-appender.html

Use a non-default logback configuration file name

[Note: this tip applies only to StreamBase 7.x and prior.]

The default logback configuration file is logback.xml, but you shouldn't use that filename. All of our command line tools and lots of third party tools use logback so if your configuration file is called logback.xml then running any of those commands in the same directory will cause them to write data into your log files, which can be very confusing. So I usually name my logback configuration files something like sbd-logback.xml. Then I put the following sysproperty into my sbconf file (in the java-vm section):

 <syspropertyname="logback.configurationFile"value="sbd-logback.xml"/>