openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandeep Paliwal"<>
Subject Re: Adding OpenTracing support
Date Wed, 26 Jul 2017 10:51:08 GMT
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. 


On 2017-07-25 21:45 (+0530), Rodric Rabbah <> 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]
> [2]

View raw message