would you be open to leveraging OpenTelemetry's semantic conventions for some of @vercel/otel's default resource attributes? That would make interop with observability solutions and visualizations clearer, i.e., Vercel data could be surfaced more nicely.
These attribute keys specifically could be replaced with their standardized counterparts:
I also see room to add the cloud.provider=vercel resource attribute (OTel specification).
Why I am bringing this up: At Dash0 we are surfacing specific resources attributes because they carry additional meaning to users. By surfacing these we can help users navigate/provide context. If @vercel/otel also used standard OTel attributes, this would just work OOTB. Sample screenshots showing how certain standardized resource attributes are leveraged to provide context:
Hey folks,
would you be open to leveraging OpenTelemetry's semantic conventions for some of
@vercel/otel's default resource attributes? That would make interop with observability solutions and visualizations clearer, i.e., Vercel data could be surfaced more nicely.These attribute keys specifically could be replaced with their standardized counterparts:
env:deployment.environment(OTel specification)vercel.region:cloud.region/cloud.availability_zone(OTel specification)vercel.runtime:process.runtime.name(OTel specification)I also see room to add the
cloud.provider=vercelresource attribute (OTel specification).Why I am bringing this up: At Dash0 we are surfacing specific resources attributes because they carry additional meaning to users. By surfacing these we can help users navigate/provide context. If
@vercel/otelalso used standard OTel attributes, this would just work OOTB. Sample screenshots showing how certain standardized resource attributes are leveraged to provide context: