Load all ResourceDetectors installed in the environment

[sanketmehta28]

Before opening a feature request against this repo, consider whether the feature should/could be implemented in the other OpenTelemetry client libraries. If so, please open an issue on opentelemetry-specification first.

Is your feature request related to a problem?
ContainerResourceDetectors and KubernetesResourceDetectors are being developed as a part of contrib repo. (issue).
So some changes are required at SDK level to load all the ResourceDetectors if installed (just like instrumentors)

Describe the solution you'd like
Load all ResourceDetectors installed

Describe alternatives you've considered
Specifying an ResourceDetector via ENV variable is possible. The issue is in pending state in specification repo (issue)

Additional context
Just like instrumentors, all installed ResourceDetectors should be loaded when the application starts and it will automatically fetch the resources and add it to spans.
ContainerResourceDetectors and KubernetesResourceDetectors are being developed as a part of contrib repo. once loaded they will fetch the container.id and pod.id respectively and add them in span resource.
This will allow end user to correlate the service issue with container issue.

[ocelotl]

@sanketmehta28 see #3181

[sanketmehta28]

@ocelotl : This is exactly I was trying to achieve with this issue. Only problem is I thought we cannot introduce the env variable _OTEL_RESOURCE_DETECTORS so we have to do it the same way we load the framework specific instrumentors.

[lzchen]

@ocelotl

Should probably close #3172 in favor of this issue as it is a duplicate.

[ocelotl]

@ocelotl

Should probably close #3172 in favor of this issue as it is a duplicate.

Done

[danw-mpl]

I've implemented a temporary workaround in my environment. We can set most of the resources OTEL attributes using the OTEL_RESOURCE_ATTRIBUTES environment variable.

Most importantly, we must form the log group ARN ourselves because the default CDK logGroupArn ends in a /* which X-Ray's log view does not like. We saw 400 Bad Request to https://egress.cell0001.prod.eu-west-1.scroll.aws.a2z.com/ in this case.

Example in CDK for an ECS service:

const resourceAttributes: { [key: string]: string } = {
    "service.app": this.applicationName,
    "service.env": this.environmentName,
    "container.name": fargateService.taskDefinition.defaultContainer?.containerName ?? "unknown",
    "cloud.provider": "aws",
    "cloud.platform": "aws_ecs",
    "cloud.account.id": this.account,
    "cloud.region": this.region,
    "aws.ecs.cluster.arn": fargateService.cluster.clusterArn,
    "aws.ecs.task.family": fargateService.taskDefinition.family,
    "aws.ecs.launchtype": "fargate",
    "aws.log.group.arns": `arn:aws:logs:${this.region}:${this.account}:log-group:${logGroup.logGroupName}`,
};

const dictToResourceAttributes = (dict: { [key: string]: string }): string => {
    return Object.keys(dict).map(key => {
        return key + "=" + resourceAttributes[key]
    }).join(",")
};

fargateService.taskDefinition.defaultContainer?.addEnvironment(
    'OTEL_RESOURCE_ATTRIBUTES',
    dictToResourceAttributes(resourceAttributes)
);

I found the attribute keys in https://aws-otel.github.io/docs/getting-started/x-ray