Если вы собираете метрики через VictoriaMetrics, вы работаете в облаках, у вас большая инфраструктура, развернутая в нескольких зонах доступности, то в какой-то момент заметите, что счета за метрики начинают составлять ощутимый процент в счете за инфраструктуру.

Иногда этот момент совпадает с пробелами в графиках, из за того, что вы перегрузили сервис мониторинга своего облачного провайдера.

Когда мы говорим о сборе метрик в HA средах и VictoriaMetrics, обычно рассматриваются два пути:

  • Шардирование (Sharding): Каждый агент собирает свою часть данных. Если один шард падает — часть метрик теряется. Для критической инфраструктуры это неприемлемо.

  • Репликация (Replication): Вы запускаете 2+ идентичных инстанса VMAgent (по одному на зону). Каждый из них идет к одним и тем же таргетам и забирает одни и те же данные.

И тут начинаются проблемы:

  • Умножение нагрузки: Если у вас 3 реплики агента, ваш сервис-таргет получает в 3 раза больше запросов. Если сервис и так нагружен, лишний парсинг метрик может его "добить".

  • Лимиты и деньги: Если вы собираете метрики из внешних API или платных сервисов, где тарификация идет за запросы, ваши расходы растут линейно количеству реплик.

  • Смещение по времени:  Реплики могут приходить за данными в разное время, что иногда приводит к "ступенькам" на графиках при переключении между источниками данных.

Мы столкнулись с этим при масштабировании к��астера VictoriaMetrics: переход на 3 реплики для трёхзонной отказоустойчивости утроил счёт за сбор метрик из облачных сервисов. Было больно.

Чтобы решить эти проблемы, я разработал Metric Cacher Exporter. Это легковесный кеширующий прокси-сервис на Go, который встает между агентом сбора (Prometheus/VictoriaMetrics) и сервис-таргетами.

Как это работает?

  1. Кэшер проверяет наличие данных в Redis.

  2. Если данных нет, он идет в upstream (реальный сервис).

  3. Сохраняет результат в Redis с заданным TTL.

  4. Отдает ответ агенту.

Если одновременно приходит несколько одинаковых запросов — в Upstream идёт только один, остальные ждут ответа.

На наших инсталляциях внедрение metric-cacher-exporter позволило снизить затраты на сервис сбора метрик примерно на 70-80%.

Внедрение за 5 минут:

Интеграция с vmagent — через relabel_configs без изменения таргетов:

scrape_configs:
  - job_name: "my-app"
    scrape_interval: 60s
    params:
      cacheTTL: ["55"]  # TTL < scrape_interval
    static_configs:
      - targets: ["my-service:9090"]  # оригинальный адрес
    relabel_configs:
      # Перенаправляем запрос через кешер
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: metric-cacher-exporter:8080  # адрес кешера

Иногда самое эффективное решение - не очередной "распределённый супер-кластер", а простой прокси с "умным" кешированием.

Проект opensource, исходный код доступен на GitHub. Issue и MR приветствуются.

GitHub: https://github.com/spions/metric-cacher-exporter
Docker Hub: spions/metric-cacher-exporter:latest