[GitHub] camel pull request #2071: camel-aws-xray tracing support

[RovoMe <gi...@git.apache.org>]

GitHub user RovoMe opened a pull request:

    https://github.com/apache/camel/pull/2071

    camel-aws-xray tracing support

    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 ![a service map](https://github.com/RovoMe/camel-rest-dsl-with-spring-security/raw/master/xray_file_upload_serviceMap.png) and actual traces ![an actual trace](https://github.com/RovoMe/camel-rest-dsl-with-spring-security/raw/master/xray_file_upload_trace.png)
    
    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

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/camel/pull/2071.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 #2071
    
----
commit 5fa9786f9d1c8129e8cfae27a90c79509de44680
Author: Roman Vottner <ro...@gmx.at>
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 c0c8074f5bb432abce1e77737605abd8e09ca576
Author: Roman Vottner <ro...@gmx.at>
Date:   2017-10-31T14:11:48Z

    Fixed typo in documentation

----


---

[GitHub] camel pull request #2071: camel-aws-xray tracing support

[RovoMe <gi...@git.apache.org>]

Github user RovoMe closed the pull request at:

    https://github.com/apache/camel/pull/2071


---