Just a second...

Logging reference

Messages logged by the Diffusion™ server are logged at different levels depending on their severity.

Log levels

Diffusion events are logged at different levels of severity. The log levels, ordered from most severe to least severe, are as follows:

Table 1. Log levels
Level Description
ERROR Events that indicate a failure.
WARN Events that indicate a problem with operation.
INFO Significant events.
DEBUG Verbose logging. Not usually enabled for production.
TRACE High-volume logging of interest only to Push Technology Support. Push Technology Support may occasionally ask you to enable this log level to diagnose issues.
Warning: Logging can use considerable CPU resources. In a production environment, enable only significant log messages (INFO and above). Performance degrades significantly when running at finer logging levels as more messages are produced, each requiring processing.

Log format

Log messages output by the Diffusion default logging back-end are output in the following format.

Each log line is made up of a number of fields. All of the fields except for the Exception are formatted on a single line, delimited by pipe (|) characters.

yyyy-MM-dd HH:mm:ss.SSS|Level|Thread|Code|Message|LoggerName Exception

If you use log4j2 as your logging back-end it also produces output in this format if you use the provided Log4j2.xml configuration file. However, you can edit the configuration file to change the log format. For more information, see Configuring log4j2.

Note: Sometimes log messages that are output to the same location as Diffusion messages can be from other products. You can see which messages are Diffusion messages by looking for the message code of the format PUSH-XXXXXX. All messages that Diffusion outputs at INFO level or above include this code.

The meaning of each field is described in the following table.

Table 2. Fields included in the logs
Field Optional or Mandatory Format/values stable between releases Description
Time stamp Mandatory Yes

The time and date the log event occurred.

Asynchronous logging is enabled by default. The server might log a message in a different thread to the one that produced the log event, and at a slightly later time. Consequently, log lines might not be logged in exact time stamp order.

The time stamp is displayed using the timezone configured for the Java Virtual Machine (JVM) running the server. The date format can be changed in the Server.xml configuration file.

Level Mandatory Yes The log severity, using the SLF4J levels: ERROR, WARN, INFO, DEBUG, TRACE.
Thread Mandatory No The name of the Java™ thread that logged the event.
Code Optional Yes

Diffusion log messages have a unique code. For example, PUSH-000123. For more information, see .

All messages at that are logged at INFO or above are documented.

Message Mandatory No A natural language description of the event.
Logger name Mandatory No The logger name. Usually the fully qualified name of the Java class that produced the event.
Exception Optional No If the log event has an associated Java Throwable, the exception message and stack trace directly follows the message line.

Optional fields are empty if the log event does not have the information.

The third column indicates whether fields are stable between releases. Where possible, Push Technology will not change the format or values of these fields so they can be relied on for automated log monitoring. The fields not marked as stable are more likely to change between releases, including patch releases.

Log message examples

The following examples show the log format output by the Diffusion default logging back-end. Log4j2 also produces output in this format if you use the provided Log4j2.xml configuration file.

Most log messages are formatted on a single line.

2016-02-19 14:01:31.199|INFO|main|PUSH-000159|The maximum message size is 32768 bytes.|com.pushtechnology.diffusion.DiffusionController

If a log event has an exception, the exception message and stack trace directly follows the message line. The exception can span multiple lines.

2016-02-19 14:14:54.095|ERROR|main|PUSH-000164|Diffusion Server not started.|com.pushtechnology.diffusion.api.server.DiffusionServer
com.pushtechnology.diffusion.server.security.persistence.store.StoreException: Error parsing SystemAuthentication.store
	at com.pushtechnology.diffusion.server.security.persistence.store.systemauthentication.DSLSystemAuthenticationProvider.parse(DSLSystemAuthenticationProvider.java:67)
	at com.pushtechnology.diffusion.server.security.persistence.store.AbstractFileProvider.connect(AbstractFileProvider.java:102)
	at com.pushtechnology.diffusion.server.security.persistence.store.AbstractStoreImpl.getModel(AbstractStoreImpl.java:71)
	at com.pushtechnology.diffusion.server.security.authentication.systemhandler.SystemAuthenticationHandler.<init>(SystemAuthenticationHandler.java:47)
	at com.pushtechnology.diffusion.server.security.persistence.store.systemauthentication.SystemAuthenticationStoreImpl.newHandler(SystemAuthenticationStoreImpl.java:75)
	at com.pushtechnology.diffusion.server.security.authentication.AuthenticationManagerProvider.provide(AuthenticationManagerProvider.java:107)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)

Log headers

Currently, log files output by the Diffusion default logging back-end start with a special header.

2016-02-19 14:14:53.376 : Starting log for Diffusion 5.7.0_01 (Server) 29689@tangerine (2016-02-08 12:22:07)

Do not depend on this header. In a future release, this header will be replaced with a standard log message.

This does not apply to log files output by log4j2 or other third-party SLF4J implementations.

Log stopped

When the Diffusion default logging back-end rotates the log files, it outputs the message Log stopped at the end of the log file before creating a new log file and continuing to log messages in that new file.

This does not apply to log files output by log4j2 or other third-party SLF4J implementations.