-
Notifications
You must be signed in to change notification settings - Fork 130
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
[maven-extension] Option to disable the creation of spans per mojo goal execution #108
[maven-extension] Option to disable the creation of spans per mojo goal execution #108
Conversation
@kenfinnigan please look at this proposal to solve the problem you raised to disable the creation of spans per mojo goal execution for large builds. I introduced the configuration parameter
|
maven-extension/README.md
Outdated
@@ -63,6 +63,7 @@ The Maven OpenTelemetry Extension supports a subset of the [OpenTelemetry auto c | |||
| otel.exporter.otlp.headers | OTEL_EXPORTER_OTLP_HEADERS | Key-value pairs separated by commas to pass as request headers on OTLP trace and metrics requests. | | |||
| otel.exporter.otlp.timeout | OTEL_EXPORTER_OTLP_TIMEOUT | The maximum waiting time, in milliseconds, allowed to send each OTLP trace and metric batch. Default is `10000`. | | |||
| otel.resource.attributes | OTEL_RESOURCE_ATTRIBUTES | Specify resource attributes in the following format: key1=val1,key2=val2,key3=val3 | | |||
| otel.maven.instrumentation.mojos.enabled | OTEL_MAVEN_INSTRUMENTATION_MOJOS_ENABLED | Disable the creation of spans for each mojo goal execution, `true` or `false`. Convenient to reduce the number of spans for large builds. Default value: `true` | |
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 description confused me as it implies disabling, but based on the code I think it's meant to be enabling.
Is that correct?
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 that the proposed code keeps mojo spans enabled by default (see L171 and code snippet below).
I'm wondering if the naming convention of to disable instrumentations on the Otel Java Agent, OTEL_INSTRUMENTATION_[NAME]_ENABLED
, is intuitive enough for our use case on the Otel Maven extension.
❓ Would it be more intuitive to suffix the config param by _DISABLED
(ie OTEL_MAVEN_INSTRUMENTATION_MOJOS_DISABLED
) than to follow the _ENABLED
convention of the Otel Java Agent?
Code snippet of the proposed code that keeps mojo spans enabled by default thanks to the default value true
:
this.mojosInstrumentationEnabled =
Boolean.parseBoolean(
StringUtils.defaultIfBlank(mojosInstrumentationEnabledAsString, "true"));
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.
Following the convention of the instrumentation repo, for better or worse, is probably a good idea. I guess @kenfinnigan's pointing to the comment starting with Disable the creation
which makes it seem like this flags disables when it's true. I think this would read fine
"Whether to create spans for each mojo goal execution"
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 @anuraaga , I have improved the documentation based on your recommendation.
Thanks @anuraaga for the edits! |
maven-extension/README.md
Outdated
@@ -63,9 +63,10 @@ The Maven OpenTelemetry Extension supports a subset of the [OpenTelemetry auto c | |||
| otel.exporter.otlp.headers | OTEL_EXPORTER_OTLP_HEADERS | Key-value pairs separated by commas to pass as request headers on OTLP trace and metrics requests. | | |||
| otel.exporter.otlp.timeout | OTEL_EXPORTER_OTLP_TIMEOUT | The maximum waiting time, in milliseconds, allowed to send each OTLP trace and metric batch. Default is `10000`. | | |||
| otel.resource.attributes | OTEL_RESOURCE_ATTRIBUTES | Specify resource attributes in the following format: key1=val1,key2=val2,key3=val3 | | |||
| otel.maven.instrumentation.mojos.enabled | OTEL_MAVEN_INSTRUMENTATION_MOJOS_ENABLED | Whether to create spans for mojo goal executions, `true` or `false`. Can be configured to reduce the number of spans created for large builds. Default value: `true` | |
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.
Question regarding the naming convention:
Should OTEL_MAVEN
_INSTRUMENTATION_MOJOS_ENABLED be renamed to OTEL_INSTRUMENTATION_MAVEN
_MOJOS_ENABLED?
Similar to the example for OTEL_INSTRUMENTATION_AKKA_ACTOR_ENABLED
in https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/suppressing-instrumentation.md#even-more-fine-grained-control ?
I understand it's not purely a java instrumentation by definition, so I don't know if it makes sense to use the same format or whether this might cause some misleading.
Other than 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.
Based on the ones I see here: https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/config/common.md
I would agree it should probably be OTEL_INSTRUMENTATION_MAVEN_MOJOS_ENABLED
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.
Great catch @v1v , the Maven extension doesn't need to have a different configuration prefix.
I updated to use -Dotel.instrumentation.maven-mojos.enabled
and OTEL_INSTRUMENTATION_MAVEN_MOJOS_ENABLED
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.
Bit of a nitpick, but can it be maven.mojos
instead of a hyphen separator?
If additional properties are added in the future it's good to have them all under maven.*
and it wouldn't require a rename of this one to do 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.
No problem, I wanted to highlight the usage of -
over .
but I forgot to explain the rationale.
I used -
rather than .
to align with the convention chosen for "libraries and frameworks" in suppressing-instrumentation.md. All libs and frameworks use -
, even broad namespaces like spring-*
when I didn't find example of libraries and frameworks using .
.
I'll switch from maven-*
to maven.*
if desired.
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 understand the rationale of the -
over .
based on the linked document, but I wonder if it applies given there isn't a separate library of instrumentation for Maven vs Maven Mojo. I consider it to be a Maven instrumentation and not a Maven Mojo one, meaning maven
is the instrumentation and not maven-mojo
.
I could easily be splitting hairs on this, so please ignore me if that's the case.
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 like you proposal, I pushed a change.
Last verification, I switched to mojo singular rather than plural.
Choosing -Dotel.instrumentation.maven.mojo.enabled
and OTEL_INSTRUMENTATION_MAVEN_MOJO_ENABLED
to match with the usage of singular on suppressing-instrumentation.md and to match with what you just said in your comment.
Thanks again for your patience.
…f `OTEL_MAVEN_INSTRUMENTATION_MOJOS_ENABLED`
Thanks @trask! |
Description:
Option to disable the creation of spans per mojo goal execution
Existing Issue(s):
Testing:
Unfortunately I don't know yet how to add integration tests for Maven extensions. To manually test
Documentation:
Documented the new configuration parameter
OTEL_MAVEN_INSTRUMENTATION_MOJOS_ENABLED=true/false
/-Dotel.maven.instrumentation.mojos.enabled=true/false
Outstanding items:
Adding integration tests. I plan to engage with the Maven community to get guidance on this.