You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The OpenTelemetry semantic conventions defines a number of attributes that be logical to set as resource attributes for GCE compute instances. Currently using these on an internal project but i appreciate their applicability might just be due to how our GCP setup works.
service.instance.id The string ID of the service instance, this is the four characters at the end of a GCE VM Instance.
service.namespace A string value having a meaning that helps to distinguish a group of services, in our case this is the project the VM is in.
service.name Must be the same for all instances of horizontally scaled services, we've set this to the instance group name
service.version The version string of the service API or implementation, and this is the instance template name each increment of which is a new version of the service.
This means that the combination of service namespace, service name and instance id is a globally unique identifier for that VM.
Essentially is GCE instance group setups widely standard enough that we can reliably use instance group/template/project to define the attributes?
If each VM is only running one process reporting telemetry, this could be a reasonable approach. I think it's pretty common for other users to have multiple applications running in one VM, which would cause conflicts. Ofc it also depends on you naming your VMs in such a way that service.name means something to your developers. I'm not sure if this would be widely applicable to other users.
The OpenTelemetry semantic conventions defines a number of attributes that be logical to set as resource attributes for GCE compute instances. Currently using these on an internal project but i appreciate their applicability might just be due to how our GCP setup works.
service.instance.id
The string ID of the service instance, this is the four characters at the end of a GCE VM Instance.service.namespace
A string value having a meaning that helps to distinguish a group of services, in our case this is the project the VM is in.service.name
Must be the same for all instances of horizontally scaled services, we've set this to the instance group nameservice.version
The version string of the service API or implementation, and this is the instance template name each increment of which is a new version of the service.This means that the combination of service namespace, service name and instance id is a globally unique identifier for that VM.
Service attributes spec
Quick demo of how these values could be acquired there's probably a better way to do this.
Essentially is GCE instance group setups widely standard enough that we can reliably use instance group/template/project to define the attributes?
The text was updated successfully, but these errors were encountered: