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

added cloud.infrastructure_service attribute to resource spec #1112

Merged
merged 15 commits into from
Jan 7, 2021
Merged
52 changes: 52 additions & 0 deletions semantic_conventions/resource/cloud.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -37,3 +37,55 @@ groups:
note: >
In AWS, this is called availability-zone.
examples: ['us-central1-a']
- id: infrastructure_service
Copy link
Member

@Oberon00 Oberon00 Dec 9, 2020

Choose a reason for hiding this comment

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

Not sure if "infrastructure" is the best word here. For example, AWS (Lambda, ...) is not only IaaS, there is more than just the infrastructure provided. Although of course the infrastructure is also provided. So I guess infrastructure_service is fine, but maybe compute_service would be better. cloud.hosting_service or cloud.hosting_product may also make sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree compute_service is good too - I'd just rather not change the key for a marginal naming improvement since it's already been included in recent releases of the collector contrib (e.g. here). But of course it's still in beta so if you feel strongly I'm happy to make the change :)

Copy link
Member

Choose a reason for hiding this comment

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

I agree. However, given that "infrastructure" could be interpreted in a broader sense, it should be fine, and the enumeration of well-known values will also make it clearer.

type:
allow_custom_values: true
members:
- id: AWS_EC2
value: 'AWS_EC2'
brief: AWS Elastic Compute Cloud
- id: AWS_ECS
value: 'AWS_ECS'
brief: AWS Elastic Container Service
- id: AWS_EKS
value: 'AWS_EKS'
brief: AWS Elastic Kubernetes Service
- id: AWS_Lambda
value: 'AWS_Lambda'
brief: AWS Lambda
- id: AWS_ElasticBeanstalk
value: 'AWS_ElasticBeanstalk'
brief: AWS Elastic Beanstalk
- id: Azure_VM
value: 'Azure_VM'
brief: Azure Virtual Machines
- id: Azure_ContainerInstances
value: 'Azure_ContainerInstances'
brief: Azure Container Instances
- id: Azure_AKS
value: 'Azure_AKS'
brief: Azure Kubernetes Service
- id: Azure_Functions
value: 'Azure_Functions'
brief: Azure Functions
- id: Azure_AppService
value: 'Azure_AppService'
brief: Azure App Service
- id: GCP_ComputeEngine
value: 'GCP_ComputeEngine'
brief: GCP Compute Engine
- id: GCP_CloudRun
value: 'GCP_CloudRun'
brief: GCP Cloud Run
- id: GCP_GKE
value: 'GCP_GKE'
brief: Google Kubernetes Engine
- id: GCP_CloudFunctions
value: 'GCP_CloudFunctions'
brief: GCP Cloud Functions
- id: GCP_AppEngine
value: 'GCP_AppEngine'
brief: GCP App Engine
brief: >
The cloud infrastructure resource in use.
Copy link
Member

Choose a reason for hiding this comment

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

Maybe add a note that the service should (must?) match cloud.provider.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Went with should - we allow for custom values so that other cloud providers besides the 3 we enumerate can be referenced, and we can't really control what people would call those infrastructure_services.

examples: ['AWS_EC2', 'Azure_VM', 'GCP_ComputeEngine']
21 changes: 21 additions & 0 deletions specification/resource/semantic_conventions/cloud.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,7 @@
| `cloud.account.id` | string | The cloud account ID used to identify different entities. | `opentelemetry` | No |
| `cloud.region` | string | A specific geographical location where different entities can run. | `us-central1` | No |
| `cloud.zone` | string | Zones are a sub set of the region connected through low-latency links. [1] | `us-central1-a` | No |
| `cloud.infrastructure_service` | string | The cloud infrastructure resource in use. | `AWS_EC2`<br>`Azure_VM`<br>`GCP_ComputeEngine` | No |

**[1]:** In AWS, this is called availability-zone.

Expand All @@ -21,4 +22,24 @@
| `aws` | Amazon Web Services |
| `azure` | Microsoft Azure |
| `gcp` | Google Cloud Platform |

`cloud.infrastructure_service` MUST be one of the following or, if none of the listed values apply, a custom value:

| Value | Description |
|---|---|
| `AWS_EC2` | AWS Elastic Compute Cloud |
| `AWS_ECS` | AWS Elastic Container Service |
| `AWS_EKS` | AWS Elastic Kubernetes Service |
| `AWS_Lambda` | AWS Lambda |
| `AWS_ElasticBeanstalk` | AWS Elastic Beanstalk |
| `Azure_VM` | Azure Virtual Machines |
| `Azure_ContainerInstances` | Azure Container Instances |
| `Azure_AKS` | Azure Kubernetes Service |
| `Azure_Functions` | Azure Functions |
| `Azure_AppService` | Azure App Service |
| `GCP_ComputeEngine` | GCP Compute Engine |
| `GCP_CloudRun` | GCP Cloud Run |
| `GCP_GKE` | Google Kubernetes Engine |
| `GCP_CloudFunctions` | GCP Cloud Functions |
| `GCP_AppEngine` | GCP App Engine |
<!-- endsemconv -->