Multi-cluster Prometheus: remote_write в централизованное хранилище

Published: 2026-05-10

В каждом кластере работает собственный Prometheus (через kube-prom-stack). Для долгосрочных трендов, кросс-кластерных сравнений и хранения метрик дольше, чем позволяет spoke-кластер, spoke-экземпляры Prometheus пишут через remote_write в центральный VictoriaMetrics на infra-кластере.

Конфигурация remote_write

Настройка живёт в values kube-prom-stack и применяется к каждому spoke-кластеру Kustomize-патчем:

yaml# patches/kube-prom-stack.yaml (окружение dev)
spec:
  values:
    prometheus:
      prometheusSpec:
        externalLabels:
          cluster: dev
          environment: dev
        remoteWrite:
          - url: "http://victoria-metrics.observability.infra.svc.cluster.local:8428/api/v1/write"
            queueConfig:
              capacity: 10000
              maxSamplesPerSend: 1000
              maxShards: 10
            writeRelabelConfigs:
              - sourceLabels: [__name__]
                regex: "(node_|container_|kube_|up|probe_).+"
                action: keep
        retention: 3d
        retentionSize: "10GB"

externalLabels.cluster: dev помечает каждую серию именем кластера — это важно для кросс-кластерных дашбордов, где нужна фильтрация по кластеру. retention: 3d держит spoke-хранилище компактным, поскольку исторические данные живут в VictoriaMetrics.

URL remote_write между кластерами

На YC-кластерах и on-prem k3s VictoriaMetrics недоступна через внутренний DNS (это другой кластер). Два варианта:

Вариант 1: опубликовать VictoriaMetrics через APISIX (проще)

yaml# ApisixRoute на infra
- name: vm-remote-write
  match:
    hosts:
      - vm-write.infra.test.antonnovikov.com
    paths:
      - /api/v1/write
  backends:
    - serviceName: victoria-metrics-victoria-metrics
      serviceNamespace: observability
      servicePort: 8428

yaml# URL remote_write в spoke patches
remoteWrite:
  - url: "https://vm-write.infra.test.antonnovikov.com/api/v1/write"

Вариант 2: WireGuard VPN между кластерами — spoke-кластеры подключаются к infra через VPN и обращаются к внутреннему ClusterIP напрямую.

writeRelabelConfigs для снижения трафика

Отправлять все серии Prometheus в центральное хранилище расточительно. writeRelabelConfigs фильтрует только самые полезные метрики:

yamlwriteRelabelConfigs:
  # Оставляем: инфраструктурные метрики
  - sourceLabels: [__name__]
    regex: "(node_|container_|kube_state_|up|probe_|kubelet_).+"
    action: keep
  # Отбрасываем: высококардинальные шумные метрики
  - sourceLabels: [__name__]
    regex: "(go_gc_|go_memstats_|process_).+"
    action: drop
  # Отбрасываем: метрики короткоживущих подов (заменяем recording rules)
  - sourceLabels: [__name__, pod]
    regex: "container_.+;.+-[a-z0-9]{10}-.+"
    action: drop

Это снижает трафик remote_write на ~60–70% по сравнению с отправкой всего подряд.

Кросс-кластерный дашборд в Grafana

Когда все кластеры пишут в VictoriaMetrics, один дашборд в Grafana позволяет сравнивать их:

sum by (cluster) (
  rate(container_cpu_usage_seconds_total{container!=""}[5m])
)

Добавляем template-переменную для фильтрации:

json{
  "name": "cluster",
  "type": "query",
  "query": "label_values(up, cluster)",
  "datasource": "VictoriaMetrics"
}

Переменная заполняется из лейбла cluster, который добавляет externalLabels.

Проверка работоспособности remote_write

bash# На spoke: проверяем очередь remote_write
kubectl port-forward -n observability svc/prometheus-operated 9090:9090
# Затем: http://localhost:9090/graph?g0.expr=prometheus_remote_storage_queue_length

# На infra: проверяем скорость приёма в VictoriaMetrics
kubectl port-forward -n observability svc/victoria-metrics-victoria-metrics 8428:8428
# Затем: http://localhost:8428/api/v1/query?query=sum(rate(vm_rows_inserted_total[5m]))

Ошибки remote_write отражаются в prometheus_remote_storage_failed_samples_total. Устойчивое ненулевое значение означает, что центральный VictoriaMetrics недоступен или отклоняет записи.

Срок хранения и размер хранилища VictoriaMetrics

VictoriaMetrics на infra-кластере хранит метрики от всех spoke. Настройки:

yaml# values HelmRelease VictoriaMetrics
server:
  retentionPeriod: 90d
  persistentVolume:
    size: 50Gi
  resources:
    requests:
      memory: 2Gi
      cpu: 500m
    limits:
      memory: 4Gi

При 3 spoke-кластерах, пишущих ~500k samples/min каждый, 90 дней помещается в ~30–40Gi. VictoriaMetrics сжимает данные значительно лучше, чем Prometheus TSDB (~10x), поэтому реальное потребление диска намного ниже.

Аутентификация для remote_write

Если VictoriaMetrics доступна из интернета (через APISIX), включить basic auth:

yaml# VictoriaMetrics: включить basic auth
server:
  extraArgs:
    httpAuth.username: "prom-writer"
    httpAuth.password: "strong-password"

yaml# Spoke Prometheus remote_write
remoteWrite:
  - url: "https://vm-write.infra.test.example.com/api/v1/write"
    basicAuth:
      username:
        name: vm-remote-write-secret
        key: username
      password:
        name: vm-remote-write-secret
        key: password

Секрет — SealedSecret, закоммиченный в spoke overlay.

Алертинг на задержку remote_write

PrometheusRule для алерта при росте очереди remote_write:

yaml- alert: RemoteWriteQueueFull
  expr: >
    prometheus_remote_storage_queue_length /
    prometheus_remote_storage_queue_capacity > 0.8
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "Очередь remote_write > 80% на {{ $labels.cluster }}"
    description: "VictoriaMetrics может быть недоступна или работать медленно"

weblog