Hello,
Would it then be OK to build a PoC to add OpenTracing capabilities
around the Function executions? My goal is not to trace the internals of
OpenWhisk, but rather provide tracing capabilities to the functions
deployed into it.
- Juca.
On 06/14/2017 03:31 PM, Sandeep Paliwal wrote:
Hi Juca,
the current tracing changes integrate with the existing logging in OpenWhisk.
OpenWhisk logs messages which can be considered logical units in processing of
and action invocation. The tracing PR adds tracing capability to this existing
mechanism.
Zipkin library used supported Akka framework and made it easy to integrate
with. I have not explored Opentracing but once the tracing itself is made
pluggable it will be just a matter of individual preference.
thanks,
Sandeep
On 2017-06-14 16:51 (+0530), Juraci Paixão Kröhling <[email protected]>
wrote:
On 06/14/2017 12:31 PM, Michael Marth wrote:
I was in discussions with Sandeep before he created the PR for Zipkin support,
so I can give some background info:
Thanks for the info! I have a couple more questions, if you wouldn't mind.
As a part of better understanding and improving the performance characteristics
of OW we were simply looking for a way to profile the whole system. Zipkin
seemed (still seems) to be fit for that job. So from our perspective
plugability was not much of a concern, we “simply†wanted to get to the
data.
Is that for tracing OW internals (like a logging mechanism), or to
provide distributed tracing capabilities to functions?
Also, any pointers as to why the usage of Zipkin directly, and not
Zipkin's OpenTracing-compatible libraries? Perhaps you need some Zipkin
feature that's not part of the OT standard?
- Juca.
