-
Notifications
You must be signed in to change notification settings - Fork 344
[Discuss] Tracer is just interface, is it enough? I think it make users difficult to switch implements. #63
Comments
adding an extra layer of indirection via "tracer factory" does not resolve your issue of having to make a decision about the implementation and have some way of representing that decision in every service in your system. I think a more realistic approach is to give all services in your ecosystem a shared library that will be responsible for instantiating a specific implementation of the tracer. You could implement the initialization logic with a factory as you described, if you wish, but each initialization will be fairly specific to the concrete tracer implementation. For example, to create a Jaeger Tracer you need to instantiate and pass certain parameters (sampler, reporter, etc), so doing it via |
A shared lib seems a way to go for one, who focus on developing system. But, as a tracer sky-walking develop, I focus on the easiest way to integrate tracer system to app. As java tracer, the most popular tech is javaagent, by using premain and instrument. In this way, I want to achieve the goal by following OpenTracing Specification: Application developer choose to follow OpenTracing API, but not choose implements. And this system is running on dev env, with noop-impl. When system on line( test or production env), choose a tracer system, use -javaagent to instrument.. No source code need to change. I think this is very import for tracer and system developer. It seems necessary for you or OpenTracing-java? |
I still think the problem you're trying to solve (a) has many different solutions, javaagent being one of them, and (b) is a problem of packaging, dependency injection, deployment. It's not a problem that OpenTracing API itself is trying to solve. I would suggest starting with a personal repository, something like yourname/opentracing-javaagent, developing a prototype there with examples of integrating the app with 2-3 different implementations of OpenTracing (e.g. Jaeger, Lightstep, and there's zipkin/brave/opentracing bridge in the openzipkin project). If you succeed in such prototype, you can move it to the github.com/opentracing-contrib org as a utility package for binding tracing implementations. |
I agree with @yurishkuro: that this is a fundamental software engineering issue that almost certainly can (and, thus, should) be resolved outside of the OpenTracing API itself. |
Thanks a lot. I will review the If I have more questions, I will let you known. Thanks, again. |
@bensigelman @yurishkuro @michaelsembwever
As OpenTracing specification says, one of OpenTracing specification goals is to let application developers to build trace in their application from beginning, and to choose implements later.
I review the api module recently. I think the definition of
interface Tracer
may cause users difficult to switch implements.First, if I am a application developers, in order to use OpenTracing-api, I must
new TracerImp()
. At this time, I must choose a implements to make sure the "new" can be done. This don't match the specification obviously.Other way to do this, I must import opentracing-impl or opentracing-noop module, and
new NoopTracer()
instead. It seems to work. But I am define a tracer many times, when I develop distributed system. When I switch implement to a real tracer, I must change all codes refer to thisnew
operation. It seems not so cool.I recommend to change add a TracerFactory or TracerResolver, to choose a tracer Implment base on some tech. Such as spi, System.getProperty() (use -D main param). TracerFactory or TracerResolver will return the noop-implements in opentracing-noop module.
Or TracerFactory or TracerResolver provide
register
operation to let implements to doWhat's your opinions about this?
If you agree with me, I will send a pull request to provide this api.
Looking forward your replies.
The text was updated successfully, but these errors were encountered: