Child pages
  • Log
Skip to end of metadata
Go to start of metadata

Log Component

The log: component logs message exchanges to the underlying logging mechanism.

Camel uses sfl4j which allows you to configure logging via, among others:

URI format

Where loggingCategory is the name of the logging category to use. You can append query options to the URI in the following format, ?option=value&option=value&...

Using Logger instance from the the Registry

As of Camel 2.12.4/2.13.1, if there's single instance of org.slf4j.Logger found in the Registry, the loggingCategory is no longer used to create logger instance. The registered instance is used instead. Also it is possible to reference particular Logger instance using ?logger=#myLogger URI parameter. Eventually, if there's no registered and URI logger parameter, the logger instance is created using loggingCategory.

For example, a log endpoint typically specifies the logging level using the level option, as follows:

The default logger logs every exchange (regular logging). But Camel also ships with the Throughput logger, which is used whenever the groupSize option is specified.

Also a log in the DSL

There is also a log directly in the DSL, but it has a different purpose. Its meant for lightweight and human logs. See more details at LogEIP.

Options

Option

Default

Type

Description

groupActiveOnly

true

boolean

If true, will hide stats when no new messages have been received for a time interval.

If false, show stats regardless of message traffic

groupDelay

0

Integer

Set the initial delay for stats (in millis)

groupInterval

null

Integer

If specified will group message stats by this time interval (in millis)

groupSize

null

Integer

An integer that specifies a group size for throughput logging.

level

INFO

String

Logging level to use. Possible values: ERROR, WARN, INFO, DEBUG, TRACE, OFF

logger

 

Logger

Camel 2.12.4/2.13.1: An optional reference to org.slf4j.Logger from Registry to use.

marker

null

String

Camel 2.9: An optional Marker name to use.

 


groupDelay and groupActiveOnly are only applicable when using groupInterval.

 

Formatting

The log formats the execution of exchanges to log lines. 

By default, the log uses LogFormatter to format the log output, where LogFormatter has the following options:

Option

Default

Description

maxChars

 

Limits the number of characters logged per line. The default value, from Camel 2.9 is 10000.

multiline

false

If true, each piece of information is logged on a new line.

showAll

false

Quick option for turning all options on. (multilinemaxChars has to be manually set if to be used)

showBody

true

Show the IN body.

showBodyType

true

Show the IN body Java type.

showCaughtException

false

If the exchange has a caught exception, show the exception message (no stack trace).

A caught exception is stored as a property on the exchange (using the key Exchange.EXCEPTION_CAUGHT) and for instance a doCatch can catch exceptions.

See Try Catch Finally.

showException

false

If the exchange has an exception, show the exception message (no stack trace).

showExchangeId

false

Show the unique exchange ID.

showExchangePattern

true

Shows the Message Exchange Pattern (or MEP for short).

showFiles

false

Camel 2.9: Whether Camel should show file bodies or not, e.g., such as java.io.File.

showFuture

false

Whether Camel should show java.util.concurrent.Future bodies or not. If enabled Camel could potentially wait until the Future task is done. Will not wait, by default.

showHeaders

false

Show the IN message headers.

showOut

false

If the exchange has an OUT message, show the OUT message.

showProperties

false

Show the exchange properties.

showStackTrace

false

Show the stack trace, if an exchange has an exception. Only effective if one of showAll, showException or showCaughtException are enabled.

showStreams

false

Camel 2.8: Whether Camel should show stream bodies or not, e.g., such as java.io.InputStream.

If you enable this option then you may not be able later to access the message body as the stream have already been read by this logger.

To remedy this you will have to use Stream caching.

skipBodyLineSeparator

true

Camel 2.12.2: Whether to skip line separators when logging the message body. This will log the message body on a single line.

Set to false to preserve any line separators present in the body, therefore logging the body as is.

Logging stream bodies

For older versions of Camel that do not support the showFiles or showStreams properties above, you can set the following property instead on the CamelContext to log both stream and file bodies:

Regular Logger Example

In the route below we log the incoming orders at DEBUG level before the order is processed:

Or using Spring XML:

Regular Logger with Formatter

In the route below we log the incoming orders at INFO level before the order is processed.

Throughput Logger With groupSize

In the route below we log the throughput of the incoming orders at DEBUG level grouped by 10 messages.

Throughput Logger With groupInterval

This route will result in message stats logged every 10s, with an initial 60s delay and stats should be displayed even if there isn't any message traffic.

The following will be logged:

Full Customization of the Logged Output

Available as of Camel 2.11

With the options outlined in the #Formatting section, you can control much of the output of the logger. However, log lines will always follow this structure:

This format is unsuitable in some cases, perhaps because you need to:

  • Filter the headers and properties that are printed, to strike a balance between insight and verbosity.
  • Adjust the log message to whatever you deem most readable.
  • Tailor log messages for digestion by log mining systems, e.g. Splunk.
  • Print specific body types differently.
  • Etc.

Whenever you require absolute customization, you can create a class that implements the ExchangeFormatter interface. Within the format(Exchange) method you have access to the full Exchange, so you can select and extract the precise information you need, format it in a custom manner and return it. The return value will become the final log message.

You can have the Log component pick up your custom ExchangeFormatter in one of two ways:

Explicitly instantiating the LogComponent in your Registry

Convention Over Configuration

Simply by registering a bean with the name logFormatter; the Log Component is intelligent enough to pick it up automatically.

The ExchangeFormatter gets applied to all Log endpoints within that Camel Context. If you need a different ExchangeFormatter for each endpoint, just instantiate the LogComponent as many times as needed, and use the relevant bean name as the endpoint prefix.

From Camel 2.11.2/2.12: when using a custom log formatter, you can specify parameters in the log URI, which gets configured on the custom log formatter. Though when you do that you should define the logFormatter as prototype scoped so its not shared if you have different parameters.

Example:

And then we can have Camel routes using the log URI with different options:

Using Log Component in OSGi

Improvements from Camel 2.12.4/2.13.1

When using Log component inside OSGi (e.g., in Karaf), the underlying logging mechanisms are provided by PAX logging. It searches for a bundle which invokes org.slf4j.LoggerFactory.getLogger() method and associates the bundle with the logger instance. Without specifying custom org.sfl4j.Logger instance, the logger created by Log component is associated with camel-core bundle.

In some scenarios it is required that the bundle associated with logger should be the bundle which contains route definition. To do this, either register a single instance of org.slf4j.Logger in the Registry or reference it using logger URI parameter.

See Also

  • No labels

0 Comments