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 resource provider for CloudFoundry #12862

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

KarstenSchnitter
Copy link

Adds a module to provide a resource provider for applications deployed to CloudFoundry. It parses the VCAP_APPLICATION environment variable to fill in the attributes specified in the semantic conventions[1].

The implementation follows the OsResource in the resources module.

[1] https://github.com/open-telemetry/semantic-conventions/blob/main/docs/attributes-registry/cloudfoundry.md

Adds a module to provide a resource provider for applications
deployed to CloudFoundry. It parses the VCAP_APPLICATION
environment variable to fill in the attributes specified in the
semantic conventions[1].

The implementation follows the OsResource in the resources
module.

[1] https://github.com/open-telemetry/semantic-conventions/blob/main/docs/attributes-registry/cloudfoundry.md

Signed-off-by: Karsten Schnitter <[email protected]>
@KarstenSchnitter KarstenSchnitter requested a review from a team as a code owner December 9, 2024 09:36
@KarstenSchnitter
Copy link
Author

This change addresses #12861. Since this is my first contribution, please let me know, if I violated any guidelines. I was unsure, whether this is a library or javaagent instrumentation.

Note, this feature can be enhanced by adding a service name detector, that provides the cloudfoundry.app.name as service.name when there is no other service name, yet. This could work similar to the SpringBootServiceNameDetector.

@laurit
Copy link
Contributor

laurit commented Dec 9, 2024

Aws resource and gcp resource providers are in opentelemetry-java-contrib repository.

I was unsure, whether this is a library or javaagent instrumentation.

Javaagent instrumentations are embedded inside the agent and only work with the agent, library instrumentations can be added to the application. Resource providers are like library instrumentations, they can be used without the agent.

@KarstenSchnitter
Copy link
Author

@laurit thanks for the clarification. Are you suggesting, I take this PR to opentelemetry-java-contrib?

@KarstenSchnitter
Copy link
Author

Do I understand, that I would add the code to a submodule of opentelemetry-java-contrib and reference this at

"io.opentelemetry.contrib:opentelemetry-aws-resources:${otelContribVersion}",
"io.opentelemetry.contrib:opentelemetry-aws-xray-propagator:${otelContribVersion}",
"io.opentelemetry.contrib:opentelemetry-gcp-resources:${otelContribVersion}",
"io.opentelemetry.contrib:opentelemetry-baggage-processor:${otelContribVersion}",
within this project?

@laurit
Copy link
Contributor

laurit commented Dec 10, 2024

Do I understand, that I would add the code to a submodule of opentelemetry-java-contrib and reference this at

Besides adding it to the dependency management you would also need to add it to

implementation("io.opentelemetry.contrib:opentelemetry-aws-resources")
to include it in the agent and
implementation("io.opentelemetry.contrib:opentelemetry-aws-resources")
to include it in the spring starter (your current PR does not include the provider in the agent).
Since this resource provider is considerably simpler than gcp and aws another option that could be considered is having it in https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/resources/library @trask what is your preference?

@trask
Copy link
Member

trask commented Dec 13, 2024

I think I prefer for it to have its own module (instead of adding to io.opentelemetry.instrumentation:opentelemetry-resources)

probably contrib is the most consistent with the existing cloud resource providers, so I'm 👍 that route

Copy link
Contributor

@breedx-splk breedx-splk left a comment

Choose a reason for hiding this comment

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

Oops, forgot to "Submit review" a few days ago, sorry...

Comment on lines +57 to +58
CloudFoundryAttributesBuilder attributes = new CloudFoundryAttributesBuilder(vcapAppRaw);
attributes
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: I would name the variable builder instead of attributes.

Copy link
Author

Choose a reason for hiding this comment

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

I have to strong feelings about that. My thoughts were to make it clear, that only the attributes are being built, not the entire resource.

@trask
Copy link
Member

trask commented Dec 13, 2024

Oops, forgot to "Submit review" a few days ago, sorry...

been there, and I think it's really weird how GitHub shows the comments with the date you made them instead of the date you posted them

…c/main/java/io/opentelemetry/javaagent/instrumentation/cloudfoundry/resources/CloudFoundryResource.java

Co-authored-by: jason plumb <[email protected]>
@KarstenSchnitter
Copy link
Author

probably contrib is the most consistent with the existing cloud resource providers, so I'm 👍 that route

The same discussion is going on in #12861, the enhancement proposal for this PR. I have no problem taking this code to the contrib repository. But I still want to point out, that CloudFoundry is open source and governed by the CloudFoundry Foundation a member of the Linux Foundation. This is a difference to cloud providers like AWS or GCP. If you still think, this resource provider should go to the contrib repository, let me know. I will move it to the repository if necessary.

@trask
Copy link
Member

trask commented Dec 14, 2024

we may revisit this in the future open-telemetry/opentelemetry-java-contrib#1603 (comment)

I'd prefer to explore moving contrib components into the instrumentation repo if we are including them in the java agent distribution

but for now I believe the best place is in the contrib repo where we have a different component ownership model and so you can continue to own the module

@KarstenSchnitter
Copy link
Author

I migrated the code to the contrib repository with open-telemetry/opentelemetry-java-contrib#1613.

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