[kstenerud]

Or you could just adopt https://opentelemetry.io/ and then everyone can benefit from all OT enabled libraries without having to write extra code, and you won't have to rewrite in order to change implementations since it's just an API.

The go implementation of OT makes extensive use of the Context [1] object to support tracing, logging, and metrics. You write once, and then the user only needs to decide which exporter to use, and possibly filters to apply.

[1] https://golang.org/pkg/context/

[owaislone]

I think what OP is getting at is more like how to manually instrument your code. You can use OpenTelemetry but you might still want to manually instrument code using OpenTelemetry and that involves making calls to records metrics, create spans etc. The pattern OP is proposing fits perfectly well with using something like OpenTelemetry.

[gobwas]

As a library developer, don't you need to define exactly the same trace points (hooks) in your code?

Am I understand it right, that you suggest instead of doing it in a generic way (any tracing method could be plugged in this way), to stick to one particular library?

[kstenerud]

Yes, because then the library developer can define all of the things that COULD be interesting, and leave it to the user of the library to decide WHAT to record (filters), and WHERE to record it (exporters).

And since this is a standard, it means that when a user includes a bunch of disparate libraries/remote calls in his app, he can define his instrumentation wishes once for everything during app initialization. The libraries can even cooperate since they use the same underlying API and concepts for instrumentation.

[gobwas]

> Yes, because then the library developer can define all of the things that COULD be interesting, and leave it to the user of the library to decide WHAT to record (filters), and WHERE to record it (exporters).

I agree that this uppercase words can be called as somewhat purposes of the tracing API. I believe also that I was talking exactly about the same approach in the article. But I can't get how sticking to one particular library will help here? In other words, I think it will just greatly reduce the usage options.

What Im saying is that you can leave the generic hooks in the library (as it described in the article and gtrace) and then let the user choose which library to use inside what hooks.

[kstenerud]

With a standard library and API that everyone adheres to, you just pass in some initial configuration during app initialization to decide which libraries record what kinds of information. The user only touches one file to enable and choose instrumentation.

With hooks, you get nothing unless you hook, which means you have to write hooks for everything you're interested in (and also come up with a way to export the data), and so the user must touch code all over the place.

[filipn]

Is opentelemetry ready for production usage? As my understanding this project is a merge between OpenCensus and OpenTracing, but it’s still in beta and the documentation is really lacking. Does anyone have any hands-on experience with this library?

[owaislone]

SDKs for languages are in beta and might not be production ready but the collector is production ready. You can use any of the OpenTracing or OpenCensus instrumentation libraries but deploy the OpenTelemetry collector and once Otel SKDs mature, migrate OC/OT to Otel or not if you don't want to.

[kstenerud]

I've used it, and it's very similar to OpenCensus and OpenTracing. If you've used either, it's not much of a stretch to use OpenTelemetry.

That said, it is still beta, and will be until Q4.

[zeveb]

What happened to OpenTracing?

[sharms]

OpenTelemetry is the project formed from the merger of OpenTracing and OpenCensus, under the CNCF: https://opentelemetry.io/about/