Distributed Tracing

Distributed tracing support in a Mashling instance is achieved via two pieces:

1. The tracer embedded within the Gorilla Mux HTTP trigger.
2. The tracing activity that can be added to Flogo flows to log tracing events when the context is correctly propagated.
3. Native tracing support baked into the REST activity in Mashling.

The tracing implementation is powered by the Golang OpenTracing library here: github.com/opentracing/opentracing-go

Out of the box the HTTP trigger can be configured to support the following distributed tracing solutions:

1. Zipkin
2. AppDash
3. Lightstep

Trigger

The following tracing specific configuration options are available for the Gorilla Mux HTTP trigger:

Key	Description
tracer	The tracer to use: noop, zipkin, appdash, or lightstep
tracerEndpoint	The url or address of the tracer (ZipKin, APPDash)
tracerToken	The token for tracing access (LightStep)
tracerDebug	Debug mode for the tracer (ZipKin)
tracerSameSpan	Put client side and server side annotations in same span (ZipKin)
tracerID128Bit	Use 128 bit ids (ZipKin)

The tracing related output of the trigger (that allows a user to propagate context for instance) is:

Key	Description
tracing	Tracing context

More details on the trigger can be found here: https://github.com/TIBCOSoftware/mashling/tree/master/ext/flogo/trigger/gorillamuxtrigger

Tracing Activity

A new tracing activity has been added. It can be used in any Flogo flow but does require the tracing context to be propagated in order to correctly send the tracing details to the tracing server.

Key inputs and outputs are:

Inputs

Key	Description
tracing	The tracing context to span off of
span	The current span to close

Outputs

Key	Description
tracing	The tracing context to forward
span	The current span to forward

More details and up-to-date examples can be found here: https://github.com/TIBCOSoftware/mashling/tree/master/ext/flogo/activity/tracer

REST Activity

Native tracing support has been added to the default REST activity in Mashling as well. This primarily involves auto ingesting and processing the tracing details if the following tracing context is provided to the activity:

Key	Description
tracing	The tracing context to forward

More details and up-to-date examples can be found here: https://github.com/TIBCOSoftware/mashling/tree/master/ext/flogo/activity/rest

Istio Integration

By default, a Mashling that is using the Gorilla Mux HTTP trigger with tracing enabled and pointing to the Istio instance service name for the Zipkin server will consume the Istio generated tracing context headers and pass them along the flow. This enables visibility into the full request flow from the Istio ingress through to your Mashling process.

An example and walkthrough can be found in the Mashling Recipes Github repository under the recipes/istio/mashling-istio-tracing folder (WIP: not yet merged into master).

Document generated by Confluence on Aug 06, 2018 17:26

Atlassian