Define a consistent way to record infrastructure service in use

[willarmiros]

What are you trying to achieve?

I would like to see the type of compute service that is running my OpenTelemetry-instrumented application as an attribute. Today, to determine the cloud service my app is running on based on existing resource attributes, I have to do something like:

if (cloud.provider == 'aws' && host.id != null) {
  return 'EC2';
} else if (cloud.provider == 'gcp' && host.id != null) {
  return 'GCE';
} 
// etc

Even this may not be completely reliable, since a more abstract service (like a containerized service that runs on EC2 or GCE under the hood) may have host.id defined even though it's an entirely different service. To improve this experience, I'd like an attribute that specifically tells me my application is on Amazon EC2, or Google Compute Engine, or Azure VMs, or some other cloud service.

Option 1

Add a generic cloud.infrastructure_service attribute and an enumeration of several popular cloud services from the existing cloud.providers. Limiting it to only services from our predefined cloud.provider list will prevent the enumerated values from being expanded indefinitely IMO. We can also allow custom values for less-popular services. This proposal is drafted in #1112.

Pros: Provides a general attribute that can be adopted by all the major cloud providers to give users explicit knowledge of their compute service. All the enumerated values live in the same place in the spec for easy reference.

Cons: A monolithic enumeration can grow to be very large and possibly becomes a hassle to maintain.

Option 2

Add a service attribute as a cloud-provider-specific attribute, e.g. aws.service as proposed by @tigrannajaryan. #1099 provides a mechanism for this. The enumeration of services would be limited to each provider's own specs.

Pros: Encapsulates services to their provider, meaning there is a guaranteed limit on the size of the enumeration for each provider.

Cons: The types of services live in disparate locations in the spec. It also might be difficult to initially get the GCE and Azure service types added, since with this option we'd have to create an entire directory structure for them like I did for AWS in #1099.

[anuraaga]

@open-telemetry/specs-trace-approvers any thoughts on this issue? Option 1 seems like the simplest to use in backends to me.