EdColeman

One way to think of it is that each tag will create a unique time-series in some (most?) back ends. So, in addition to the number of metrics that are...

Would something like tracing work? If we could activate / de-activate tracing on-demand, then it seems that maybe would could collect the needed values for profiling and then turn them...

For example guidance, [Prometheus label guidelines](https://prometheus.io/docs/practices/instrumentation/#do-not-overuse-labels]) provides the following:, ``` As a general guideline, try to keep the cardinality of your metrics below 10, and for metrics that exceed that,...

While those are specific to Prometheus - my understanding is that they apply generally across various metric systems. There are similar limitations for things like InfluxDB and it all relates...

I was wondering if instead of going in a predictable order if the algorithm picked a random start point? Maybe treat the list of tables (by id?) as a ring...

Another "feature" may be to prioritize system tables - particularly the metadata table to make sure that the system tables are balanced first.

The process name and IP are set as common tags when the metrics are initialized and do not need to be added again. Common tags cannot be added once the...

Should this target an earlier branch? Maybe even a 2.1.x? While it may be easier to implement for elasticity, if this is addressing a source of possible race conditions (so,...

Did you intend to target this for 3.1 (current main) or as a fix to 2.1.3? You may need to adjust the target branch and resolve changes for 2.1.3.

If run on a schedule, and similar to FATEs, there could be some simple metrics - maybe error count and run-time would be enough. A non-zero error count could then...