metric name tenant

[yuchen-db]

Added a new flag --receive.metric-name-shards that creates tenant sharding based on metric names.

How it works:

• When flag is set to N (e.g. 64), it hashes metric names and creates N tenants
• Router mode: Changes tenant from my-tenant to hashring-name-35 (where 35 = hash(metric_name) % 64)
• Ingestor mode: Only queries TSDBs that match the metric's shard instead of all TSDBs

Benefits:

• Creates finer-grained tenant separation based on metric names
• Reduces query fan-out in ingestors (no need for cuckoo filter)

Note that routing is not changed at all. It is more complicated and we will have another PR to address it.

[hczhu-db]

Thanks for starting the first V2 PR. There are still some implementation decisions to make and we need to meet and discuss.
At the high level, let's separate the write path and read path in different PRs.

[hczhu-db]

We should use a configmap for the sharding schema instead of a command flag. Thanos Router needs to support the schema defined in the V2 design doc. It has special metric groups besides the number of shards for each metric scope.

  scopeName: "az-eastus2",
  shards: 20,
  // The metrics that are heavily used by alert rules or have super high cardinality
  // can be in special groups to avoid skewed data partitions.
  specialMetricGroups: [
    {
      name: "kube-metrics",
      metrics: [
        "container_cpu_usage_seconds_total",
        "container_memory_working_set_bytes"
      ]
    },
    {
      name: "rpc-metrics",
      metrics: ["rpc_client_requests_total"]
    }
  ]
}

=== shard name calculation ===

if metric_name in any special metric group then
  shard_name = the speical metric group name
else
  shard_name = hash(metric_name) % shards

[hczhu-db]

What semantics will hashringName have in our context?

[yuchen-db]

let's discuss in meeting. Deleted the screenshot in this public repo