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

[maven-extension] Capture details on mojo goal executions: deploy:deploy, spring-boot:build-image, jib:build, snyk:test, snyk:monitor #146

Conversation

cyrille-leclerc
Copy link
Member

@cyrille-leclerc cyrille-leclerc commented Dec 6, 2021

Description:

Capture details on mojo goal executions: deploy:deploy, spring-boot:build-image, jib:build, snyk:test, and snyk:monitor

Existing Issue(s):

None

Testing:

Introduced unit tests.

Documentation:

See the updated README.md

Outstanding items:

Span Attributes introduced in this PR

Span attributes introduced in this PR.

Key namespaces:

  • maven.*: anything related to Maven
    • maven.build.*: anything related to the artifacts produced by Maven builds
      • maven.build.container: producing docker/container images
        • maven.build.container.image.*: anything related to container images produced by Maven builds
        • maven.build.container.registry.*: attributes to describe container registry to which produced docker images are uploaded., describe the urlof the registry and the username used for authentication.
      • maven.build.repository: uploading artifacts to a Maven repository
    • maven.execution.*: anything related to the Maven execution (e.g. the goal)
    • maven.plugin.*: anything related to the Maven plugin that is being executed
    • maven.project.*: anything related to the project/module that is building

Noteworthy: we capture the username used to upload to container registries and Maven repositories to help troubleshooting

Span attribute Type Description
maven.build.container.image.name string Name of the produced Docker image
maven.build.container.image.tags string[] Tags of the produced Docker image
maven.build.container.registry.auth.username string Username used to upload the image to the container registry.
maven.build.container.registry.url string URL of the container registry to which this image is uploaded.
maven.build.repository.auth.username string Username used to upload artifacts to the Maven repository. See Maven POM reference / Repository
maven.build.repository.id string ID of the Maven repository to which the artifact is deployed. See Maven POM reference / Repository
maven.build.repository.url string URL of the Maven repository to which the artifact is deployed. See Maven POM reference / Repository
maven.execution.goal string Goal that is being executed
maven.execution.id string ID of the execution
maven.execution.lifecyclePhase string Lifecycle phase to which belong the execution
maven.plugin.artifactId string Artifact ID of the Maven plugin on which the Maven goal is executed
maven.plugin.groupId string Group ID of the Maven plugin on which the Maven goal is executed
maven.plugin.version string Version of the Maven plugin on which the Maven goal is executed
maven.project.artifactId string Artifact ID of the Maven project on which the Maven goal is executed
maven.project.groupId string Group ID of the Maven project on which the Maven goal is executed
maven.project.version string Version of the Maven project on which the Maven goal is executed

@cyrille-leclerc cyrille-leclerc changed the title Capture details on mojo goal executions: deploy:deployand spring-boot:build-image [maven-extension] Capture details on mojo goal executions: deploy:deployand spring-boot:build-image Dec 6, 2021
@cyrille-leclerc
Copy link
Member Author

@kenfinnigan the visibility OTel tracing brings on the flow of the build is amazing! It can greatly help teams optimize their builds.

I discover that even for pretty simple projects, it's easy to wrongly configure the chain of goals of a Maven build and have redundant executions of costly goals.

Here is an example below of a build just combining a Spring Boot app with Snyk checks, a deploy to a Maven repo, and and the publishing as a docker image.
I got some pom.xml fragments from snyk.io and Spring Boot web site to assemble a mvn deploy and the goals surefire:test, snyk:test are executed twice impacting seriously the duration (pom.xml).

@cyrille-leclerc cyrille-leclerc changed the title [maven-extension] Capture details on mojo goal executions: deploy:deployand spring-boot:build-image [maven-extension] Capture details on mojo goal executions: deploy:deploy, spring-boot:build-image, jib:build, snyk:test, snyk:monitor Dec 14, 2021
@cyrille-leclerc
Copy link
Member Author

@kenfinnigan @trask I have added in the description of this PR all the introduced span attributes with an explanation on the used namespaces (container.registry.image.* and maven.*) including the maven.build.* we have just discussed.
The detailed description of all the attribute per Maven Plugin Goal execution is available on the updated README.md.

I have implemented the enrichment for 5 plugin goals in order to have a broad set of use cases.

Even if @trask suggested to subdivide the maven.build.* namespace per plugin that build things, I tried to use a common namespace for maven.build.container.image.* for Docker images produced either by the Spring Boot Maven Plugin or by the Google Jib Maven Plugin and IMO it works well.

I can easily implement @trask's suggestion with maven.springboot.build.container.image.* and maven.googlejib.build.container.image.* if we prefer.

@cyrille-leclerc cyrille-leclerc marked this pull request as ready for review December 15, 2021 22:12
@cyrille-leclerc cyrille-leclerc requested a review from a team December 15, 2021 22:12
@trask
Copy link
Member

trask commented Dec 15, 2021

I tried to use a common namespace for maven.build.container.image.* for Docker images produced either by the Spring Boot Maven Plugin or by the Google Jib Maven Plugin and IMO it works well.

👍

on first glance, it may make sense to move container.registry.url and container.registry.username to maven.build.container.registry.*, which matches maven.build.container.image.*, and avoids some confusion with container.* resource attributes spec

@@ -0,0 +1,5 @@
io.opentelemetry.maven.handler.GoogleJibBuildHandler
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think about avoiding SPI for our built in handlers? Then we could make them non-public too, just implementation details.

Copy link
Member Author

Choose a reason for hiding this comment

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

I introduced the SPI after discussing with @kenfinnigan . I see value in allowing Maven plugin authors to add instrumentation for the their plugins (plugin authors being vendors, oss projects or Maven practitioners).

What solution do you have in mind as an alternative to the SPI?
Before implementing the SPI, I used a hardcoded list of handlers, could it be what you had in mind?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah I had meant a list of built in components that is appended to with SPI. I think it satisfies both itches.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done through d393bea . Please review

.startSpan();
mojoExecution.getLifecyclePhase());
// enrich spans with MojoGoalExecutionHandler
Optional<MojoGoalExecutionHandler> handler =
Copy link
Contributor

Choose a reason for hiding this comment

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

We don't use Optional much in OTel codebases in favor of Nullable. I just noticed I've been forgetting to add nullness checking to this repo like we have in SDK repo, will add that. Can you look into reducing Optional for more consistency with SDK repo? I don't think the usages here are all that different from null checks

Copy link
Member Author

Choose a reason for hiding this comment

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

I like the principle "When in Rome, do as the Romans do" :-). I'll replace the usage of Optional by using @Nullable

Copy link
Member Author

Choose a reason for hiding this comment

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

Migration from Optional to @Nullable done. Please verify

@cyrille-leclerc
Copy link
Member Author

cyrille-leclerc commented Dec 16, 2021

I tried to use a common namespace for maven.build.container.image.* for Docker images produced either by the Spring Boot Maven Plugin or by the Google Jib Maven Plugin and IMO it works well.

👍

on first glance, it may make sense to move container.registry.url and container.registry.username to maven.build.container.registry.*, which matches maven.build.container.image.*, and avoids some confusion with container.* resource attributes spec

@trask I followed your guidance and we now have maven.build.container.*and maven.build.repository.*. Please see updated PR description and updated README.md

Copy link
Contributor

@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.

So sorry I just merged in the change to error prone knowing that it is likely annoying for this PR. If you are able to merge main and fix issues that come up that would be great, otherwise I can do it to this PR tomorrow.

# Conflicts:
#	maven-extension/src/main/java/io/opentelemetry/maven/OtelExecutionListener.java
#	maven-extension/src/main/java/io/opentelemetry/maven/OtelUtils.java
#	maven-extension/src/main/java/io/opentelemetry/maven/semconv/MavenOtelSemanticAttributes.java
Copy link
Contributor

@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.

Thanks just small points

.forEach(
goal -> {
MojoGoalExecutionHandler previousHandler =
mojoGoalExecutionHandlers.put(goal, handler);
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks @anuraaga . Could you please give me more guidance on this one?
I don't catch how I can use stream.collect(Collectors.toMap()) as I have a double loop 👼

Copy link
Contributor

Choose a reason for hiding this comment

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

Oops - yeah didn't think enough about it, stream doesn't seem good for this case

.forEach(
goal -> {
MojoGoalExecutionHandler previousHandler =
mojoGoalExecutionHandlers.put(goal, handler);
Copy link
Contributor

Choose a reason for hiding this comment

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

Oops - yeah didn't think enough about it, stream doesn't seem good for this case

@cyrille-leclerc
Copy link
Member Author

@ipleten I see on jenkinsci/opentelemetry-plugin#281 that you have CI pipelines build Java applications and packaging them as Docker images.

Could you please by any chance:

  • Indicate us how you build Docker images in your CI pipelines? A Maven / Gradle plugin? A shell script invoking docker build? ...
  • Have a look at the visualization of Maven + Docker builds we bring with this Pull Request and share feedback on this (screenshot above )?

# Conflicts:
#	maven-extension/src/main/java/io/opentelemetry/maven/OtelExecutionListener.java
@cyrille-leclerc cyrille-leclerc force-pushed the capture-details-on-mojo-goal-executions branch from 3d82fd6 to 81aaeb1 Compare January 3, 2022 23:05
@trask trask merged commit 2c02e42 into open-telemetry:main Jan 3, 2022
@cyrille-leclerc cyrille-leclerc deleted the capture-details-on-mojo-goal-executions branch January 16, 2022 20:59
@cyrille-leclerc cyrille-leclerc added this to the v1.10.0 milestone Jan 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants