Skip to content
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

Merged
merged 8 commits into from
Mar 16, 2022
Merged

Conversation

anuraaga
Copy link
Contributor

Fixes #4248

@anuraaga anuraaga requested a review from a user March 10, 2022 09:16
@anuraaga anuraaga requested a review from Oberon00 as a code owner March 10, 2022 09:16
Copy link
Contributor Author

@anuraaga anuraaga left a 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

otelJava.moduleName.set("io.opentelemetry.micrometershim")

dependencies {
api("io.micrometer:micrometer-core")
Copy link
Contributor Author

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) {
Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Contributor

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;
Copy link
Contributor Author

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
Copy link

codecov bot commented Mar 10, 2022

Codecov Report

Merging #4258 (12d7431) into main (85b33d4) will decrease coverage by 0.24%.
The diff coverage is 80.27%.

@@             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     
Impacted Files Coverage Δ
...lemetry/micrometer1shim/UnsupportedReadLogger.java 0.00% <0.00%> (ø)
.../opentelemetry/micrometer1shim/TimeUnitHelper.java 22.22% <22.22%> (ø)
...ntelemetry/micrometer1shim/OpenTelemetryGauge.java 63.15% <63.15%> (ø)
...ry/micrometer1shim/OpenTelemetryFunctionTimer.java 64.70% <64.70%> (ø)
.../micrometer1shim/OpenTelemetryFunctionCounter.java 65.00% <65.00%> (ø)
...elemetry/micrometer1shim/OpenTelemetryCounter.java 72.00% <72.00%> (ø)
...ntelemetry/micrometer1shim/OpenTelemetryMeter.java 81.81% <81.81%> (ø)
...rometer1shim/OpenTelemetryDistributionSummary.java 85.41% <85.41%> (ø)
...ntelemetry/micrometer1shim/OpenTelemetryTimer.java 86.53% <86.53%> (ø)
...ry/micrometer1shim/OpenTelemetryLongTaskTimer.java 87.50% <87.50%> (ø)
... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 85b33d4...12d7431. Read the comment docs.

Comment on lines 41 to 45
/** Sets the {@link NamingConvention} for this registry. */
public OpenTelemetryMeterRegistryBuilder setNamingConvention(NamingConvention namingConvention) {
this.namingConvention = namingConvention;
return this;
}
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

@anuraaga anuraaga Mar 11, 2022

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());
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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.


testing {
suites {
// Test older LTS versions
Copy link
Member

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) {
Copy link
Member

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.

@mateuszrzeszutek
Copy link
Member

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. micrometer-1-shim

@anuraaga
Copy link
Contributor Author

@jack-berg @jkwatson Would be great if you could give this an ack, thanks!

@jkwatson
Copy link
Contributor

Will look tomorrow first thing

import java.util.Collections;
import javax.annotation.Nullable;

@SuppressWarnings("HashCodeToString")
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

@jkwatson jkwatson left a 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.

}

description = "OpenTelemetry Micrometer Bridge"
otelJava.moduleName.set("io.opentelemetry.micrometershim")
Copy link
Member

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?

dependencies {
api("io.micrometer:micrometer-core")

implementation(project(":api:all"))
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Move micrometer shim to the core repo
4 participants