-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[HUDI-7337] Implement MetricsReporter that reports metrics to M3 #10565
Conversation
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/metrics/m3/M3MetricsReporter.java
Show resolved
Hide resolved
@@ -120,6 +120,16 @@ | |||
<groupId>io.prometheus</groupId> | |||
<artifactId>simpleclient_pushgateway</artifactId> | |||
</dependency> | |||
<dependency> | |||
<groupId>com.uber.m3</groupId> | |||
<artifactId>tally-m3</artifactId> |
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.
Is there any risk for the uber specific jar to conflict with others?
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 took a look at dependencies used by com.uber.m3:tally-m3
and com.uber.m3:tally-core
. It seems that the former has dependency org.apache.thrift:libthrift:jar:0.9.3
and com.google.code.findbugs:jsr305:jar:3.0.2
.
I'll take a look at how to make sure com.uber.m3:tally-m3
uses its own version of thrift and com.google.code.findbugs
so that HUDI APIs (and other dependencies) won't use in tally's versions and tally will use the versions it needs, which I think I might need to use shading to solve.
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.
For now I ended up shading com.uber.m3
in the packaging/hudi-*-bundle
POM files. To be fully transparent, I'm not too familiar with MVN/Java dependency management, so I did this approach based on what I saw on the web. Since my main priority is to just make sure dependencies "brought in" by com.uber.m3
don't "override" jar versions by hoodie_oss
or users. If there's a better convention/technique for guarding against future dependency conflicts in Apache Java projects then I can try doing that instead.
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, shading is fine.
@@ -120,6 +120,16 @@ | |||
<groupId>io.prometheus</groupId> | |||
<artifactId>simpleclient_pushgateway</artifactId> | |||
</dependency> | |||
<dependency> | |||
<groupId>com.uber.m3</groupId> | |||
<artifactId>tally-m3</artifactId> |
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, shading is fine.
Change Logs
com.uber.m3:tally-m3
,com.uber.m3:tally-core
Impact
hoodie.metrics.reporter.type
asM3
and their corresponding host address/port inhoodie.metrics.m3.host
/hoodie.metrics.m3.port
Risk level (write none, low medium or high below)
low
Documentation Update
Documentation should be updated with the new config options for M3 metrics reporting:
hoodie.metrics.m3.host
hoodie.metrics.m3.port
hoodie.metrics.m3.tags
hoodie.metrics.m3.service
hoodie.metrics.m3.env
Contributor's checklist