Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify tracing algebras #194

Closed
Fristi opened this issue Jul 24, 2020 · 2 comments
Closed

Unify tracing algebras #194

Fristi opened this issue Jul 24, 2020 · 2 comments

Comments

@Fristi
Copy link
Contributor

Fristi commented Jul 24, 2020

The idea behind defining a service there can exist multiple implementations like opentracing, opentelemetry, honeycomb etcetera. Now we've defined per tracing solution a seperate module, but I think it's a great idea to unify this like github.com/tpolecat/natchez/ does

WDYT?

@runtologist
Copy link
Member

IMO that totally makes sense. The first version of the library had that abstraction. However, OpenTelemetry still was in early alpha by then. We would have had to guess half of the API and we needed a working OpenTracing implementation, hence the split. By now we understand the domain much better I guess. We would probably need some kind of modules, as not all functionality is available through all libraries.

@duxet
Copy link
Contributor

duxet commented Feb 9, 2021

OpenTelemetry seems to be getting close to stable release, so IMHO it would be better to focus on adding full support for it, rather than trying to keep additional layer of abstraction for already obsolete OpenTracing/OpenCensus or single vendor standards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants