openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodric Rabbah <>
Subject Re: Adding OpenTracing support
Date Tue, 25 Jul 2017 16:15:55 GMT
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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message