htrace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin McCabe <>
Subject Re: What is stopping Htrace from being considered opentracing complient
Date Mon, 20 Mar 2017 18:54:32 GMT
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

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.


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