-
Notifications
You must be signed in to change notification settings - Fork 846
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
Bring in micrometer shim #4258
Bring in micrometer shim #4258
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.
Comments below for the only two locations business logic changed. Tests were modified fairly significantly though should still be testing the same cases
micrometer-shim/build.gradle.kts
Outdated
otelJava.moduleName.set("io.opentelemetry.micrometershim") | ||
|
||
dependencies { | ||
api("io.micrometer:micrometer-core") |
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.
In instrumentation repo this is compileOnly
but here went with api
for now to match pattern in opentracing shim but may change it.
|
||
final class Bridging { | ||
|
||
static Attributes tagsAsAttributes(Meter.Id id, NamingConvention namingConvention) { |
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.
Removed caches from this class since we don't (yet) have a concurrent cache in this repo
- I've always wondered whether we should cache
AttributesBuilder.put(String key
invocations in the API itself. I don't think there's anything unique to micrometer to do it specifically here - Implement metric identity specification #4222 will land soon to remove need for description cache
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 always wondered whether we should cache
AttributesBuilder.put(String key
invocations in the API itself. I don't think there's anything unique to micrometer to do it specifically here
That would be awesome, I think - we've been recommending using AttributeKey
everywhere to avoid additional allocations, but if we could fix that at the source that would be great.
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 a bit hesitant, only because we'd need to be careful about how much we cache... we wouldn't want a pathological API usage to OOM us.
private final OpenTelemetry openTelemetry; | ||
private Clock clock = Clock.SYSTEM; | ||
private TimeUnit baseTimeUnit = TimeUnit.MILLISECONDS; | ||
private NamingConvention namingConvention = NamingConvention.identity; |
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.
No config property read here like in instrumentation repo
Codecov Report
@@ Coverage Diff @@
## main #4258 +/- ##
============================================
- Coverage 90.18% 89.93% -0.25%
- Complexity 4718 4797 +79
============================================
Files 553 568 +15
Lines 14544 14909 +365
Branches 1399 1414 +15
============================================
+ Hits 13116 13409 +293
- Misses 978 1043 +65
- Partials 450 457 +7
Continue to review full report at Codecov.
|
/** Sets the {@link NamingConvention} for this registry. */ | ||
public OpenTelemetryMeterRegistryBuilder setNamingConvention(NamingConvention namingConvention) { | ||
this.namingConvention = namingConvention; | ||
return 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.
NamingConvention
can be overriden by using meterRegistry.config().namingConvention(...)
- do we need a builder method for that?
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 having common options here is good since it keeps all the configuration in one place and discoverable. Naming convention is quite key
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.
That being said better to start with less than more API, so went back, we'll probably see how important naming convention is when working out the prometheus compatibility mode.
final class UnsupportedReadLogger { | ||
|
||
static { | ||
Logger logger = Logger.getLogger(OpenTelemetryMeterRegistry.class.getName()); |
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.
Micrometer has an InternalLogger
that can be used instead (it forwards either to slf4j or JUL, depending on the classpath) -- WDYT about using it 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.
Just like we don't want people to use our internal classes I don't want to use others' as well :P This logger class seems fine for OTel users
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.
Hmm, I had the impression that it could be used inside MeterRegistry
implementations - but I've double checked it just now, it seems it's only used in micrometer-core
itself.
Yeah, let's keep using JUL then.
micrometer-shim/build.gradle.kts
Outdated
|
||
testing { | ||
suites { | ||
// Test older LTS versions |
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.
Nice 👍
|
||
final class Bridging { | ||
|
||
static Attributes tagsAsAttributes(Meter.Id id, NamingConvention namingConvention) { |
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 always wondered whether we should cache
AttributesBuilder.put(String key
invocations in the API itself. I don't think there's anything unique to micrometer to do it specifically here
That would be awesome, I think - we've been recommending using AttributeKey
everywhere to avoid additional allocations, but if we could fix that at the source that would be great.
Now that I think of it, there's going to be Micrometer 2.0 release soon - we'll most likely need another shim for that, I think we can safely assume that there're going to be incompatible changes in there. Should we include the version in the artifact/module name? E.g. |
@jack-berg @jkwatson Would be great if you could give this an ack, thanks! |
Will look tomorrow first thing |
import java.util.Collections; | ||
import javax.annotation.Nullable; | ||
|
||
@SuppressWarnings("HashCodeToString") |
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 is this warning about?
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 since hashcode is defined but toString isn't. It seems like it'd be worth defining toString but will follow up
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.
Didn't give it anything close to a thorough review, but it's marked as alpha
, so I'm not overly concerned.
micrometer1-shim/build.gradle.kts
Outdated
} | ||
|
||
description = "OpenTelemetry Micrometer Bridge" | ||
otelJava.moduleName.set("io.opentelemetry.micrometershim") |
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 directory name is micrometer1-shim
which doesn't align with the module name. Was this intentional?
micrometer1-shim/build.gradle.kts
Outdated
dependencies { | ||
api("io.micrometer:micrometer-core") | ||
|
||
implementation(project(":api:all")) |
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 we need an api dependency on :api:all
since OpenTelemetry
is used in the shim's public API.
Fixes #4248