GitHub user RovoMe opened a pull request:
https://github.com/apache/camel/pull/2072
camel-aws-xray tracing support
As requested by @oscerd I open the PR for the master-branch this time. I
copy over the other information from the original `2.19.x` branch PR #2071
---
Added support for AWS XRay tracing (similar to OpenTracing) which tracks
the lifecycle of the exchange and invoked EIPs and bean/processors and adds the
gathered information to AWS XRay segments. The code itself is currently added
to the `2.19.x` branch as we still use `2.19.1` internally.
AWS XRay will send the data to a [locally running
daemon](http://docs.aws.amazon.com/xray/latest/devguide/xray-daemon.html)
listening on UDP port 2000 which sends the gathered data to AWS and presents it
as visualization as for service maps 
and actual traces 
In the trace image above, a segment corresponds to the bold entries, like
`api-file-upload` and `process-file` while anything indented is a subsegment of
the corresponding segment.
The code itself does create a new AWS XRay segment for a new exchange
unless there is already an active segment available within the threads context.
AWS XRay manages its segments on a thread-local basis and discards any
information gathered in case a new segment is spawned although an already
active segment is present in the threads context. To circumvent data loss, the
implementation will check first if already an active segment is present in the
current threads context and only then create a new one. If already an active
segment is present (in case of `.to("direct:foo")` the creation of a new
exchange will add a subsegment to the current segment. As multicast with
parallel processing enabled will spawn new threads in a separate thread, the
segment is copied over via an exchange property and set manually for threads
which name contains a multicast name.
The images above contains only traces of `.bean(...)` and `.process(...)`
instances which are a annotated with `@XRayTrace`. This annotation is processed
by TraceAnnotatedTracingStrategy which adds subsegments for the respective
beans to the AWS XRay segment. If no tracing strategy (= InterceptStrategy) is
configured, this implementation will default to a `NoopTracingStrategy` which
as its name suggest will do nothing. A very simple `EIPTracingStrategy` is also
provided which adds subsegments for the currently processed
`ProcessorDefinition`s short name to the current segment.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/RovoMe/camel feature/camel-aws-xray-tracer
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/2072.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2072
----
commit 1a414b83fd86c35904fcd43620b9a59e61ad6f8d
Author: Roman Vottner <[email protected]>
Date: 2017-10-31T10:44:13Z
Added support for AWS XRay tracing of Camel's exchange routing capabilities
which works similar to the OpenTracing tracer support camel-opentracing
provides. This implementation differs, however, slightly from the one of
OpenTracing due to the thread-local nature of an AWS XRay segment and its
behavior if a new segment is created if already an existing segment is present
in the context of the current thread. Upon exchange creation it is first
checked whether an existing segment is already present. If not, a new one will
be created otherwise a subsegment will be created and added to the existing
segment. In case of a multicast the segment is copied over via exchange
properties to the intermediary thread created for initializing the respective
threads otherwise it wont be able to take notice of the previous segment it
belongs to.
By default no tracing strategy (= InterceptStragegy) is applied though a
tracing subsegment can be created on utilizing EIPTracingStrategy. If only
@XRayTrace annotated beans and processors (which keep the actual business logic
in it in our case) should be tracked TraceAnnotatedTracingStrategy can be used
instead.
commit 3a28628fd53ae3cddf323011920ac6926403beee
Author: Roman Vottner <[email protected]>
Date: 2017-10-31T14:11:48Z
Fixed typo in documentation
----
---
