-
-
Notifications
You must be signed in to change notification settings - Fork 26
Start tracing send recieve #360
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good to me. Just a small question/comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 3 of 5 files at r1, 1 of 1 files at r3, all commit messages.
Reviewable status: 4 of 5 files reviewed, 2 unresolved discussions (waiting on @hahn-kev and @josephmyers)
the package System.Diagnostics.DiagnosticSource supports all the way back to net462 and lets use configure some distributed tracing which can then be instrumented by our applications. After tracing our sync code in Lexbox, I would like to get a little more insight into what's going on in chorus. I've trace the following:
Tracing is similar to logging so that when no one is listening to the activity source then no activity will be created and it'll be a noop for the code in question. In order to listen to those events with OTEL, you can do something like
service.AddOpenTelemetry().WithTracing(b => b.AddSource(LibChorusActivitySource.ActivitySourceName));
then all the activities configured in this PR will be emit traces and logged in OTEL. I suspect other application tracing frameworks would also tap in to these traces. It could also be used for analytics.
This change is