-
Notifications
You must be signed in to change notification settings - Fork 775
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
MeterProviderSdk should throw when no meters added. #2476
Closed
Yun-Ting
wants to merge
10
commits into
open-telemetry:main
from
Yun-Ting:Yun-Ting/MeterProviderException
+24
−15
Closed
Changes from all commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
52dc054
MeterProvider should throw when no meters added.
Yun-Ting 553f8b4
case
Yun-Ting 5289cb7
case
Yun-Ting 9e023d4
Revert "case"
Yun-Ting 8a7c4eb
comment
Yun-Ting 6fcaf0c
Oops
Yun-Ting 6cb1863
fixed tests
Yun-Ting f02d689
Trigger CI builds
Yun-Ting 0bb6dd1
Trigger CI builds
Yun-Ting 23cf66e
one more test fix
Yun-Ting File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Curious - do we do the same for traces (when no ActivitySource / legacy source are added)? (and why we want to do it for metrics?)
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 be doing for traces as well. We did not originally did the check for ActivitySources, as it was possible to add instrumentations which did "legacy" activities using some adapter. So it made sense for TracerProvide to exist even if no ActivitySource was present. Later we added native legacyactivity support, so if both are empty, then no need for setting up the SDK.
For metrics, there is no purpose served by having a MeterProvider, if no Meters are added, and is likely a user forgetting to add meters.
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.
nit: With this change you can remove the check before creating
meterSourcesToSubscribe
: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.
Thank you Cijo for the detailed explanation.
I've also fixed some of the existing metrics test cases by adding a meter after introducing this new check.
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'm concerned about this part. I understand that if the user forgot to add any Meter, it might be a mistake - and if that's the case we might want to fail fast and let them know. I think there are other cases folks want to comment out the meter just to disable telemetry collection, for troubleshooting or scoping down a performance problem.
If we let the
Build()
throw, the user might need to hack to code because it's hard to replace all the other places wheremeterProvider
methods are used. So I imagine they would put something like: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.
The development troubleshooting use case did not immediately come to mind, but I agree it's important.
I can definitely see myself doing something like this 😄.
.AddMeter("I.Know.Why.I.Have.To.Do.This.But.Id.Prefer.Not.To.Have.To")
That said, let's say someone mistakingly creates a MeterProvider with no Meters in production, I can see it being desirable from a production troubleshooting scenario to throw so that I can narrow down the problem quickly...
Might be nice to throw here when
SomeListOfMetersReadDynamicallyAtStartUp
turns out to be empty in production.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 agree on the above mentioning examples of cases that users do not need the meter but have to add meter to get around this hard check. Tests around HostingMeterExtensionTests.cs are other examples, too.
I will leave the decision of whether to add meter our not to the user to prevent having to do it just to get around this hard check.
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 was about to say that fail-fasting when user forgot to add any Meter was more important than the awkwardness of
AddMeter("I.Do.Not.Know.Why.I.Have.To.Do.This.But.Anyways")
, but based on our feedbacks so far - the issue is typically not with user forgetting to add any source/meter, but its missing to add the one they care about. So by throwing if no source/meter added, we won't help that more-common use case.Agree to leave this as is.
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.
Another thing to consider, in the future we might have lots of instrumentation libraries and the user might have: