opentelemetry - zipkin

10 views
Skip to first unread message

Jordi Polo Carres

unread,
Sep 18, 2019, 4:38:18 PM9/18/19
to zipki...@googlegroups.com
Hi,
I was to respond to the "help wanted" email thread with this messagge but do not want to steal it.

About the zipkin-go-opentracing repo, it seems a lot of opentracing has been renamed/moved to opentelemetry https://github.com/open-telemetry
Wouldn't it make more sense to push zipkin backends to thir implemenatations rather than yet another implementation in other repo?

Going further, what does a zipkin client provide that a (future? done? wip?) opentelemetry client with a zipkin backend does not?
Would it be crazy to join forces writing clients (and their exporters to zipkin) and sunset zipkin-only clients?

I am not very familiar with these multiple open-* projects so excuse me if these questions do not make much sense.

Thanks

--

José Carlos Chávez

unread,
Sep 18, 2019, 4:52:56 PM9/18/19
to zipki...@googlegroups.com
Personal answer: I am keeping an eye to those OTel languages I am familiar with and mostly paying attention to reporters (e.g. https://github.com/open-telemetry/opentelemetry-js/pull/192). OTel is a big staffed team (many vendors behind it, guess how many users) so I would say they should not need any help but we should definitively pay attention to exporters because personally I saw past histories where opencensus exporters did a bad use of zipkin data format.

Related to what zipkin provides that OTel does not, zipkin has a quite sophisticated libraries with many features OTel don't based on **user requests** and many (many) meetings of Adrian with users so I would always go for zipkin instrumentation. OTOH OTel is suppose to support OT which means that those willing to use zipkin or OTel can do it over OT.

--
You received this message because you are subscribed to the Google Groups "zipkin-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zipkin-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zipkin-dev/CAM2%2BnKgT64KPSi%3DP8eb0F6t6QchpKZS1VW6W53TfBXAM0KYjcA%40mail.gmail.com.

Jordi Polo Carres

unread,
Sep 18, 2019, 6:24:29 PM9/18/19
to zipki...@googlegroups.com

I guess my question is do zipkin-only clients allow for anything that OT clients will never be able to match?
If not, I think it makes sense for long-term for all tracing people to unite behind one set of clients.
I'm guessing short-term they are pretty much wip and not for production usage.



To view this discussion on the web visit https://groups.google.com/d/msgid/zipkin-dev/CAGZ2AkOwZ8L0owjf6NHP_z8yZJkDfyyu1XsKbHVMmdz6KA8Y%2Bg%40mail.gmail.com.

Adrian Cole

unread,
Sep 18, 2019, 8:12:38 PM9/18/19
to zipki...@googlegroups.com
Jordi, I would recommend trying yourself before suggesting we should blindly unite :) We've been down this road before and I think the various issues have been mentioned many times under 3 different brand names. Issues including constant api drift, lack of user driven demand of features or transparency behind them, extreme cost of collaboration, being put second class citizens etc.

You can come to your own conclusions, which is probably a good next step if conclusions of others aren't helping. That way you can feel the pain before asking us all to take it, especially those who have suffered the same people before multiple times.

-A

To view this discussion on the web visit https://groups.google.com/d/msgid/zipkin-dev/CAM2%2BnKjejPY3jr6bgD%3DAb_Bg5sYZO4Dpsom6KcijCTopc%2B9HMg%40mail.gmail.com.

Adrian Cole

unread,
Sep 18, 2019, 9:47:07 PM9/18/19
to zipkin-dev
PS one day I'll write a generic gist on the problems of blindly going into communities with an idea that magically workload decreases when usually dramatic opposite is the case. To suffice for now, hopefully, is this..

When something isn't user-driven what happens is we end up both with the overhead of tracking and coaxing the other project *and also* having to maintain what users actually use. This is fundamentally why the last 3 vendor things I've worked on fiercely didn't pan out in a way I personally could afford to continue (ex OpenTracing, OpenCensus, w3c context) without abandoning what people actually use. Rich collaborations not only have staff themselves, but routinely hire contractors and have time to sit and argue in meetings etc, and this can happen regardless of whether users are served or not. It is super expensive.

Anyway, probably because some of the things here are more stable, you have time for other work. Consider if it weren't? Let's consider value we manage to deliver to users despite few staff. Here's a quote below from a large site in the last couple weeks by a site who also uses OpenCensus/Telemetry (actually what they use isn't ported and in fact most code is ported from OpenCensus not OpenTracing)


In fact it's a good thing that Zipkin is not getting caught in the hype and outside any lime light. We can move the product optimizing on utility value. One step at a time. It takes lot of time, but payoffs are very good in the long run.

I see and the biggest selling point of Zipkin so far is that the deep integration and out of the box instrumentation in Spring Boot.


To each their own, but I certainly don't wand to learn for the 4th time working with the same people that OTel is just as expensive and futile as the last three times, and throw Zipkin's actual merit under the train meanwhile. I also know others who have attempted to collaborate, rarely succeeded unless paid due to the extreme time commitments needed. You can review for yourself how many volunteers actually succeed in these environments.

I hope this makes sense, and seriously if you want to work on OTel also, there's certainly no exclusive contract :) It would be nice if eventually these projects became more helpful to users and less liability.
To unsubscribe from this group and stop receiving emails from it, send an email to zipkin-dev+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "zipkin-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zipkin-dev+unsubscribe@googlegroups.com.


--

--
You received this message because you are subscribed to the Google Groups "zipkin-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zipkin-dev+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages