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

Add meter version to runtime metrics #6874

Merged
merged 2 commits into from
Oct 23, 2022

Conversation

jack-berg
Copy link
Member

@jack-berg jack-berg commented Oct 14, 2022

Runtime metrics doesn't include the meter version. This adds it from the utility method in the instrumentation-api EmbeddedInstrumentationProperties.findVersion. I know I can read the properties file for this module, but its repetitive to implement that in many places.

@jack-berg jack-berg requested a review from a team October 14, 2022 00:23
@@ -36,6 +46,74 @@ void setup() {
beans = Arrays.asList(bufferPoolBean);
}

@Test
void registerObservers() {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also adding some test coverage to make this consistent with the other runtime observers.

@@ -50,6 +59,125 @@ void setup() {
beans = Arrays.asList(heapPoolBean, nonHeapPoolBean);
}

@Test
void registerObservers() {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also adding some test coverage to make this consistent with the other runtime observers.

@jack-berg
Copy link
Member Author

Oh second thought, maybe we should read the version from the module's version.properties given that there could be version conflicts with the instrumentation-api.

@mateuszrzeszutek
Copy link
Member

Oh second thought, maybe we should read the version from the module's version.properties given that there could be version conflicts with the instrumentation-api.

EmbeddedInstrumentationProperties does read the version from the module's properties file though; what kind of conflicts did you have in mind?

@jack-berg
Copy link
Member Author

EmbeddedInstrumentationProperties does read the version from the module's properties file though; what kind of conflicts did you have in mind?

Ok you are correct. I wasn't sure how this worked behind the scenes but it looks like it relies on the instrumentationName argument being the same as the name of the properties file name, which is generated from the module name in this convention. Pretty cool!

It will be important that instrumentation that uses EmbeddedInstrumentationProperties.findVersion has unit tests asserting the instrumentation scope version, since getting a non-null response is dependent on passing a very specific instrumentationName.

@trask
Copy link
Member

trask commented Oct 17, 2022

It will be important that instrumentation that uses EmbeddedInstrumentationProperties.findVersion has unit tests asserting the instrumentation scope version, since getting a non-null response is dependent on passing a very specific instrumentationName.

check out #6773, it's definitely not in an intuitive place though

@trask trask merged commit 015dbf9 into open-telemetry:main Oct 23, 2022
LironKS pushed a commit to helios/opentelemetry-java-instrumentation that referenced this pull request Oct 31, 2022
Runtime metrics doesn't include the meter version. This adds it from the
utility method in the instrumentation-api
`EmbeddedInstrumentationProperties.findVersion`. I know I can read the
properties file for this module, but its repetitive to implement that in
many places.
LironKS pushed a commit to helios/opentelemetry-java-instrumentation that referenced this pull request Dec 4, 2022
Runtime metrics doesn't include the meter version. This adds it from the
utility method in the instrumentation-api
`EmbeddedInstrumentationProperties.findVersion`. I know I can read the
properties file for this module, but its repetitive to implement that in
many places.
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.

4 participants