Re: Adding OpenTracing support

[Rodric Rabbah <ro...@gmail.com>]

I'm summarizing below a discussion with Juraci Paixão Kröhling regarding PR
2413 [1] for integrating OpenTracing with OpenWhisk for the benefit of the
dev list so that interested parties can add their input.

While superficially there is some overlap with another tracing PR (2282)
[2], it became evident upon discussion that the goals are different.

In 2413, the goal is to trace the execution of actions and make the elapsed
duration of of actions visible to end users. Each action execution
constitutes a measurement which might include components outside of
OpenWhisk. This allows a system consisting of REST APIs implemented in a
mix of serverless and microservices approach to trace the overall execution
time of a transaction in the system.

Since this trace data is intended to be visible to end users and hence has
to be segregated between users in a multi-tenant solutions, an alternate
solution we discussed, compared to the one offered in the PR, is to do add
this functionality entirely at user level. This can be done for example
with a new runtime kind which supports tracing. When using such a runtime
kind, a user then has the option of making available credentials and
coordinates for its desired tracing backend. The runtime can just implement
the required wrapping around functions for measuring the span. This doesn't
preclude tracing around user actions intrinsically in the system but defers
the need to that immediately until some of the usages issues are better
worked out. A third option that was also briefly discussed piggy backs on
the activation records which already measures the desired intervals and
recording that in the tracing service.

We agreed that OpenTracing in general is superior to locking into a
specific framework like Zipkin and at some point 2282 should be migrated to
use OpenTracing APIs instead. But we should consider the two PRs
separately. I expect we'll have more discussions on this as it's a topic of
interest to many.

-r

[1] https://github.com/apache/incubator-openwhisk/pull/2413
[2] https://github.com/apache/incubator-openwhisk/pull/2282

Re: Adding OpenTracing support

[Sandeep Paliwal <sa...@gmail.com>]

Hi,
Thanks for the updates Rabbah.
Regarding use of zipkin or OpenTracing I guess once we have made OpenWhisk pluggable this issue can be addressed and it will be upto individual preference which tracing to plug in. Although this will require some core changes in OpenWhisk to support this. 

thanks,
Sandeep

On 2017-07-25 21:45 (+0530), Rodric Rabbah <ro...@gmail.com> wrote: 
> I'm summarizing below a discussion with Juraci Paixão Kröhling regarding PR
> 2413 [1] for integrating OpenTracing with OpenWhisk for the benefit of the
> dev list so that interested parties can add their input.
> 
> While superficially there is some overlap with another tracing PR (2282)
> [2], it became evident upon discussion that the goals are different.
> 
> In 2413, the goal is to trace the execution of actions and make the elapsed
> duration of of actions visible to end users. Each action execution
> constitutes a measurement which might include components outside of
> OpenWhisk. This allows a system consisting of REST APIs implemented in a
> mix of serverless and microservices approach to trace the overall execution
> time of a transaction in the system.
> 
> Since this trace data is intended to be visible to end users and hence has
> to be segregated between users in a multi-tenant solutions, an alternate
> solution we discussed, compared to the one offered in the PR, is to do add
> this functionality entirely at user level. This can be done for example
> with a new runtime kind which supports tracing. When using such a runtime
> kind, a user then has the option of making available credentials and
> coordinates for its desired tracing backend. The runtime can just implement
> the required wrapping around functions for measuring the span. This doesn't
> preclude tracing around user actions intrinsically in the system but defers
> the need to that immediately until some of the usages issues are better
> worked out. A third option that was also briefly discussed piggy backs on
> the activation records which already measures the desired intervals and
> recording that in the tracing service.
> 
> We agreed that OpenTracing in general is superior to locking into a
> specific framework like Zipkin and at some point 2282 should be migrated to
> use OpenTracing APIs instead. But we should consider the two PRs
> separately. I expect we'll have more discussions on this as it's a topic of
> interest to many.
> 
> -r
> 
> [1] https://github.com/apache/incubator-openwhisk/pull/2413
> [2] https://github.com/apache/incubator-openwhisk/pull/2282
>