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:
log:loggingCategory[?options]
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&...
For example, a log endpoint typically specifies the logging level using the level
option, as follows:
log:org.apache.camel.example?level=DEBUG
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.
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. |
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. (multiline , maxChars 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 . |
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. |
Regular Logger Example
In the route below we log the incoming orders at DEBUG
level before the order is processed:
from("activemq:orders")
.to("log:com.mycompany.order?level=DEBUG")
.to("bean:processOrder");
Or using Spring XML:
<route>
<from uri="activemq:orders"/>
<to uri="log:com.mycompany.order?level=DEBUG"/>
<to uri="bean:processOrder"/>
</route>
In the route below we log the incoming orders at INFO
level before the order is processed.
from("activemq:orders")
.to("log:com.mycompany.order?showAll=true&multiline=true")
.to("bean:processOrder");
Throughput Logger With groupSize
In the route below we log the throughput of the incoming orders at DEBUG
level grouped by 10 messages.
from("activemq:orders")
.to("log:com.mycompany.order?level=DEBUG&groupSize=10")
.to("bean:processOrder");
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.
from("activemq:orders")
.to("log:com.mycompany.order?level=DEBUG&groupInterval=10000&groupDelay=60000&groupActiveOnly=false")
.to("bean:processOrder");
The following will be logged:
"Received: 1000 new messages, with total 2000 so far. Last group took: 10000 millis which is: 100 messages per second. average: 100"
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:
Exchange[Id:ID-machine-local-50656-1234567901234-1-2, ExchangePattern:InOut,
Properties:{CamelToEndpoint=log://org.apache.camel.component.log.TEST?showAll=true,
CamelCreatedTimestamp=Thu Mar 28 00:00:00 WET 2013},
Headers:{breadcrumbId=ID-machine-local-50656-1234567901234-1-1}, BodyType:String, Body:Hello World, Out: null]
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
<bean name="log" class="org.apache.camel.component.log.LogComponent">
<property name="exchangeFormatter" ref="myCustomFormatter"/>
</bean>
Convention Over Configuration
Simply by registering a bean with the name logFormatter
; the Log Component is intelligent enough to pick it up automatically.
<bean name="logFormatter" class="com.xyz.MyCustomExchangeFormatter"/>
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:
<bean name="logFormatter" class="com.xyz.MyCustomExchangeFormatter" scope="prototype"/>
And then we can have Camel routes using the log URI with different options:
<to uri="log:foo?param1=foo&param2=100"/>
<!-- ... -->
<to uri="log:bar?param1=bar&param2=200"/>
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.