-
Notifications
You must be signed in to change notification settings - Fork 888
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
Changes from 6 commits
f241fe7
491054c
845dfd4
d26ecf0
f4a1b6f
328d5df
8e97404
ccee0c5
47a9c84
6df9b41
a9a1113
66d4bbd
9b58292
4be0877
fea3418
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -37,3 +37,55 @@ groups: | |
note: > | ||
In AWS, this is called availability-zone. | ||
examples: ['us-central1-a'] | ||
- id: infrastructure_service | ||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe add a note that the service should (must?) match There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
examples: ['AWS_EC2', 'Azure_VM', 'GCP_ComputeEngine'] |
There was a problem hiding this comment.
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
orcloud.hosting_product
may also make sense.There was a problem hiding this comment.
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 :)There was a problem hiding this comment.
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.