-
Notifications
You must be signed in to change notification settings - Fork 765
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
Add Sdk.SuppressInstrumentation #960
Conversation
private static TimeSpan defaultPushInterval = TimeSpan.FromSeconds(60); | ||
private static readonly TimeSpan DefaultPushInterval = TimeSpan.FromSeconds(60); | ||
|
||
private static readonly RuntimeContextSlot<bool> SuppressInstrumentationRuntimeContextSlot = RuntimeContext.RegisterSlot<bool>("otel.suppress_instrumentation"); |
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.
This would help the exporters/processors to quickly look up the suppress_instrumentation flag without a hash lookup.
Codecov Report
@@ Coverage Diff @@
## master #960 +/- ##
==========================================
+ Coverage 68.24% 68.46% +0.21%
==========================================
Files 218 218
Lines 5955 5961 +6
Branches 969 969
==========================================
+ Hits 4064 4081 +17
+ Misses 1623 1611 -12
- Partials 268 269 +1
|
{ | ||
object slot; | ||
Slots.TryGetValue(name, out slot); | ||
return (RuntimeContextSlot<T>)slot; |
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.
Will this cause a cast exception if the the TryGet fails?
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.
Yes it will. I expect consumers to call this once, and cache the slot for subsequent use (similar like what I did for the Sdk
).
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.
Perhaps I should just use (RuntimeContextSlot<T>)Slots[name]
?
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.
I think that will throw a key not found. I'm just noting your comment
<returns>The slot previously registered, or null if not found.</returns>
Seems like the TryGetValue is a good way to go and just return null if that fails. Was that your intent?
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.
I've updated the code and also the PR description to show my current approach/thinking.
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.
👍 ok yea I get it, thanks.
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.
Also, the using
idea is interesting - maybe we try on for size what you have here, and refactor if we like it?
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.
Yeah, I think we will have better understanding of how syntactical sugar will help exporters/processors/instrumentation when we start to add the code.
|
||
private static readonly RuntimeContextSlot<bool> SuppressInstrumentationRuntimeContextSlot = RuntimeContext.RegisterSlot<bool>("otel.suppress_instrumentation"); | ||
|
||
public static bool SuppressInstrumentation |
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.
- We should have XML comments here. Important spot :) Not sure exactly how to word it though?
/// <summary>
/// Gets or sets a value indicating whether or not <see cref="Activity"/>Activity</see> object collection in the current context should be suppressed (dsiabled). Default value: False.
/// </summary>
/// <remarks>
/// Set <see cref="SuppressInstrumentation"/> to <see langword="true"/> when you want to turn off automatic <see cref="Activity"/> collection.
/// This is typically done to prevent infinte loops created by collection of internal operations, such as exporting spans over HTTP.
/// <code>
/// public override async Task<ExportResult> ExportAsync(IEnumerable<Activity> batchActivity, CancellationToken cancellationToken)
/// {
/// Sdk.SuppressInstrumentation = true;
/// try
/// {
/// await this.SendBatchActivityAsync(batchActivity, cancellationToken).ConfigureAwait(false);
/// return ExportResult.Success;
/// }
/// finally
/// {
/// Sdk.SuppressInstrumentation = false;
/// }
/// }
/// </code>
/// </remarks>
- Should context be in the prop name?
SuppressInstrumentationOnCurrentContext
? Trying to hint to users what it is doing.
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.
- We should have XML comments here. Important spot :) Not sure exactly how to word it though?
Good catch, will add it.
- Should context be in the prop name?
SuppressInstrumentationOnCurrentContext
? Trying to hint to users what it is doing.
Not sure, the proposed name seems too long 😅
Perhaps the XML comment should address this?
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.
What if it wasn't exposed as a bool? Something more like log scope: public IDisposable SuppressInstrumentation()
Which is to say, return an object that sets the bool to true on ctor, sets it to fault on dispose?
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.
I believe this is what @reyang was proposing in the PR description. I think I do like the disposable idea. I'm currently playing with this implementation and I thing this would make things read nicer.
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.
Yeah, @alanwest is helping on that part in a separate PR ❤️
@reyang In your sample code in the PR description you have
Though, it seems like this will be desirable. If some DB library uses HttpClient under the covers then it seems that it will need to be up to the DB library to enable suppression if that's the desired effect. |
Definitely. Another example is a library that keep polling the backend (e.g. in Microsoft there is something called SignalR), where folks only want high level logical operation rather than millions of HTTP 304. |
This is a follow up PR on #948. It helps us to move closer to the resolution for #893 (comment) and the 2nd point of #809 (comment).
Changes
With this change, SDK consumers (e.g. exporters) can use:
For API consumers, I guess we don't want to expose this as a public API, so what folks would do (e.g. in instrumentation):
Please provide a brief description of the changes here. Update the
CHANGELOG.md
for non-trivial changes.For significant contributions please make sure you have completed the following items: