-
Notifications
You must be signed in to change notification settings - Fork 73
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
Should I being using this project or opentelemetry-dotnet packages? #88
Comments
OpenTelemetry is a successor of OpenTracing. It is a merger of OpenTracing and OpenCensus. Use OpenTelemetry if it already fits your requirements. |
Actually OpenTracing fits my requirements currently :) |
OK - I just wouldn't invest too much time in this library. If you run into issues/things you don't like with this, I'd try to switch to OpenTelemetry. There's not much going on here anymore. fyi: @jbogard wrote a great blog series about OpenTelemetry integration with .NET as well: https://jimmybogard.com/building-end-to-end-diagnostics-and-tracing-a-primer/ - it also has great information about .NET's built-in "Activity*"-types which you should use if you want to instrument your own .NET library. |
Thanks!
…On Thu, 28 Jan 2021 at 12:01, Christian Weiss ***@***.***> wrote:
OK - I just wouldn't invest too much time in this library. If you run into
issues/things you don't like with this, I'd try to switch to OpenTelemetry.
There's not much going on here anymore.
fyi: @jbogard <https://github.com/jbogard> wrote a great blog series
about OpenTelemetry integration with .NET as well:
https://jimmybogard.com/building-end-to-end-diagnostics-and-tracing-a-primer/
- it also has great information about .NET's built-in "Activity*"-types
which you should use if you want to instrument your own .NET library.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#88 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAZVJWK7F6HW6BAUY6KLD3S4FG2DANCNFSM4WWZDVPQ>
.
|
What does this actually mean for the Jaeger C Sharp client? The only reason I'm using OpenTracing is because that's what the Jaeger C Sharp client uses. I assume at some point that Jaeger and that library will be updated to also use OpenTelemetry. Do you have any insight into that happening? |
The OpenTelemetry-dotnet repository has a built-in "exporter" for Jaeger, so you won't need the existing "Jaeger" NuGet-package anymore: |
Ah, thank you for that info! Does the OpenTelemetry-dotnet library have the ability to bypass the Jaeger Agent and push directly to the Collector (via gRPC for example)? |
I don't know that, sorry. |
@js8080 No, it does not: If you're currently using OpenTracing/Jaeger -> Jaeger Collector then you have three options to migrate to OpenTelemetry (all involving standing up new infrastructure):
|
As the title suggests. I may have this wrong but there seems to be a dual effort in providing libraries to expose tracing data. I'm currently using this package and Jaeger and all works nicely but I also see there are efforts from Microsoft as part of the https://github.com/open-telemetry/opentelemetry-dotnet repo so just wondering which path should I be on?
Thanks
The text was updated successfully, but these errors were encountered: