Tag-awareness in the stats API

[kyessenov]

We would like to expose a stats API to extensions through Wasm that is compatible with a general purpose OpenCensus/OpenTelemetry interfaces. Generally, these provide an ability to separate tag keys from tag values (e.g. https://opencensus.io/tag/). Envoy currently compresses all tags into a single long string, and expects custom tag extractors for post-processing. This causes two issues:

1. Regex overhead. Separating key=value pairs requires extra static bootstrap config (it is neither xDS compatible, nor modifiable by extensions), and extra parsing overhead since these are not simple prefix matches.
2. Symbol tables cannot distinguish static tag keys from the dynamic/per-request tag values. OpenCensus, for example, maintains a global symbol table for keys but not values, since registering new values at request time would cause lock contention. Envoy, however, would either inline all stats symbols or none of them, there is no way to distinguish between keys and values.

This is a feature request to extend the internal stats API to allow registering stat tag keys so that they can be automatically extracted on export without regex parsing, and symbol table gains awareness of the keys vs values.

cc @jmarantz @mandarjog @jplevyak

[mandarjog]

@bogdandrutu cc for full alignment with open telemetry.

[mattklein123]

+1 on adding a direct tag API to envoy stats. I think this would be a nice enhancement and a more flexible programming model. Will defer to @jmarantz for the right way of doing this. Note though that we have to make sure that Envoy stats in general still work well for tagless deployments such as statsd.

[bogdandrutu]

I will be out for 1.5 weeks, but very happy to see this proposal. I can share my experience and thoughts on this the week after next

[jmarantz]

@bogdandrutu assigning to you for now so you can share your experience & thoughts on this enhancement. Afterward I can unassign but I wanted to bump this to the top of your queue now that you've been back for 0.5 weeks :)

[jmarantz]

See also #7003 for which I have a draft PR to resolve. That would at least partially address @kyessenov 's second bullet point, though not his first.

[stale]

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 other activity occurs. Thank you for your contributions.

[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.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.