alt_stat_name as a standardized observability label for clusters

[htuch]

Currently, Cluster has an alt_stat_name field that is used for stats only. It seems that this would be useful for both tracing and access logs (to the extent that service names appear that at all). This allows for a semantically meaningful label to be consumed by monitoring and humans, regardless of the resource name (which might be reflecting addressing or config pipeline artifacts, e.g. when we start using xdstp:// URLs).

I'd like to propose we either repurpose alt_stat_name as the general observability name or create an explicit, more general, observability_name that applies across stats/logging/tracing. Within Envoy, we would have a clean C++ abstraction to access this in ClusterInfo.

Ultimately this would apply to other resources as well, but clusters is where we (Google) have a specific interest today.

CC @envoyproxy/api-shepherds

[mattklein123]

I think it would be fine to use alt_stat_name for general observability naming and tag the field for a name change in the next major version. I'm not sure it's worth the churn to change the name now.

[htuch]

Sounds good. I imagine we should set a runtime flag to control its use in tracing/logs, in case this breaks anyone, but we can default it true?

[mattklein123]

Sure runtime flag sgtm but IMO we can default it to on as you say.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.