App Tracing

App tracing allows you to log information when a program is executing. The trace log can then be used for diagnostic purposes such as debugging failures in the program execution.

Tracing is used to help you identify issues with your app (performance of the app or simply debugging an issue) instead of going through stack traces. The use of tracing is particularly useful in a distributed microservice architecture environment where all the apps are instrumented by some kind of tracing framework and while the tracing framework runs in the background, you can monitor each trace in the UI. You can use that to track any abnormalities or issues to identify the location of the problem.

Some Considerations

Keep the following in mind when using the tracing capability in TIBCO Cloud Integration - Flogo (PAYG):

  • At any given point of time only one tracer can be registered - if you try to register multiple tracers, only the first one that you register is accepted and used at run time to trace all the activities of the flow.
  • All the traces start at the flow level. There are two relations between spans - a span is either the child of a parent span or the span is a span that follows (comes after) another span. You should be able to see all the operations and the traces for the flows and activities that are part of an app.
  • Tracing can be done across apps by passing the tracing context from one app to another. To trace across multiple apps, you must make sure that all apps are instrumented with similar sort of tracing frameworks, such as OpenTracing semantics, so that they understand the framework language. Otherwise it will not be possible for you to get a holistic following of the entire trace through multiple services.
  • When looping is enabled for an activity, each loop is considered one span, since each loop calls the server which triggers a server flow.
  • If a span is passed on to the trigger, that span becomes the parent span. You should be able to see how much time is taken between the time the event is received by the trigger and the time the trigger replies back. This only works for triggers that support the extraction of the context from the underlying technology, for instance triggers that support HTTP headers.

    The ReceiveHTTPMessage REST trigger and InvokeRESTService activity are supported for this release where the REST trigger is able to extract the context from the request and InvokeRESTService activity is able to inject the context into the request. If two Flogo apps are both Opentracing-enabled, when one app calls the other, you can see the chain of events (invocation and how much time is taken by each invocation) in the Jaeger UI. If app A is calling app B, the total request time taken by app A is the cumulative of the time taken by all activities in app A plus the time taken by the service that it calls. If you open up each invocation separately, you can see the details of how much time was taken by each activity in that invocation.

  • Triggers that support span (for instance the REST trigger) are always the parent, so any flows that are attached to that trigger are always the child of the trigger span. Trigger span is completed only after the request goes to the flow and the flow returns.
  • A subflow becomes a child of the activity from which it is called.