Camel's tracer interceptor can be used for logging, by default at the
INFO level, a route's execution. The tracer is an instance of
org.apache.camel.spi.InterceptStrategy. It can be applied to either a
DefaultCamelContext or a
SpringCamelContext to ensure that there is a
TracerInterceptor created for every node in the route. The tracer's logging can be enabled/disabled dynamically by calling its
Checkout which dependencies are required by Camel for logging purpose.
From Camel 2.12: the CamelContext must be explicitly configured for tracing:
<camelContext trace="true" ...>
Enable/disable the tracer.
Sets the Trace Formatter to use.
Camel 2.3: Fully qualified class name for a custom
For example you can use your custom JPA @Entity class to store traced information in a database according to your schema layout.
The logging level to use:
The log name to use.
Controls whether the stack trace of a traced exception should be logged. If
An Exchange Predicate to filter the tracing.
Enable/disable tracing of interceptors.
Enable/disable tracing of an exception thrown during the processing of an Exchange.
Camel 2.3: To use a custom
Camel 2.3: To use a custom
Enable/disable fine grained tracing, using a callback, for both
By default only one trace callback is executed.
To use a
The tracer formats the execution of exchanges to log lines. They are logged at
INFO level in the log category:
org.apache.camel.processor.interceptor.TraceInterceptor. By default the tracer uses:
org.apache.camel.processor.interceptor.DefaultTraceFormatter to format the log line.
DefaultTraceFormatter has the following options:
Fixed length of the bread crumb.
Setting a value to e.g.
Limits the number of chars logged per line.
From Camel 2.9: the default value is
Camel 2.18: If
Fixed length of the node.
Setting a value to e.g.
Outputs the unique UnitOfWork for the exchange.
Can be used for correlation to identify a particular Exchange.
Output the exception if the processing of an Exchange has failed.
Enable/disable the output of an Exchange's unique
Currently the breadcrumb is sufficient.
Output the Message Exchange Pattern (MEP).
Previous and destination node.
Output the Exchange's properties.
Camel 2.8: output the
To output the Exchange's unique
Logging stream bodies
ID-claus-acer/3690-1214458315718/2-0is the breadcrumb with the unique correlation id.
node3is the id of the node in the route path. Always displayed.
To[mock:a]is the destination node.
InOnlyis the exchange pattern. Is always shown.
- Then the rest is properties, headers and the body.
The trace log will output both the from and to so you can see where the Exchange came from, such as:
To enable tracer from the main run:
and the tracer will be activated.
Enabling in Java
You can configure tracing at a higher granularity as you can configure it on camel context and then override and set it per route as well. For instance you could just enable the tracer for a particular route.
Configuring in Java
Tracer options can be configured in Java as follows:
Using Predicates to Filter Exchanges
In the code below we want the tracer only to trace if the body contains the text
London. As this is just an example can of course set any Predicate that matches your criteria:
Enabling in Spring XML
There is now a
trace attribute you can specify on the
Another option is to just include a spring XML which defines the Tracer bean such as the one that is automatically included if you run the Main with -t above.
Configuring in Spring XML
You can configure the tracer as a Spring bean. Just add a bean with the bean class
org.apache.camel.processor.interceptor.Tracer and Camel will use it as the tracer.
You can configure the formatting of tracer as a Spring bean. Just add a bean with the
id="traceFormatter" and Camel will lookup this
id and use the associated formatter.
Enable Tracing of
To trace the messages coming out of processing steps configure the tracer as follows:
With these options the output will look like:
Using a Custom Formatter
To create a custom formatter create a class that implements the interface
And here we have our custom logger that implements the
TraceFormatter interface where we can construct the log message how we like:
Using a Destination for Custom Processing and Routing
Tracer supports custom processing of trace events. This can be used to route a trace event to a JPA endpoint for persistence in a database.
This works by Camel creates a new TraceEventMessage containing:
- snapshot of the original traced Exchange as a immutable TraceEventMessage containing String values of the fields, when the interception occurred. This ensures the fields contains the exact data at the given time of interception.
- the original Exchange can in some implementations be accessed using
getTracedExchange()(though with JPA based tracer you cannot get the original Exchange).
Beware to access the original Exchange to avoid causing any side effects or alter its state. Prefer to access the information from TraceEventMessage
Camel routes the
TraceEventMessage synchronously from the point of interception. When its completed Camel will continue routing the original Exchange.
The sample below demonstrates this feature, where we route traced Exchanges to the
Then we can configure a route for the traced messages:
And our processor where we can process the
TraceEventMessage. Here we want to create a CSV format of the trace event to be stored as a file. We do this by constructing the CSV String and the replace the
IN body with our String instead of the
Using JPA as a Datastore for Trace Messages
See Tracer Example for complete documentation and how to use this feature.
Traced Route Path During Runtime
Tracer also traces the actual route path taken during runtime. Camel will store the route path taken on the UnitOfWork when Tracer is enabled. The example below demonstrates how we can use that for error handling where we can determine at which node in the route graph the error triggered.
First we define our route:And then our custom error processor where we can handle the exception and figure out at which node the exception occurred.