-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-21195][CORE] MetricSystem should pick up dynamically registered metrics in sources #31267
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
|
ok to test |
|
Kubernetes integration test starting |
|
Kubernetes integration test status failure |
|
Test build #135325 has finished for PR 31267 at commit
|
|
Looks like jenkins tests pass fine andn giithub actions flaked |
56706ff to
a951f24
Compare
|
Test build #752447031 for PR 31267 at commit |
a951f24 to
c808690
Compare
|
Test build #752448650 for PR 31267 at commit |
|
Kubernetes integration test starting |
|
Kubernetes integration test starting |
|
Kubernetes integration test status failure |
|
Kubernetes integration test status failure |
|
Test build #137423 has finished for PR 31267 at commit
|
mridulm
left a 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.
Thanks for working on this @robert3005, took a quick pass through it.
core/src/main/scala/org/apache/spark/metrics/MetricsSystem.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/metrics/MetricsSystem.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/metrics/MetricsSystem.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/metrics/MetricsSystem.scala
Outdated
Show resolved
Hide resolved
|
+CC @HyukjinKwon, @jerryshao who have worked on this in past. |
|
Thanks for cc'ing me @mridulm. Actually I reviewed this. It makes sense but I am not very used to this code path to be honest ... |
|
Thanks @HyukjinKwon :-) |
|
Test build #137635 has finished for PR 31267 at commit
|
|
We're closing this PR because it hasn't been updated in a while. This isn't a judgement on the merit of the PR in any way. It's just a way of keeping the PR queue manageable. |
|
This pr shouldn't be stale. I forgot about but will address comments eow |
e6b0092 to
2e6f29b
Compare
|
Addressed the comments. While reviewing the code I noticed there was a small thing that I missed - the error on duplicate metric name will happen now in the listener so I kept the logic that suppressed that error when registering |
|
Kubernetes integration test unable to build dist. exiting with code: 1 |
|
Test build #142115 has finished for PR 31267 at commit
|
|
Kubernetes integration test starting |
|
Kubernetes integration test status failure |
|
Test build #142174 has finished for PR 31267 at commit
|
|
Test build #143664 has finished for PR 31267 at commit
|
|
We're closing this PR because it hasn't been updated in a while. This isn't a judgement on the merit of the PR in any way. It's just a way of keeping the PR queue manageable. |
What changes were proposed in this pull request?
MetricSystem picks up new metrics from sources that are added throughout execution. If you do measurements via dynamic proxies you might not want to redeclare all metrics that the proxies will create and you'd prefer them to get populated as they're being produced. Right now all sources are processed only onceat startup and metrics are picked up only if they have been registered statically at compile time. Behaviour I am proposing lets you not have to declare metrics in two places.
This had been previously suggested in #18406 and #29980. I have reduced the scope of the change to just dynamic metric registration.
Why are the changes needed?
Currently there's no way to access MetricRegistry that MetricsSystem uses to hold its state and as such it's not possible to reprocess a source. MetricsSystem throws if any metric had already been registered previously.
n.b. the MetricRegistry is added as a constructor argument to make testing easier but could as well be accessed via reflection as a private variable.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Added tests