stats: introduce CustomStatNamespaces.

[mathetake]

This commit adds Stats::CustomStatNamespaces, and the concept of custom stat namespaces used by
extensions and stat sinks. Custom stat namespaces are registered by extensions
via the Stats::CustomStatNamespaces object owned by the API object, and user-defined metrics
created by these extensions are all prefixed by the namespace. For example,
Wasm extension registers "wasmcustom" as a custom stat namespace,
and all the metrics created by user Wasm programs are prefixed by "wasmcustom." internally.
This is mainly for distinguishing these "custom metrics" defined outside Envoy codebase from
the native metrics defined by Envoy codebase, and this way stat sinks are able to determine
how to expose these two kinds of metrics.

Notably this commit fixes #14920 and istio/istio#27635 by making changes to
prometheus stat handler so that it strips the metrics names prefixed
by custom stat namespaces and exposes the stripped ones as-is in the output.
Previously in the prometheus stat handler, Envoy prefixes all the metrics by "envoy_" for those who do not have
the prefixes registered statistically via PrometheusStatsFormatter::registerPrometheusNamespace.
That was not a good UX because, for example, Wasm extension users cannot register their own
prometheus namespaces at runtime and therefore they end up having
all of their own metrics prefixed by "envoy_" unless they have their own Envoy builds.
Consequently, we no longer need the static prometheus namespace registration mechanism,
so this commit also deletes the unneeded API.

Signed-off-by: Takeshi Yoneda takeshi@tetrate.io

[mathetake]

@lizan could you take a quick view to see if my approach to thread-safety looks ok? I guess something like "dispatch on main thread" would be another approach rather than taking mutex like this, but I couldn't find the proper way to do that.

[lizan]

I'm not keen into this approach, doesn't the wasm foreign function implementation has access to dispatcher?

[mathetake]

yeah actually we can access to the main thread dispatcher here. Let me rework later.

[mathetake]

will do after the refactoring work here: proxy-wasm/proxy-wasm-cpp-host#183

[mathetake]

changed so we dispatch on main, rather than taking locks.

[PiotrSikora]

Since the overall goal seems to be avoiding the envoy_ prefix in Wasm metrics, couldn't we automatically do that for all metrics defined in Wasm, instead of adding those implementation-specific hostcalls?

[mathetake]

Since the overall goal seems to be avoiding the envoy_ prefix in Wasm metrics, couldn't we automatically do that for all metrics defined in Wasm, instead of adding those implementation-specific hostcalls?

ah that's good point and I think it's better UX. Let me rework.

[PiotrSikora]

I don't know enough about the current stats to know for sure, but isn't this too greedy? e.g. if someone defines cluster_foo metric in Wasm, wouldn't it automatically remove envoy_ prefix from all "native" metrics as well?

[mathetake]

yeah that's true.. maybe better have something like "is_native" flag in Metric class, and prefix "envoy_" based on it, rather than using registerPrometheusNamespace?

[PiotrSikora]

Yeah, that sounds good to me... although, it seems that such solution was discussed in #11808, but the prefix list was added instead. cc @lizan @mandarjog @ggreenway @jmarantz

[ggreenway]

I'm not familiar with wasm APIs at all, but could you require the plugin to register it's namespace, and clearly document that it should be specific to this plugin and not overlap with any existing native stat names, and that all plugin stats should be under that namespace? There's still the possibility of a plugin incorrectly registering for an incorrect prefix, but there's at least documentation about how to behave correctly to avoid such issues.

[PiotrSikora]

I guess my point is why do we have those "namespaces" in the first place, when in reality it's only about separating native Envoy metrics that append envoy_ prefix from those that don't?

[mathetake]

Sorry I'm on vacation but I noticed this.

Oh sorry to interrupt you, and thanks for taking your time.

If this is really specific to wasm then it seems unclean to put a bit in the general stats structure to handle a special case.

This bit, say "is_custom_metric" flag, will be only set by Wasm for now since afaik Wasn extension is the only extension which defines non-Envoy-native metrics dynamically. But in the future, maybe other extensions would have that ability to define custom metrics.

[mathetake]

ping @jmarantz , wdyt ^^? Do you think the purpose is not worth a bit?

[PiotrSikora]

@mathetake I think that we should do it, using flags to differentiate between Envoy's internal and Wasm/Lua/whatever metrics is much better UX than the need to register and use Prometheus namespaces.

[jmarantz]

I'm fine with this.

[mathetake]

OK thank you all, I will rework this PR and add a "is_custom_metric" flag in Metric class to differentiate Envoy native metrics from others.

[mathetake]

coverage failure in http/cache seems caused by this https://github.com/envoyproxy/envoy/runs/3402140077 https://dev.azure.com/cncf/envoy/_build/results?buildId=86179&view=logs&j=bbe4b42d-86e6-5e9c-8a0b-fea01d818a24&t=e00c5a13-c6dc-5e9a-6104-69976170e881 .. will raise another PR: #17817

[mathetake]

anyway I believe this is ready for review.

[mathetake]

sorry the one is actually for DCO - I used git revert xxx for reverting the DynamicName stuff (and pushed without realizing that would miss signed-off).

[mathetake]

How can we continue the dialog about getting a symbol-table-friendly way of making stats in wasm so we don't have catastrophic contention at scale?

I will open an issue for this! cc @PiotrSikora Do you want to say anything?

[jmarantz]

Looks great; couple of minor points and one concern around lifetime in your new StatName member var. But assuming at least the lifetime issue is commented on or just made safe by inspection, this is good from my end, and I'm ready for @mattklein123 to take another look.

[mattklein123]

Thanks for iterating on this!

[mathetake]

Thank you so much for your reviews! @mattklein123 @jmarantz

[mergeconflict]

unused here (only used in the impl)