feature: [victoria-metrics-distributed] add native vmestimator integration

feature: [victoria-metrics-distributed] add native vmestimator integration

Chart name and version, where you feel a lack of requested feature

Chart: victoria-metrics-distributed
Version: latest

Is your feature request related to a problem? Please describe.

VictoriaMetrics now provides vmestimator for real-time cardinality estimation, as well as an official victoria-metrics-estimator Helm chart.

The recommended architecture is to replicate remote-write traffic from vmagent to both the normal VictoriaMetrics destination and vmestimator, for example:

                   -> VictoriaMetrics
vmagent -----------|
                   -> vmestimator

For a victoria-metrics-distributed deployment, all write traffic normally passes through the per-zone VMAgents before reaching the VMCluster in each zone.

A typical deployment looks like:

                         -> zone-1 VMAgent -> zone-1 VMCluster
clients -> global VMAuth |
                         -> zone-2 VMAgent -> zone-2 VMCluster

This makes a zone VMAgent a useful point for sending a copy of the complete ingest stream to vmestimator.

Currently there does not appear to be a straightforward native configuration in the victoria-metrics-distributed chart to:

1. Deploy vmestimator.
2. Select one or more zones whose VMAgents should replicate traffic to it.
3. Add the vmestimator destination without replacing the automatically generated remote-write destination to the zone's VMCluster.
4. Configure the vmestimator remote-write destination with disableOnDiskQueue=true so an unavailable estimator cannot affect the production ingestion path.

This currently requires maintaining additional Kubernetes resources and/or customizing the VMAgent topology outside the distributed chart.

Describe the solution you'd like

It would be useful if victoria-metrics-distributed could optionally integrate the existing official victoria-metrics-estimator chart.

For example, something conceptually similar to:

vmestimator:
  enabled: true

  mode: single

  source:
    zones:
      - zone-1

  config:
    data:
      streams:
        - interval: 5m
        - interval: 5m
          group_by:
            - __name__
        - interval: 5m
          group_by:
            - __label__

  serviceMonitor:
    enabled: true

When enabled, the selected zone VMAgents could automatically receive an additional remote-write destination:

zone VMAgent
  |
  +--> zone VMCluster
  |
  +--> vmestimator

with the equivalent behavior of:

-remoteWrite.url=<zone VMCluster>
-remoteWrite.url=http://<vmestimator-service>:8490/cardinality/api/v1/write

-remoteWrite.disableOnDiskQueue=false,true
-remoteWrite.disableMetadata=false,true

The exact values API is only a suggestion; another implementation would also work.

Zone selection

For multi-zone deployments, I think it would be useful to allow explicitly selecting which zone(s) forward data to vmestimator.

For example:

vmestimator:
  source:
    zones:
      - zone-1

The reason is that the same ingest stream may be replicated to multiple zones.

Sending traffic from every zone to a single vmestimator may result in unnecessary duplicate processing.

Selecting one zone would provide a simple way to estimate cardinality for the complete ingest stream without doubling the input workload.

Users who prefer availability over reduced processing could explicitly enable multiple zones.

Cluster mode

Since the official victoria-metrics-estimator chart already supports:

mode: single

and:

mode: cluster

it would be great if the distributed chart could reuse the existing estimator chart rather than implementing another vmestimator deployment template.

For small and medium installations:

Zone VMAgents -> vmestimator single

For larger installations:

Zone VMAgents -> vmestimator storage nodes
                          |
                          v
                    vmestimator select

Describe alternatives you've considered

1. Deploy victoria-metrics-estimator as a separate Helm release and manually modify the VMAgent configuration.

2. Create an external VMAgent resource with multiple remote-write destinations and reference it from the distributed deployment.

3. Send data to vmestimator from an upstream collection VMAgent instead of the zone VMAgent.

The third option works when all metrics originate from that VMAgent, but it does not provide complete visibility when multiple Prometheus/vmagent/remote-write clients write through the distributed VictoriaMetrics endpoint.

Additional context

The main goal is to make cardinality analysis a first-class optional capability of a distributed VictoriaMetrics installation:

Prometheus / VMAgent / remote_write clients
                  |
                  v
             global VMAuth
                  |
          +-------+-------+
          |               |
          v               v
   zone-1 VMAgent   zone-2 VMAgent
          |               |
          |               +--> zone-2 VMCluster
          |
          +--> zone-1 VMCluster
          |
          +--> vmestimator

vmestimator should remain completely optional and outside the critical production write path. If it is unavailable, normal VictoriaMetrics ingestion should continue unaffected.

Start by reviewing the victoria-metrics-distributed chart and the official victoria-metrics-estimator Helm chart to understand how deployment modes, zone selection, and VMAgent remote-write destinations are configured. Done should provide optional estimator integration, preserve the generated VMCluster destination, support the requested estimator settings, and keep estimator unavailability from disrupting production ingestion.