htrace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <>
Subject Re: What is stopping Htrace from being considered opentracing complient
Date Tue, 21 Mar 2017 01:28:10 GMT
It is also important to note that while aiming to be an
instrumentation api, OT would have to be used a specific way in order
to retain parent semantics in the same way as existing htrace
instrumentation does. For example, if someone writes to the OT api,
with multiple calls to "childOf" reference, it would need to end up
semantically the same as existing HTrace instrumentation or the spans
won't be as usable.

This is very different than the zipkin integration as zipkin does not
require use of a specific programming api. The zipkin integration is a
simple model conversion, rather than something that implies a rewrite
of HDFS instrumentation, for example.

One milestone for an interested contributor would be to make
OpenTracing instrumentation which ends up in HTrace as if it was
written with HTrace's SDK. A proof of concept could attempt to forward
OpenTracing library calls to HTrace core library calls (this is a
typical pattern). It would also need to consider in-process
propagation which is still not yet formalized in OpenTracing. I'd
expect such an experiment to take at least a few days from an
experienced developer.

Once the concept is proven (the OT api has the features needed by
HTrace), a call to formalize such becomes more interesting and

My 2p


On Tue, Mar 21, 2017 at 2:59 AM, Raam Rosh-Hai <> wrote:
> Thank you Colin for the quick and thorough reply, that's just what I was
> looking for. I didn't know what words to use since you can use htrace with
> zipkin, the parents are dropped automatically. The multiple parent thing is
> what I suspected to be "different" in the words of opentracing
> Thanks again,
> On 20 March 2017 at 19:54, Colin McCabe <> wrote:
>> Hi Raam,
>> As you know, OpenTracing is an API which uses other tracing systems as
>> the backend.  So, for example, you can use OpenTracing with a
>> proprietary backend.  Or you can use OpenTracing with Zipkin as the
>> backend.  In this context, the function of the "backend" is to store and
>> process the spans.
>> There was some recent discussion on the mailing list about setting up an
>> OpenTracing connector that would send spans to HTrace.  That sounds like
>> a good initiative, and perhaps that's what you mean by "OpenTracing
>> compliant"?
>> As I remember, the main difference between HTrace and OpenTracing data
>> models was about whether spans should have multiple parents or a single
>> parent.  The single-parent model was simpler to display in GUIs, but it
>> leads to people needing to use other IDs to associate related groups of
>> spans.  This is something we might revisit in the future if there are
>> better ways of doing the same thing, but for now we have multiple
>> parents.  In any case, this will not prevent an OpenTracing-to-HTrace
>> connector from being written if people want one.
>> best,
>> Colin
>> On Mon, Mar 20, 2017, at 09:49, Raam Rosh-Hai wrote:
>> > Hi Guys,
>> >
>> > For my talk about tracing scala application I talk about Htrace and
>> > zipkin,
>> >  After reading the opentracing spec it seems like htrace does follow most
>> > if not all of the open tracing spec, for completeness and correctness I
>> > would really appreciate it if someone can describe what is missing in
>> > order
>> > for Htrace to opentracing implementation.
>> >
>> > I am not implying it's neceserry that htrace should be complaint but I
>> > think it would be interesting to highlights the differences if any
>> > between
>> > the methods.
>> >
>> > Thanks,
>> > Raam

View raw message