Add Support for CloudFoundry Resource Attributes

[KarstenSchnitter]

Is your feature request related to a problem? Please describe.

When running an application as a CloudFoundry deployment, the Cloud Foundry attributes should be filled automatically. This allows connecting the observability data with the application metadata as used by Cloud Foundry.

Describe the solution you'd like

An application deployed to Cloud Foundry receives the necessary metadata in the environment variable VCAP_APPLICATION. The contents of this variable is a JSON document whose fields can be mapped to the CloudFoundry attributes by the following mapping.

• VCAP_APPLICATION(application_id) -> cloudfoundry.app.id
• VCAP_APPLICATION(application_name) -> cloudfoundry.app.name
• VCAP_APPLICATION(instance_index) -> cloudfoundry.app.instance.id (convert int to string)
• VCAP_APPLICATION(organization_id) -> cloudfoundry.org.id
• VCAP_APPLICATION(organization_name) -> cloudfoundry.org.name
• VCAP_APPLICATION(process_id) -> cloudfoundry.process.id
• VCAP_APPLICATION(process_type) -> cloudfoundry.process.type
• VCAP_APPLICATION(space_id) -> cloudfoundry.space.id
• VCAP_APPLICATION(space_name) -> cloudfoundry.space.name

All of this can be done in a ResourceProvider, that searches for the environment variable VCAP_APPLICATION and applies this mapping, if it is found.

Describe alternatives you've considered

CloudFoundry developers can run custom extensions on the Java Agent to provide this functionality.

Additional context

No response

[breedx-splk]

@KarstenSchnitter thanks for the suggestion, I think CF users would find this helpful. We typically put vendor-specific (in this case cloud-vendor specific) implementations over in the contrib repo (see the aws and gcp implementations over there). Once that happens, vendors can choose to include these ResourceProvider implementations in their distros, or end-users can include them via agent extension.

I'm inclined to move this issue to the contrib repo, if that's cool with everyone...

[KarstenSchnitter]

@laurit suggested the same in the associated PR #12862. Still, I want to point out, that CloudFoundry is a CNCF project just like Kubernetes and much more vendor-agnostic than AWS or GCP. I would prefer having this instrumentation available without an additional extension, but I can work with that solution as well.

[breedx-splk]

Sorry, I missed that the conversation had already been started over there.

Can you link to documentation that shows CloudFoundry as a CNCF project? I couldn't find any evidence of that being a true statement, but might have just overlooked it.

[KarstenSchnitter]

Sorry, I got it a little mixed up. CloudFoundry is not a CNCF project, but the CloudFoundry Foundation is part of the Linux Foundation: https://www.cloudfoundry.org/foundation/

[laurit]

I would prefer having this instrumentation available without an additional extension, but I can work with that solution as well.

Having the resource provider in contrib repository does not prevent it from being included in the agent. Both gcp and aws resource providers are included in the agent, although they are disabled by default.