Агент VictoriaMetrics (vmagent)#

Описание#

vmagent — это агент, предназначенный для сбора метрик из различных источников, их перетегирования и фильтрации, а также последующего сохранения в VictoriaMetrics или в другие системы хранения данных по протоколу Prometheus remote_write, либо по протоколу VictoriaMetrics remote_write.

Функциональные особенности vmagent:

• Может использоваться в качестве прямой замены Prometheus для обнаружения и сбора метрик с целей, таких как node_exporter. Однокомпонентная версия Victoriametrics также может обнаруживать и собирать метрики с целей, совместимых с Prometheus, аналогично тому, как это делает vmagent.

• Поддерживает добавление, удаление и изменение меток (тегов) с использованием механизма перетегирования (relabeling) Prometheus. Позволяет фильтровать данные до отправки в удаленное хранилище.

• Может принимать данные по всем протоколам приема данных, поддерживаемым VictoriaMetrics.

• Поддерживает агрегацию входящих показателей по времени и по меткам перед отправкой в удаленное хранилище.

• Обеспечивает репликацию собранных метрик одновременно в несколько систем удаленного хранения, совместимых с Prometheus (подробнее см. в разделе «Репликация и высокая доступность»).

• Позволяет снизить затраты на исходящий трафик при использовании протокола удаленной записи VictoriaMetrics remote_write для передачи данных в VictoriaMetrics.

• Бесперебойно работает в средах с нестабильным соединением с удаленным хранилищем. В случае недоступности хранилища собранные метрики буферизуются в каталоге, указанном в параметре -remoteWrite.tmpDataPath. После восстановления соединения данные отправляются в хранилище. Максимальный объем дискового пространства, выделяемый под буфер, может быть ограничен с помощью параметра -remoteWrite.maxDiskUsagePerURL.

• Потребляет значительно меньше оперативной памяти, вычислительных ресурсов, дискового I/O и сетевой полосы пропускания по сравнению с Prometheus. Потребление RAM и CPU может быть дополнительно снижено при необходимости (подробнее см. в разделе «Оптимизация производительности»).

• При необходимости опроса большого количества целей возможно распределение задач между несколькими экземплярами vmagent (подробнее см. в разделе «Сбор метрик с целей через прокси»).

• Поддерживает загрузку конфигураций опроса из нескольких файлов (подробнее см. в разделе «Загрузка конфигураций сбора метрик из нескольких файлов»).

• Эффективно собирает метрики с цели, предоставляющие миллионы временных рядов, например, endpoint /federate в Prometheus (подробнее см. в разделе «Режим потокового парсинга»).

• Позволяет решать проблемы, связанные с высокой кардинальностью и высокой скоростью изменения меток (churn rate), за счет ограничения количества уникальных временных рядов на этапе опроса и перед отправкой в удаленные системы хранения (подробнее см. в разделе «Ограничитель кардинальности»).

• Поддерживает запись собранных метрик в несколько участников (tenants) (подробнее см. в разделе «Multitenancy»).

Варианты использования#

Мониторинг IoT и Edge-устройств#

vmagent может функционировать и собирать метрики в IoT-средах и промышленных сетях, где соединение с удаленным хранилищем может быть ненадежным или периодическим. Собранные данные буферизуются в локальных файлах до восстановления соединения, после чего vmagent отправляет накопленные данные в удаленное хранилище. Отправка данных повторяется до тех пор, пока ошибки не будут устранены. Максимальный объем данных на диске для буферизации можно ограничить с помощью параметра -remoteWrite.maxDiskUsagePerURL.

vmagent поддерживает различные архитектуры, используемые в IoT: 32-разрядный и 64-разрядный ARM, ppc64, 386, amd64.

Использование протокола VictoriaMetrics remote_write (подробнее см. в разделе «Протокол Victoriametrics remote write») позволяет снизить расходы на сетевой трафик.

Прямая замена Prometheus#

vmagent может выступать в роли прямой замены Prometheus в тех случаях, когда основной задачей Prometheus является сбор метрик с различных целей и их последующая передача в удаленное хранилище. Как правило, vmagent требует меньше оперативной памяти, процессорного времени и сетевой полосы пропускания по сравнению с Prometheus. Подробнее см. раздел «Сбор метрик в формате Prometheus с помощью vmagent».

Альтернатива StatsD#

vmagent может выступать в роли полноценной замены традиционного агента StatsD. Это позволяет не только принимать метрики в формате StatsD, но и выполнять их агрегацию, фильтрацию и отправку в VictoriaMetrics или другие системы хранения с минимальными расходами.

Включение приема метрик StatsD#

Для приема метрик в формате StatsD необходимо указать адрес и порт с помощью параметра:

-statsdListenAddr=:9125

По умолчанию используется UDP. Для TCP укажите:

-statsdListenAddr=tcp://:9125

Пример запуска:

./vmagent \
  -statsdListenAddr=:9125 \
  -remoteWrite.url=https://victoria-metrics:8428/api/v1/write

После этого vmagent будет принимать метрики в формате StatsD, например:

service.request.duration:0.2|ms
service.requests:1|c

Включение потоковой агрегации#

Чтобы vmagent агрегировал метрики (например, усреднял таймеры или суммировал счетчики), необходимо включить потоковую агрегацию с помощью параметра:

-streamAggr.config=/path/to/stream-aggr.yml

Пример конфигурации потоковой агрегации#

Создайте файл stream-aggr.yml:

# Агрегация: таймеры запросов
- match: 'stats.timers.service.*.request.duration'
  output: 'http_request_duration_seconds'
  scale: 0.001  # конвертация из мс в секунды
  interval: 60s
  functions:
    - avg
    - sum
    - count
    - histogram
  labels:
    service: "${1}"
    unit: "seconds"

# Агрегация: счетчики запросов
- match: 'stats.counters.service.*.requests'
  output: 'http_requests_total'
  interval: 60s
  functions:
    - sum
  labels:
    service: "${1}"

Запуск vmagent с агрегацией#

./vmagent \
  -statsdListenAddr=:9125 \
  -remoteWrite.url=https://victoria-metrics:8428/api/v1/write \
  -streamAggr.config=/etc/vmagent/stream-aggr.yml

Отправка тестовых данных#

Пример отправки метрик через netcat:

echo "stats.timers.service.api.request.duration:150|ms" | nc -u -w 1 localhost 9125
echo "stats.counters.service.api.requests:1|c" | nc -u -w 1 localhost 9125

Через 60 секунд агрегированные метрики появятся в VictoriaMetrics.

Обогащение метрик#

Можно добавить дополнительные метки с помощью relabeling:

- source_labels: [service]
  target_label: job
  replacement: "statsd-ingest"

И применить через параметр:

-remoteWrite.relabelConfig=/etc/vmagent/relabel.yml

Гибкий ретранслятор метрик#

vmagent может принимать метрики в различных популярных протоколах приема данных (подробнее см. раздел «Прием данных в vmagent по протоколам push»), применять relabeling к принятым метрикам (например, изменять имена/метки метрик или удалять ненужные метрики), а затем пересылать переработанные метрики другим системам удаленного хранения, которые поддерживают протокол Prometheus remote_write (включая другие экземпляры vmagent).

Репликация и высокая доступность#

vmagent реплицирует собранные метрики между несколькими экземплярами удаленного хранилища, указанными через параметры -remoteWrite.url. Если один из экземпляров временно недоступен, данные остаются доступными в других хранилищах. Несоответствующие данные буферизуются в файлах по пути, заданному в -remoteWrite.tmpDataPath, и отправляются после восстановления соединения, что предотвращает появление разрывов в данных.

Кластерная версия VictoriaMetrics уже включает встроенную поддержку репликации, поэтому при записи данных в один и тот же кластер указывать несколько -remoteWrite.url не требуется.

Шардирование между удаленными хранилищами#

По умолчанию vmagent реплицирует данные на все хранилища, перечисленные в параметре -remoteWrite.url. Если задан параметр -remoteWrite.shardByURL, vmagent равномерно распределяет исходящие временные ряды между всеми указанными системами хранения.

Для реализации репликации при шардировании можно дополнительно использовать параметр -remoteWrite.shardByURLReplicas=N. Это приведет к тому, что каждый исходящий образец будет записан в N различных систем хранения, указанных в -remoteWrite.url, в дополнение к шардированию.

При включенном шардировании (-remoteWrite.shardByURL) образцы одного и того же временного ряда направляются в одну и ту же систему хранения. Это позволяет строить масштабируемые конвейеры обработки данных, когда одна система хранения не справляется с нагрузкой. Например, это позволяет создавать горизонтально масштабируемую потоковую агрегацию, направляя исходящие выборки для одного и того же временного ряда типов counter и histogram от экземпляров vmagent верхнего уровня одному и тому же экземпляру vmagent второго уровня, чтобы они правильно агрегировались.

По умолчанию при шардировании используются все метки метрик. В некоторых случаях может потребоваться использовать только определенный набор меток. Например, чтобы направлять все метрики с одинаковым значением метки instance в один и тот же -remoteWrite.url, можно указать список меток в параметре -remoteWrite.shardByURL.labels: -remoteWrite.shardByURL.labels=instance,__name__.

Также может потребоваться игнорировать некоторые метки при шардировании. Например, если все исходные образцы с одинаковым набором меток, кроме instance и pod, должны направляться в один бэкенд, можно использовать параметр -remoteWrite.shardByURL.ignoreLabels: -remoteWrite.shardByURL.ignoreLabels=instance,pod.

Подробнее см. в разделе «Сбор метрик с большого количества целей».

Переименование меток и фильтрация#

vmagent может добавлять, удалять или обновлять метки собранных данных перед их отправкой в удаленное хранилище. Кроме того, он может удалять нежелательные выборки с помощью механизма relabeling, аналогичного Prometheus, перед отправкой собранных данных в удаленное хранилище.

Разделение потоков данных между несколькими системами#

vmagent поддерживает разделение собранных данных между несколькими пунктами назначения с помощью параметра -remoteWrite.urlRelabelConfig, который применяется независимо к каждому указанному в -remoteWrite.url адресу. Например, можно реплицировать или разделять данные между долгосрочным и кратковременным хранилищами, а также системой анализа в реальном времени на базе Kafka. Каждое назначение может получать свой собственный поднабор данных благодаря индивидуальному перетегированию через -remoteWrite.urlRelabelConfig.

Например, допустим, все метрики, собираемые или принимаемые vmagent, имеют метку env со значениями dev или prod. Чтобы направлять метрики с env=dev в целевой адрес dev, а env=prod — в prod, используйте следующую конфигурацию:

1. Создайте файл конфигурации relabeling relabelDev.yml, чтобы удалить все метрики, не имеющие env=dev:

   - action: keep
     source_labels: [env]
     regex: "dev"
   

2. Создайте файл конфигурации relabeling relabelProd.yml, чтобы удалить все метрики, не имеющие env=prod:

   - action: keep
     source_labels: [env]
     regex: "prod"
   

3. Настройте vmagent с 2 флагами -remoteWrite.url и соответствующими файлами перетегирования:

   ./vmagent \
     -remoteWrite.url=http://<dev-url> -remoteWrite.urlRelabelConfig=relabelDev.yml \
     -remoteWrite.url=http://<prod-url> -remoteWrite.urlRelabelConfig=relabelProd.yml
   

В данной конфигурации vmagent будет отправлять в http://<dev-url> только метрики с env=dev, а в http://<prod-url> — только с env=prod.

Прокси Prometheus remote_write#

vmagent может использоваться в качестве прокси для данных Prometheus, передаваемых по протоколу remote_write. Он принимает данные через API remote_write на endpoint /api/v1/write, применяет перетегирование и фильтрацию, а затем пересылает их в другую систему, поддерживающую remote_write.

Входящие запросы remote_write могут быть зашифрованы с помощью параметров -tls*. Также можно включить аутентификацию по логину/паролю с помощью параметров -httpAuth.*.

remote_write для кластерной версии#

Хотя vmagent может принимать данные по различным поддерживаемым протоколам (OpenTSDB, Influx, Prometheus, Graphite) и опрашивать цели, запись всегда выполняется по протоколу Prometheus remote_write. Поэтому для кластерной версии VictoriaMetrics параметр -remoteWrite.url должен быть указан в формате: <schema>://<vminsert-host>:8480/insert/<accountID>/prometheus/api/v1/write.

Поддерживается также Multitenancy (подробнее см. в разделе «Multitenancy»).

Гибкая дедупликация#

Дедупликация на уровне потоковой агрегации позволяет настраивать сложные схемы устранения дубликатов. Примеры:

• Следующая команда указывает vmagent отправлять только последний образец для каждого временного ряда один раз в 60 секунд:

  ./vmagent -remoteWrite.url=http://remote-storage/api/v1/write -streamAggr.dedupInterval=60s
  

• Следующая команда указывает vmagent объединять временные ряды с разными значениями метки replica, а затем отправлять только последний образец для каждого объединенного ряда раз в 60 секунд:

  ./vmagent -remoteWrite.url=http://remote-storage/api/v1/write -streamAggr.dropInputLabels=replica -streamAggr.dedupInterval=60s
  

Прием данных в vmagent по протоколам push#

vmagent поддерживает тот же набор push-протоколов приема данных, что и Victoriametrics, в дополнение к pull-сбору метрик с целей, совместимых с Prometheus.

Поддерживаемые push-протоколы#

Протоколы, которые vmagent может принимать на вход:

• DataDog «submit metrics» API;

• InfluxDB line protocol;

• Graphite plaintext protocol;

• OpenTelemetry HTTP API;

• NewRelic API;

• Protocols OpenTSDB telnet and HTTP;

• Prometheus remote_write;

• JSON lines import protocol;

• Native data import protocol;

• Prometheus exposition format;

• Произвольные CSV-данные.

DataDog «submit metrics» API#

vmagent может принимать метрики от агента DataDog, DogStatsD и DataDog Lambda Extension, выступая в качестве промежуточного приемника (sidecar).

Endpoint для приема данных: vmagent слушает и принимает метрики по стандартному DataDog «submit metrics» API через:

• http://<victoriametrics-addr>:8429/datadog/api/v2/series — для отправки числовых метрик.

• http://<victoriametrics-addr>:8429/datadog/api/beta/sketches — для отправки скетчей (набросков распределений).

URL для настройки агента DataDog:

DD_DD_URL=http://<victoriametrics-addr>:8429/datadog

Где:

• <victoriametrics-addr>:8429 — адрес и порт, на котором запущен vmagent;

• /datadog — базовый путь, под которым vmagent ожидает DataDog-совместимый API.

InfluxDB line protocol#

vmagent может выступать в качестве приемника метрик по InfluxDB line protocol, принимая данные от агентов, таких как Telegraf, fluentd и других.

Endpoint для приема данных:

• http://<victoriametrics-addr>:8429/write — стандартный endpoint для отправки данных в формате InfluxDB line protocol (совместим с InfluxDB v1);

• http://<victoriametrics-addr>:8429/api/v2/write — endpoint, совместимый с API InfluxDB v2;

• http://<victoriametrics-addr>:8429/influx/write — альтернативный путь, часто используемый в конфигурациях HTTP-вывода агентов.

URL для настройки агента (например, Telegraf):

[[outputs.influxdb]]
  urls = ["http://<victoriametrics-addr>:8429"]

или для HTTP-вывода:

[[outputs.http]]
  url = "http://<victoriametrics-addr>:8429/influx/write"
  data_format = "influx"
  non_retryable_statuscodes = [400]

Оптимизация производительности: для обработки больших потоков данных рекомендуется включить streaming mode через HTTP-заголовок Stream-Mode: 1 или флаг -influx.forceStreamMode, что снижает потребление памяти и увеличивает пропускную способность.

Graphite plaintext protocol#

Для приема данных в Graphite-формате необходимо включить прослушивание порта с помощью параметра:

Endpoint: TCP/UDP порт, указанный в флаге -graphiteListenAddr (например, :2003):

/path/to/victoria-metrics-prod -graphiteListenAddr=:2003

Имена метрик могут быть санитизированы с помощью флага -graphite.sanitizeMetricName.

OpenTelemetry HTTP API#

vmagent принимает метрики в формате OpenTelemetry через HTTP:

http://<victoriametrics-addr>:8429/

Имена метрик и метки могут быть автоматически преобразованы в формат совместимый с Prometheus с помощью флага -opentelemetry.usePrometheusNaming.

NewRelic API#

vmagent может принимать метрики от NewRelic-агентов через:

http://<victoriametrics-addr>:8429/newrelic/infra/v2/metrics/events/bulk

Максимальный размер одного запроса можно настроить флагом -newrelic.maxInsertRequestSize (по умолчанию 64 МиБ).

Protocols OpenTSDB telnet and HTTP#

vmagent поддерживает прием данных в формате OpenTSDB как через telnet-интерфейс, так и через HTTP API.

Endpoint для приема данных (если флаги заданы):

• Telnet: подключиться к <victoriametrics-addr>:<port>, указанному в -opentsdbListenAddr.

• HTTP: http://<victoriametrics-addr>:<port>/api/put, где <port> указан в -opentsdbListenAddr или -opentsdbHTTPListenAddr.

/path/to/victoria-metrics-prod -opentsdbListenAddr=:4242

/path/to/victoria-metrics-prod -opentsdbHTTPListenAddr=:4242

Можно настроить обрезку временных меток с помощью флагов -opentsdbTrimTimestamp (для telnet) и -opentsdbhttpTrimTimestamp (для HTTP).

Prometheus remote_write#

vmagent может принимать данные по стандартному Prometheus remote_write через:

http://<vmagent>:8429/api/v1/write

Входящие запросы remote_write можно защитить с помощью TLS (-tls*) и Basic Auth (-httpAuth.*).

JSON lines import protocol#

Прием метрик в формате JSON по одной строке на метрику через:

http://<victoriametrics-addr>:8429/api/v1/import

Формат данных: каждая строка должна быть валидным JSON-объектом, описывающим одну метрику.

Native data import protocol#

Внутренний, высокоэффективный бинарный протокол VictoriaMetrics, предназначенный для быстрой передачи больших объемов данных между компонентами экосистемы VictoriaMetrics (например, из vmctl):

http://<victoriametrics-addr>:8429/api/v1/import/native

Рекомендуется для сценариев, где важна максимальная производительность и известно, что отправляемые данные совместимы с этим форматом.

Prometheus exposition format#

Прием данных в текстовом формате Prometheus (таком же, как /metrics) через:

http://<victoriametrics-addr>:8429/api/v1/import/prometheus

Удобен для отправки данных из скриптов или инструментов, которые умеют генерировать вывод в формате Prometheus.

Произвольные CSV-данные#

vmagent может импортировать метрики из CSV-файлов через:

http://<victoriametrics-addr>:8429/api/v1/import/csv

Пример запуска vmagent с поддержкой push-протоколов#

Этот запуск:

• принимает данные по всем push-протоколам;

• пересылает их в VictoriaMetrics;

• открывает HTTP-порт :8429 для приема Influx, OTLP, Prometheus и других.

./vmagent \
  -remoteWrite.url=https://victoria-metrics:8428/api/v1/write \
  -graphiteListenAddr=:2003 \
  -opentsdbListenAddr=:4242 \
  -httpListenAddr=:8429

Сбор метрик в формате Prometheus с помощью vmagent#

Укажите путь к файлу prometheus.yml с помощью флага -promscrape.config:

-promscrape.config=/path/to/prometheus.yml

vmagent учитывает следующие секции из файла конфигурации Prometheus:

• global;

• scrape_configs.

Пример:

global:
  scrape_interval: 15s
  external_labels:
    datacenter: eu-west

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['<IP_address_1>:9100', '<IP_address_2>:9100']

  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true

Все остальные секции игнорируются, включая remote_write. Используйте флаги -remoteWrite.* для настройки параметров remote_write.

Подстановка переменных окружения#

Файл, указанный в -promscrape.config, может содержать плейсхолдеры вида %{ENV_VAR}, которые автоматически заменяются значениями соответствующих переменных окружения.

Пример:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'nodes'
    static_configs:
      - targets: ['%{NODE_EXPORTER_HOST}:%{NODE_EXPORTER_PORT}']

При запуске:

NODE_EXPORTER_HOST=<IP_address_1> NODE_EXPORTER_PORT=9100 ./vmagent -promscrape.config=prometheus.yml -remoteWrite.url=https://victoria-metrics:8428/api/v1/write

Расширение функциональных возможностей scrape_config#

vmagent расширяет стандартную конфигурацию Prometheus, добавляя поддержку дополнительных опций в блоке scrape_configs:

• headers — список HTTP-заголовков, которые будут отправляться на цель сбора метрик с каждым запросом сбора. Это можно использовать, когда цели сбора метрик требуют пользовательской авторизации и аутентификации.

  Например:

  scrape_configs:
  - job_name: custom_headers
    headers:
    - "TenantID: abc"
    - "My-Auth: TopSecret"
  

• disable_compression: true для отключения сжатия ответа для конкретного задания. По умолчанию vmagent запрашивает сжатые ответы от целей сбора метрик для экономии сетевой полосы пропускания.

  Например:

  - job_name: no_compression
    disable_compression: true
  

• disable_keepalive: true для отключения HTTP-соединений с поддержкой keep-alive для конкретного задания. По умолчанию vmagent использует соединения с поддержкой keep-alive для целей сбора метрик, чтобы уменьшить накладные расходы на повторное установление соединения.

  Например:

  - job_name: no_keepalive
    disable_keepalive: true
  

• series_limit: N для ограничения количества уникальных временных рядов, которые может предоставить одна цель сбора метрик. Подробнее см. раздел «Ограничитель кардинальности».

  Например:

  - job_name: limited
    series_limit: 10000
  

• stream_parse: true для сбора метрик с целей потоковым способом. Это может быть полезно, когда цели предоставляют большое количество метрик. Подробнее см. раздел «Режим потокового парсинга».

  Например:

  - job_name: big_target
    stream_parse: true
  

• scrape_align_interval: duration для выравнивания сбора метрик по заданному интервалу вместо использования случайного смещения в диапазоне [0 ... scrape_interval] для сбора каждой цели. Случайное смещение помогает равномерно распределить сбор метрик во времени.

  Например:

  - job_name: aligned
    scrape_interval: 30s
    scrape_align_interval: 30s
  

• scrape_offset: duration для указания точного смещения для сбора метрик вместо использования случайного смещения в диапазоне [0 ... scrape_interval].

  Например:

  - job_name: offset
    scrape_interval: 20s
    scrape_offset: 5s
  

Загрузка конфигураций сбора метрик из нескольких файлов#

vmagent поддерживает загрузку scrape_configs из нескольких файлов через секцию scrape_config_files.

Пример основного файла prometheus.yml:

scrape_config_files:
  - configs/*.yml
  - single_scrape_config.yml
  - https://config-server/scrape_config.yml

Каждый из указанных файлов может содержать одну или несколько конфигураций scrape_config. Нет необходимости указывать верхний уровень scrape_configs в этих файлах.

Пример configs/nodes.yml:

- job_name: foo
  static_configs:
    - targets: ['vmagent:8429']

- job_name: bar
  kubernetes_sd_configs:
    - role: pod

Неподдерживаемые секции конфигурации Prometheus#

vmagent не поддерживает следующие секции в файле, указанном через флаг -promscrape.config:

• remote_write - секция заменена параметрами -remoteWrite.*. Исключена во избежание путаницы, особенно при использовании vmagent как приемника push-метрик;

• remote_read - секция не поддерживается, так как vmagent не предоставляет API запросов. Ожидается, что API предоставляется хранилищем, указанным в -remoteWrite.url, например, VictoriaMetrics;

• rule_files, alerting - секции поддерживаются в отдельном компоненте — vmalert.

Кроме того, vmagent не поддерживает опцию refresh_interval в секциях обнаружения сервисов. Эта опция заменяется флагами -promscrape.*CheckInterval, которые являются специфичными для каждого типа обнаружения сервисов.

Обновление конфигурации vmagent#

Параметры, заданные при запуске vmagent, требуют перезапуска для своего изменения. Однако конфигурационные файлы, указанные через определенные параметры, могут быть перезагружены динамически.

Поддерживаются следующие конфигурационные файлы:

• -promscrape.config — основной файл конфигурации сбора метрик;

• -remoteWrite.relabelConfig — правила relabeling перед отправкой;

• -remoteWrite.urlRelabelConfig — relabeling для конкретных URL;

• -streamAggr.config — конфигурация потоковой агрегации;

• -remoteWrite.streamAggr.config — альтернативный путь к конфигурации агрегации.

Способы перезагрузки конфигурации#

Отправка сигнала SIGHUP#

Для перезагрузки конфигурации можно отправить сигнал SIGHUP процессу vmagent:

kill -SIGHUP $(pidof vmagent)

HTTP-запрос к endpoint /-/reload#

vmagent предоставляет HTTP-запрос endpoint для принудительной перезагрузки конфигурации:

curl -X POST http://vmagent:8429/-/reload

Для защиты endpoint от несанкционированного доступа используйте параметр:

-reloadAuthKey=your-secret-key

После этого запрос должен включать заголовок авторизации:

curl -X POST http://vmagent:8429/-/reload -H 'Authorization: Bearer your-secret-key'

Автоматическая проверка изменений в конфигурации#

Для автоматической перезагрузки файла -promscrape.config при его изменении используйте параметр:

-promscrape.configCheckInterval=30s

Пример запуска:

./vmagent \
  -promscrape.config=/etc/vmagent/prometheus.yml \
  -promscrape.configCheckInterval=15s \
  -remoteWrite.url=https://victoria-metrics:8428/api/v1/write

URL-адреса SRV#

vmagent поддерживает использование DNS SRV-записей в URL-адресах через специальный префикс srv+. Это позволяет динамически разрешать адреса и порты удаленных сервисов без жесткой привязки к конкретным хостам и портам в конфигурации.

Если vmagent встречает URL с префиксом srv+ в имени хоста (например, http://srv+some-addr/some/path), он выполняет следующие действия:

1. Разрешает DNS SRV-запись для some-addr.

2. Получает TCP-адрес, включающий хост и порт.

3. Формирует результирующий URL и использует его при подключении.

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

SRV-адреса особенно полезны в следующих сценариях:

• HTTP-сервисы работают на разных TCP-портах.

• Порты сервисов могут меняться со временем (например, после перезапуска).

• Отсутствует централизованное управление статическими адресами.

• Требуется автоматическое обнаружение сервисов в динамической среде (Kubernetes, Mesos, Consul и др.).

Поддерживаемые контексты использования#

SRV-URL поддерживаются в следующих местах:

• В параметре -remoteWrite.url:

  Позволяет динамически определять адрес хранилища VictoriaMetrics через DNS SRV.

  Пример:

  Если DNS SRV-запись для victoria-metrics содержит TCP-адрес victoria-metrics-host:8428, то:

  -remoteWrite.url=http://srv+victoria-metrics/api/v1/write
  

  автоматически разрешается в:

  -remoteWrite.url=http://victoria-metrics-host:8428/api/v1/write
  

  Если SRV-запись возвращает несколько адресов, vmagent случайным образом выбирает один из них при каждом новом соединении.

  Это обеспечивает простейшее балансирование нагрузки между репликами хранилища.

• В адресах целей сбора (scrape targets), а именно в метке __address__:

  SRV-URL могут использоваться в service discovery, где динамически формируется адрес цели.

  Пример (в конфигурации relabel_configs):

  relabel_configs:
    - source_labels: [__meta_consul_service]
      target_label: __address__
      replacement: srv+${1}.service.consul:80
  

  Такой подход полезен при интеграции с Consul или другими системами service discovery, где сервисы могут работать на разных портах.

• В URL, используемых для service discovery:

  Некоторые типы service discovery (например, Consul, DNS) могут возвращать URL, содержащие srv+. vmagent корректно их обрабатывает, разрешая SRV-записи при необходимости.

Пример команды с использованием SRV#

Запуск vmagent с использованием SRV-адреса для отправки данных в VictoriaMetrics:

./vmagent \
  -remoteWrite.url=http://srv+victoria-metrics/api/v1/write \
  -promscrape.config=/etc/vmagent/prometheus.yml

Протокол Victoriametrics remote write#

vmagent поддерживает отправку данных в хранилища, указанные через параметр -remoteWrite.url, с использованием двух протоколов:

• протокол remote_write от Prometheus;

• протокол remote_write от VictoriaMetrics.

По умолчанию vmagent использует собственный протокол VictoriaMetrics remote_write, если целевое хранилище является совместимым компонентом VictoriaMetrics.

Протокол Victoriametrics remote_write предоставляет следующие преимущества по сравнению с протоколом Prometheus remote_write:

• Снижение использования сетевой полосы пропускания в 2-5 раз. Это позволяет экономить затраты на использование сетевой полосы пропускания, когда vmagent и настроенные системы удаленного хранения находятся в разных центрах обработки данных, зонах доступности или регионах.

• Снижение операций чтения/записи на диск и использования дискового пространства в vmagent, когда удаленное хранилище временно недоступно. В этом случае vmagent буферизует входящие данные на диск, используя формат Victoriametrics remote_write. Это снижает операции чтения/записи на диск и использование дискового пространства в 2-5 раз по сравнению с форматом Prometheus remote_write.

Режимы работы протокола#

Автоматический выбор протокола (по умолчанию)#

Начиная с версии v1.116.0, vmagent автоматически использует протокол VictoriaMetrics remote_write при отправке данных в совместимые компоненты:

• Другие экземпляры vmagent.

• Однокомпонентная версия VictoriaMetrics (-httpListenAddr=:8428).

• vminsert в кластерной версии VictoriaMetrics.

Принудительное использование протокола VictoriaMetrics#

Чтобы гарантированно использовать протокол VictoriaMetrics remote_write для определенного URL, укажите флаг:

-remoteWrite.forceVMProto=true

Пример команды:

./vmagent \
  -remoteWrite.url=https://victoria-metrics:8428/api/v1/write \
  -remoteWrite.forceVMProto=true

Принудительное использование протокола Prometheus#

vmagent автоматически переключается на протокол Prometheus remote_write, когда отправляет данные старым версиям компонентов Victoriametrics или другим системам удаленного хранения, совместимым с Prometheus.

Для принудительного использования стандартного Prometheus remote_write (например, при отправке в Cortex, Thanos или старые версии VictoriaMetrics) используйте:

-remoteWrite.forcePromProto=true

Пример:

./vmagent \
  -remoteWrite.url=https://cortex-gateway/api/v1/push \
  -remoteWrite.forcePromProto=true

Настройка уровня сжатия#

Уровень сжатия данных при использовании протокола VictoriaMetrics remote_write можно настроить с помощью параметра:

-remoteWrite.vmProtoCompressLevel=N

Где N — целое число от -22 до 22:

• Положительные значения: сильнее сжатие → меньше трафик, но выше нагрузка на CPU.

• Отрицательные значения: слабее сжатие → меньше нагрузка на CPU, но больше трафик.

• Значение по умолчанию: 0.

Примеры:

# Максимальное сжатие (высокая нагрузка на CPU)
-remoteWrite.vmProtoCompressLevel=22

# Минимальная нагрузка на CPU (меньше сжатие)
-remoteWrite.vmProtoCompressLevel=-22

# Баланс по умолчанию (рекомендуется)
-remoteWrite.vmProtoCompressLevel=0

Примеры конфигурации#

• Отправка в однокомпонентную версию VictoriaMetrics с использованием VictoriaMetrics remote_write:

  ./vmagent \
    -remoteWrite.url=https://victoria-metrics-host:8428/api/v1/write \
    -remoteWrite.forceVMProto=true \
    -remoteWrite.vmProtoCompressLevel=3
  

• Отправка в кластер VictoriaMetrics с автоматическим выбором протокола:

  ./vmagent \
    -remoteWrite.url=https://vminsert-0:8480/insert/0/prometheus \
    -remoteWrite.url=https://vminsert-1:8480/insert/0/prometheus \
    -remoteWrite.shardByURL=true
  

Мониторинг использования протокола#

Для диагностики используемого протокола и производительности можно использовать метрики:

• Количество запросов remote_write:

  sum(rate(vmagent_remotewrite_requests_total[1m]))
  

• Средний размер сжатого блока:

  sum(rate(vmagent_remotewrite_conn_bytes_written_total[1m])) / 
  sum(rate(vmagent_remotewrite_requests_total[1m]))
  

• Количество неудачных попыток:

  vmagent_remotewrite_push_failures_total
  

Multitenancy#

vmagent поддерживает режим Multitenancy, позволяющий маршрутизировать метрики в различные тенанты VictoriaMetrics кластера. Это особенно полезно в многопользовательских средах, где требуется изоляция данных между организациями, проектами или окружениями.

Режим по умолчанию#

По умолчанию vmagent собирает метрики без указания идентификаторов тенантов и отправляет их в хранилище, указанное через параметр -remoteWrite.url.

Если -remoteWrite.url указывает на путь вида: /insert/<tenant_id>/prometheus/api/v1/write в vminsert компоненте кластера VictoriaMetrics, тогда все метрики будут записаны в тенант с идентификатором <tenant_id>.

Пример:

-remoteWrite.url=https://vminsert:8480/insert/12345:0/prometheus/api/v1/write

Все метрики будут записаны в тенант 12345:0.

Запись метрик в несколько тенантов#

Самый простой способ отправлять метрики в разные тенанты — использовать метки vm_account_id и vm_project_id, а затем направлять данные в Multitenancy URL кластера VictoriaMetrics.

Эти метки можно добавить с помощью relabeling до отправки в -remoteWrite.url.

Пример: назначение тенанта через аннотации Kubernetes#

Следующее правило relabeling извлекает идентификатор учетной записи из аннотации prometheus.io/account_id у pod и добавляет метку vm_account_id:

scrape_configs:
- kubernetes_sd_configs:
  - role: pod
  relabel_configs:
  - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_account_id]
    target_label: vm_account_id

После этого, при отправке метрик в Multitenancy URL, vmagent автоматически маршрутизирует их в соответствующий тенант.

Прием данных через Multitenancy endpoint#

Чтобы vmagent мог принимать данные через Multitenancy endpoint (аналогично vminsert), необходимо включить соответствующий режим с помощью параметра:

-enableMultitenantHandlers

После включения vmagent начнет принимать данные на endpoint вида:

/insert/<accountID>/<suffix>

Например:

http://vmagent:8429/insert/12345:67890/api/v1/write

Автоматическое преобразование идентификаторов тенантов#

При использовании -enableMultitenantHandlers vmagent автоматически преобразует идентификаторы тенантов из URL в метки:

• vm_account_id;

• vm_project_id.

Эти метки добавляются до применения правил relabeling, заданных через:

• -remoteWrite.relabelConfig;

• -remoteWrite.urlRelabelConfig.

Таким образом, последующие правила могут использовать эти метки для фильтрации, модификации или маршрутизации метрик.

Маршрутизация метрик в тенанты#

Если метрики содержат метки vm_account_id и vm_project_id, их можно направить в соответствующие тенанты кластера VictoriaMetrics, указав Multitenancy URL в -remoteWrite.url.

Пример:

-remoteWrite.url=https://vminsert:8480/insert/0:0/prometheus/api/v1/write

Пример полной конфигурации#

./vmagent \
  -enableMultitenantHandlers \
  -remoteWrite.url=https://vminsert:8480/insert/0:0/prometheus/api/v1/write \
  -promscrape.config=/etc/vmagent/prometheus.yml \
  -httpListenAddr=:8429

С этим запуском:

• vmagent принимает данные на /insert/<accountID>/<suffix>;

• извлекает vm_account_id и vm_project_id из URL;

• отправляет метрики в кластер VictoriaMetrics с динамическим определением тенанта по меткам.

Добавление меток к метрикам#

vmagent поддерживает несколько способов добавления дополнительных меток к собираемым метрикам. Это позволяет обогащать данные контекстом, таким как зона размещения, окружение, теги сервисов и т.д., что особенно полезно при централизованном сборе и анализе метрик.

Источники дополнительных меток#

Дополнительные метки могут быть добавлены с помощью следующих механизмов:

• Секция global -> external_labels в файле -promscrape.config:

  Метки, указанные в секции external_labels, добавляются только к метрикам, собранным через scraping (т.е. из Prometheus-совместимых целей).

  Пример конфигурации (prometheus.yml):

  global:
    scrape_interval: 15s
    external_labels:
      datacenter: eu-west
      environment: production
  

  Запуск vmagent:

  /path/to/vmagent -promscrape.config=prometheus.yml -remoteWrite.url=https://victoria-metrics:8428/api/v1/write
  

  Примечание

  Эти метки не применяются к метрикам, полученным через push-протоколы (Influx, OTLP, Prometheus remote_write и др.).

• Параметр -remoteWrite.label:

  Позволяет добавить метки ко всем метрикам, которые vmagent отправляет в хранилища, указанные через -remoteWrite.url, независимо от способа их получения (scraping или push).

  Пример:

  /path/to/vmagent \
    -remoteWrite.label=datacenter=us-central \
    -remoteWrite.label=cluster=prod-east \
    -remoteWrite.url=https://victoria-metrics:8428/api/v1/write
  

  Эта команда добавит метки {datacenter="us-central", cluster="prod-east"} ко всем метрикам, включая те, что пришли через:

  • remote_write;

  • InfluxDB line protocol;

  • OpenTelemetry8;

  • Graphite и другие протоколы.

  Примечание

  Параметр можно указывать несколько раз для добавления нескольких меток.

• Relabeling (переопределение меток):

  Наиболее гибкий способ — использование правил relabeling. Позволяет добавлять, изменять или удалять метки на основе других меток или метаданных.

  Правила relabeling применяются:

  • Перед отправкой в -remoteWrite.url;

  • К всем метрикам (как scraped, так и полученным через push).

  Пример: добавление метки на основе аннотации Kubernetes

  - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_job]
    target_label: job
    regex: (.+)
    replacement: ${1}
  

  Пример: добавление фиксированной метки через relabeling

  - target_label: source
    replacement: vmagent-edge
  

  Использование в конфигурации:

  ./vmagent \
    -remoteWrite.url=https://victoria-metrics:8428/api/v1/write \
    -remoteWrite.relabelConfig=/etc/vmagent/relabel.yml
  

Автоматически генерируемые метрики#

vmagent автоматически генерирует набор служебных метрик для каждого опроса (scrape) цели, совместимой с Prometheus. Эти метрики позволяют отслеживать состояние, производительность и поведение сбора данных.

Все автоматически генерируемые метрики снабжаются метками instance, job и другими, специфичными для целей, что позволяет агрегировать и фильтровать их по источникам.

Список автоматически генерируемых метрик:

• up — эта метрика имеет значение 1 при успешном сборе метрик и значение 0 при неудачном сборе. Это позволяет отслеживать неудачные сборы метрик с помощью следующего запроса MetricsQL: up == 0.

• scrape_duration_seconds — продолжительность сбора метрик для данной цели. Это позволяет отслеживать медленные сборы метрик. Например, следующий запрос MetricsQL возвращает сборы метрик, которые занимают более 1,5 секунды: scrape_duration_seconds > 1.5.

• scrape_timeout_seconds — настроенный тайм-аут для текущей цели сбора метрик (также известный как scrape_timeout). Это позволяет обнаруживать цели, у которых продолжительность сбора метрик близка к настроенному тайм-ауту сбора. Например, следующий запрос MetricsQL возвращает цели (идентифицируемые по метке instance), у которых сбор метрик занимает более 80% от настроенного scrape_timeout: scrape_duration_seconds / scrape_timeout_seconds > 0.8.

• scrape_response_size_bytes — размер ответа в байтах для данной цели. Это позволяет отслеживать объем собираемых данных и настраивать опцию max_scrape_size для целей сбора метрик. Например, следующий запрос MetricsQL возвращает цели со сбором ответа, превышающим 10MiB: scrape_response_size_bytes > 10MiB.

• scrape_samples_scraped — количество выборок, проанализированных при каждом сборе метрик. Это позволяет обнаруживать цели, которые предоставляют слишком много рядов. Например, следующий запрос MetricsQL возвращает цели, которые предоставляют более 10000 метрик: scrape_samples_scraped > 10000.

• scrape_samples_limit — настроенный лимит на количество выборок, которые может предоставить данная цель. Лимит можно установить с помощью опции sample_limit в scrape_configs. Эта метрика предоставляется только в том случае, если установлен sample_limit. Это позволяет обнаруживать цели, которые предоставляют слишком много метрик по сравнению с настроенным sample_limit. Например, следующий запрос возвращает цели (идентифицируемые по метке instance), которые предоставляют более 80% метрик по сравнению с настроенным sample_limit: scrape_samples_scraped / scrape_samples_limit > 0.8.

• scrape_samples_post_metric_relabeling — количество выборок, оставшихся после применения relabeling на уровне метрик из раздела metric_relabel_configs. Это позволяет обнаруживать цели с слишком большим количеством рядов после relabeling. Например, следующий запрос MetricsQL возвращает цели с более чем 10000 метриками после relabeling: scrape_samples_post_metric_relabeling > 10000.

• scrape_labels_limit — настроенный лимит на количество меток, которые данная цель может предоставлять на выборку. Лимит можно установить с помощью опции label_limit в scrape_configs. Эта метрика предоставляется только в том случае, если установлен label_limit.

• scrape_series_added — приблизительное количество новых рядов, которые данная цель генерирует во время текущего сбора метрик. Эта метрика позволяет обнаруживать цели (идентифицируемые по метке instance), которые приводят к высокой скорости изменения метрик. Например, следующий запрос MetricsQL возвращает цели, которые генерируют более 1000 новых рядов за последний час: sum_over_time(scrape_series_added[1h]) > 1000 vmagent устанавливает scrape_series_added в ноль, когда он запускается с флагом -promscrape.noStaleMarkers или когда он собирает метрики с цели с опцией no_stale_markers: true, например, когда маркеры устаревания отключены.

• scrape_series_limit — лимит на количество уникальных рядов, которые может предоставить данная цель. Эта метрика предоставляется только в том случае, если установлен лимит на ряды.

• scrape_series_current — количество уникальных рядов, которые данная цель предоставила на данный момент. Эта метрика предоставляется только в том случае, если установлен лимит на ряды. Эта метрика позволяет создавать оповещения, когда количество предоставленных данной целью рядов достигает лимита. Например, следующий запрос будет генерировать оповещение, когда цель предоставляет более 90% уникальных рядов по сравнению с настроенным лимитом: scrape_series_current / scrape_series_limit > 0.9.

• scrape_series_limit_samples_dropped — показывает количество отброшенных выборок во время сбора метрик из-за превышения лимита на количество уникальных рядов. Эта метрика предоставляется только в том случае, если установлен лимит на ряды. Эта метрика позволяет создавать оповещения, когда собранные выборки отбрасываются из-за превышения лимита. Например, следующий запрос генерирует оповещение, когда хотя бы одна выборка отбрасывается из-за превышения лимита за последний час: sum_over_time(scrape_series_limit_samples_dropped[1h]) > 0.

Если цель экспортирует метрики с именами, совпадающими с именами автоматически генерируемых метрик, то vmagent автоматически добавляет префикс exported_ к этим именам метрик, чтобы они не конфликтовали с автоматически генерируемыми именами метрик. Relabeling, определенный в relabel_configs или metric_relabel_configs конфигурации сбора метрик, не применяется к автоматически генерируемым метрикам. Но их все еще можно переименовать с помощью -remoteWrite.relabelConfig перед отправкой метрик на удаленный адрес.

Маркеры устаревания Prometheus#

vmagent отправляет маркеры устаревания Prometheus в -remoteWrite.url в следующих случаях:

• Если они передаются vmagent через протокол Prometheus remote_write.

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

• Если цель сбора метрик становится временно недоступной, то для всех метрик, собранных с этой цели, отправляются маркеры устаревания.

• Если цель сбора метрик удаляется из списка целей, то для всех метрик, собранных с этой цели, отправляются маркеры устаревания.

Отслеживание маркеров устаревания Prometheus требует дополнительной памяти, поскольку необходимо хранить тело предыдущего ответа для каждой цели сбора метрик, чтобы сравнить его с текущим телом ответа. Использование памяти можно уменьшить, отключив отслеживание устаревания следующими способами:

• Передав флаг -promscrape.noStaleMarkers vmagent. Это отключает отслеживание устаревания для всех целей.

• Указав опцию no_stale_markers: true в конфигурации сбора метрик для соответствующей цели.

Когда отслеживание устаревания отключено, vmagent не отслеживает количество новых временных рядов для каждого сбора метрик, например, он устанавливает метрику scrape_series_added в ноль. Подробнее см. раздел «Автоматически генерируемые метрики».

Метаданные метрик#

По умолчанию vmagent игнорирует метаданные метрик, предоставляемые целями сбора метрик в формате экспозиции Prometheus, полученные через Prometheus remote_write v1 или протокол OpenTelemetry. Установите -enableMetadata=true для включения обработки метаданных (доступно с версии v1.124.0). Во время обработки метаданные не будут удалены или изменены relabeling или потоковой агрегацией. Когда включен -enableMultitenantHandlers, vmagent добавляет информацию об арендаторе к метаданным, полученным через Multitenancy endpoint vm_account_id или vm_project_id метки добавляются непосредственно к метрикам до того, как они достигнут vmagent, и vmagent записывает в Multitenancy endpoint vminsert, информация об арендаторе не будет прикреплена, и метаданные будут храниться под арендатором по умолчанию в кластере Victoriametrics. Включение метаданных требует дополнительной памяти, дискового пространства и сетевого трафика.

Режим потокового парсинга#

По умолчанию vmagent анализирует полный ответ от цели сбора метрик, применяет relabeling и затем отправляет полученные метрики в настроенный -remoteWrite.url за один раз. Этот режим хорошо работает для большинства случаев, когда цель сбора метрик предоставляет небольшое количество метрик (например, менее 10 тыс.). Но этот режим может потреблять большой объем памяти, когда цель сбора метрик предоставляет большое количество метрик (например, когда vmagent собирает метрики с kube-state-metrics в большом кластере Kubernetes). Для таких целей рекомендуется включить режим потокового парсинга. Когда этот режим включен, vmagent обрабатывает ответ от цели сбора метрик частями. Это позволяет экономить память при сборе метрик с целей, которые предоставляют миллионы метрик. Режим потокового парсинга автоматически включается для целей сбора метрик, возвращающих тела ответов размером больше значения флага -promscrape.minResponseSizeForStreamParse. Кроме того, режим потокового парсинга можно явно включить в следующих местах:

• С помощью флага -promscrape.streamParse. В этом случае все цели сбора метрик, определенные в файле, указанном в -promscrape.config, собираются в режиме потокового парсинга.

• С помощью опции stream_parse: true в разделе scrape_configs. В этом случае все цели сбора метрик, определенные в этом разделе, собираются в режиме потокового парсинга.

• С помощью метки __stream_parse__=true, которую можно установить через relabeling в разделе relabel_configs. В этом случае режим потокового парсинга включается для соответствующих целей сбора метрик. Типичный вариант использования: установка метки через аннотации Kubernetes для целей, предоставляющих большое количество метрик.

Примеры:

scrape_configs:
- job_name: 'big-federate'
  stream_parse: true
  static_configs:
  - targets:
    - big-prometheus1
    - big-prometheus2
  honor_labels: true
  metrics_path: /federate
  params:
    'match[]': ['{__name__!=""}']

Обратите внимание, что vmagent в режиме потокового парсинга сохраняет до sample_limit выборок в настроенное -remoteStorage.url, вместо того чтобы отбрасывать все выборки, считанные с цели, потому что проанализированные данные отправляются в удаленное хранилище сразу же, как только они анализируются в режиме потокового парсинга.

Сбор метрик с большого количества целей#

Один экземпляр vmagent может собирать метрики с десятков тысяч целей сбора метрик. Иногда этого недостаточно из-за ограничений на процессор, сеть, оперативную память и т. д. В этом случае цели сбора метрик можно распределить между несколькими экземплярами vmagent (также известными как горизонтальное масштабирование, шардирование и кластеризация vmagent). Количество экземпляров vmagent в кластере должно быть передано флагу -promscrape.cluster.membersCount. Каждый экземпляр vmagent в кластере должен использовать идентичные файлы -promscrape.config со значениями -promscrape.cluster.memberNum, отличными в диапазоне 0 ... N-1, где N — количество экземпляров vmagent в кластере, указанное через -promscrape.cluster.membersCount. Например, следующие команды распределяют цели сбора метрик между кластером из двух экземпляров vmagent:

/path/to/vmagent -promscrape.cluster.membersCount=2 -promscrape.cluster.memberNum=0 -promscrape.config=/path/to/config.yml ...
/path/to/vmagent -promscrape.cluster.membersCount=2 -promscrape.cluster.memberNum=1 -promscrape.config=/path/to/config.yml ...

Флаг -promscrape.cluster.memberNum можно установить в имя pod StatefulSet, когда vmagent работает в Kubernetes. Имя pod должно заканчиваться числом в диапазоне 0 ... promscrape.cluster.membersCount-1. Например, -promscrape.cluster.memberNum=vmagent-0. По умолчанию каждая цель сбора метрик собирается только одним экземпляром vmagent в кластере. Если необходимо реплицировать цели сбора метрик между несколькими экземплярами vmagent, то флаг -promscrape.cluster.replicationFactor должен быть установлен в желаемое количество реплик. Например, следующие команды запускают кластер из трех экземпляров vmagent, где каждая цель собирается двумя экземплярами vmagent:

/path/to/vmagent -promscrape.cluster.membersCount=3 -promscrape.cluster.replicationFactor=2 -promscrape.cluster.memberNum=0 -promscrape.config=/path/to/config.yml ...
/path/to/vmagent -promscrape.cluster.membersCount=3 -promscrape.cluster.replicationFactor=2 -promscrape.cluster.memberNum=1 -promscrape.config=/path/to/config.yml ...
/path/to/vmagent -promscrape.cluster.membersCount=3 -promscrape.cluster.replicationFactor=2 -promscrape.cluster.memberNum=2 -promscrape.config=/path/to/config.yml ...

Каждый vmagent в кластере показывает все обнаруженные цели на странице http://vmagent:8429/service-discovery. Каждая обнаруженная цель на этой странице содержит свой статус (UP, DOWN или DROPPED с причиной, по которой цель была отброшена). Если цель отброшена из-за шардирования на другие экземпляры vmagent в кластере, то столбец статуса содержит значения -promscrape.cluster.memberNum для экземпляров vmagent, где собирается данная цель. Страница /service-discovery предоставляет ссылки на соответствующие экземпляры vmagent, если установлен флаг -promscrape.cluster.memberURLTemplate. Каждое вхождение %d внутри -promscrape.cluster.memberURLTemplate заменяется на -promscrape.cluster.memberNum для соответствующего экземпляра vmagent. Например, -promscrape.cluster.memberURLTemplate='http://vmagent-instance-%d:8429/targets' генерирует URL-адрес http://vmagent-instance-42:8429/targets для экземпляра vmagent, который запускается с -promscrape.cluster.memberNum=42. Обратите внимание, что vmagent показывает до -promscrape.maxDroppedTargets отброшенных целей на странице /service-discovery. Увеличьте значение флага -promscrape.maxDroppedTargets, если на странице /service-discovery отсутствуют некоторые отброшенные цели. Если каждая цель собирается несколькими экземплярами vmagent, то на стороне удаленного хранилища, указанного в -remoteWrite.url, должна быть включена дедупликация данных. -dedup.minScrapeInterval должен быть установлен в scrape_interval, настроенный в -promscrape.config. Подробнее см. раздел «Сбор метрик с большого количества целей». Флаг -promscrape.cluster.memberLabel позволяет указать имя для метки member num, которая будет добавлена ко всем собираемым метрикам. Значение метки member num устанавливается в -promscrape.cluster.memberNum. Например, следующая конфигурация указывает добавлять метку vmagent_instance="0" ко всем метрикам, собираемым данным экземпляром vmagent:

/path/to/vmagent -promscrape.cluster.membersCount=2 -promscrape.cluster.memberNum=0 -promscrape.cluster.memberLabel=vmagent_instance

См. также как шардировать данные между несколькими системами удаленного хранения в разделе «Шардирование между удаленными хранилищами».

Высокая доступность#

Можно запустить несколько идентично настроенных экземпляров vmagent или идентично настроенных кластеров (подробнее см. в разделе «Сбор метрик с большого количества целей») vmagent, чтобы они собирали один и тот же набор целей и отправляли собранные данные в один и тот же набор систем удаленного хранения Victoriametrics. Две идентично настроенные пары vmagent или кластера обычно называются HA-парой. При запуске HA-пар дедупликация должна быть настроена на стороне Victoriametrics, чтобы устранить дубликаты полученных выборок. Также рекомендуется передавать разные значения флагу -promscrape.cluster.name для каждого экземпляра vmagent или для каждого кластера vmagent в HA-настройке. Это необходимо для правильной дедупликации данных.

Сбор метрик с целей через прокси#

vmagent поддерживает сбор метрик с целей через прокси http, https и socks5. Адрес прокси должен быть указан в опции proxy_url. Например, следующая конфигурация сбора метрик указывает на сбор метрик с цели через https-прокси по адресу https://proxy-addr:1234:

scrape_configs:
- job_name: foo
  proxy_url: https://proxy-addr:1234

Прокси можно настроить со следующими дополнительными параметрами:

• proxy_authorization для общей авторизации по токену.

• proxy_basic_auth для базовой авторизации.

• proxy_bearer_token и proxy_bearer_token_file для авторизации по токену Bearer.

• proxy_oauth2 для конфигурации OAuth2.

• proxy_tls_config для конфигурации TLS.

• proxy_headers для передачи дополнительных HTTP-заголовков в запросах к прокси.

Например:

scrape_configs:
- job_name: foo
  proxy_url: https://proxy-addr:1234
  proxy_basic_auth:
    username: foobar
    password: secret
  proxy_tls_config:
    insecure_skip_verify: true
    cert_file: /path/to/cert
    key_file: /path/to/key
    ca_file: /path/to/ca
    server_name: real-server-name
  proxy_headers:
  - "Proxy-Auth: top-secret"

Сохранение на диске#

vmagent сохраняет ожидающие данные, которые не могут быть своевременно отправлены в настроенные системы удаленного хранения. По умолчанию vmagent записывает все ожидающие данные в папку, настроенную через флаг -remoteWrite.tmpDataPath, пока эти данные не будут отправлены в настроенные системы -remoteWrite.url или пока папка не заполнится. Максимальный размер данных, который можно сохранить в -remoteWrite.tmpDataPath для каждого настроенного -remoteWrite.url, можно ограничить с помощью флага -remoteWrite.maxDiskUsagePerURL. Когда этот лимит достигнут, vmagent удаляет самые старые данные с диска, чтобы сохранить вновь полученные данные. Структура папки сохраняемых данных выглядит следующим образом:

<remoteWrite.tmpDataPath>
└── persistent-queue
    └── 1_B9EB7BE220B91E9D

Каждый URL remote_write соответствует папке, похожей на 1_B9EB7BE220B91E9D. Она генерируется на основе следующей информации:

• Порядковый номер URL remote_write в флагах, начиная с 1.

• Результат хеширования самого URL remote_write, исключая параметры запроса и фрагменты.

Например, для конфигураций remote_write:

-remoteWrite.url=http://example-1:8428/prometheus/api/v1/write?foo=bar#baz
-remoteWrite.url=http://user:pass@example-2:8428/prometheus/api/v1/write?qux=quux#quuz

vmagent сгенерирует следующие папки постоянной очереди:

# 1_<hash(http://example-1:8428/prometheus/api/v1/write)>, параметры запроса foo=bar и фрагмент baz удалены.
1_BA6E4303DCFA0D45
# 2_<hash(http://user:pass@example-2:8428/prometheus/api/v1/write)>, параметры запроса qux=quux и фрагмент quuz удалены.
2_0AAFDF53E314A72A

Отключение сохранения на диске#

Существуют случаи, когда лучше отключить сохранение ожидающих данных на стороне vmagent:

• Когда производительность постоянного диска недостаточна для заданной скорости обработки данных.

• Когда лучше буферизовать ожидающие данные на стороне клиента, а не буферизовать их на стороне vmagent в папке -remoteWrite.tmpDataPath.

• Когда лучше отбрасывать ожидающие данные, а не буферизовать их.

В этом случае флаг -remoteWrite.disableOnDiskQueue можно передать vmagent для каждого настроенного -remoteWrite.url. vmagent работает следующим образом, если соответствующая система удаленного хранения в -remoteWrite.url не может справиться с скоростью приема данных, и установлен флаг -remoteWrite.disableOnDiskQueue, то:

• возвращается HTTP-ошибка 429 Too Many Requests клиентам, которые отправляют данные в vmagent через поддерживаемые HTTP endpoint. Если установлен флаг -remoteWrite.dropSamplesOnOverload или если установлено несколько флагов -remoteWrite.url, то полученные выборки отбрасываются вместо того, чтобы возвращать ошибку клиентам.

• отбрасываются выборки, отправленные в vmagent через не-HTTP протоколы, и записывает ошибку в журнал. Передайте флаг -remoteWrite.dropSamplesOnOverload, чтобы подавить сообщения об ошибках в этом случае.

• отбрасываются выборки, собранные с целей, совместимых с Prometheus, потому что с точки зрения эксплуатации лучше отбрасывать выборки, чем блокировать процесс сбора метрик.

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

Количество отброшенных выборок из-за перегруженного удаленного хранилища можно отслеживать с помощью метрики vmagent_remotewrite_samples_dropped_total.

Количество неудачных попыток отправки данных в перегруженное удаленное хранилище можно отслеживать с помощью метрики vmagent_remotewrite_push_failures_total.

Запуск vmagent на хостах с большим объемом оперативной памяти или увеличение значения -memory.allowedPercent может уменьшить количество неудачных попыток или отброшенных выборок при пиковых нагрузках, поскольку vmagent может буферизовать больше данных в памяти перед возвратом ошибки или отбрасыванием данных. vmagent все еще может записывать ожидающие данные, находящиеся в памяти, в -remoteWrite.tmpDataPath при корректном завершении работы, если установлен флаг -remoteWrite.disableOnDiskQueue. Он также может читать буферизованные данные из -remoteWrite.tmpDataPath при запуске. Когда установлен флаг -remoteWrite.disableOnDiskQueue, vmagent может отправлять одни и те же выборки несколько раз в настроенное удаленное хранилище, если он не может справиться со скоростью приема данных. В этом случае дедупликация (подробнее см. в разделе «Репликация и высокая доступность») должна быть включена на всех настроенных системах удаленного хранения.

Ограничитель кардинальности#

По умолчанию vmagent не ограничивает количество временных рядов, которые может предоставить каждая цель сбора метрик. Ограничение можно применить в следующих местах:

• С помощью флага -promscrape.seriesLimitPerTarget. Это ограничение применяется индивидуально ко всем целям сбора метрик, определенным в файле, указанном в -promscrape.config.

• С помощью опции конфигурации series_limit в разделе scrape_config series_limit позволяет переопределить -promscrape.seriesLimitPerTarget для каждого scrape_config. Если series_limit установлен в 0 или отрицательное значение, то он не применяется к данному scrape_config, даже если установлен флаг -promscrape.seriesLimitPerTarget.

• С помощью метки __series_limit__, которую можно установить с помощью relabeling в разделе relabel_configs. __series_limit__ позволяет переопределить series_limit для каждой цели. Если __series_limit__ установлен в 0 или отрицательное значение, то он не применяется к данной цели. Типичный вариант использования: установка лимита через аннотации Kubernetes для целей, которые могут предоставлять слишком большое количество временных рядов.

Собранные метрики отбрасываются для временных рядов, превышающих заданный лимит, в течение 24-часового временного окна. vmagent создает следующие дополнительные метрики для каждой цели с ненулевым лимитом на ряды:

• scrape_series_limit_samples_dropped — количество отброшенных выборок во время сбора метрик, когда превышен лимит уникальных рядов.

• scrape_series_limit — лимит на ряды для данной цели.

• scrape_series_current — текущее количество рядов для данной цели.

Эти метрики автоматически отправляются в настроенное -remoteWrite.url вместе со всеми собранными метриками для каждой цели. Они позволяют создавать следующие правила оповещения:

• scrape_series_current / scrape_series_limit > 0.9 — генерирует оповещение, когда количество рядов, предоставляемых целью, достигает 90% от лимита.

• sum_over_time(scrape_series_limit_samples_dropped[1h]) > 0 — генерирует оповещение, когда некоторые выборки отбрасываются, потому что на конкретной цели достигнут лимит на ряды.

По умолчанию vmagent не ограничивает количество временных рядов, записываемых в системы удаленного хранения, указанные в -remoteWrite.url. Ограничение можно применить, установив следующие флаги:

• -remoteWrite.maxHourlySeries — ограничивает количество уникальных временных рядов, которые vmagent может записать в системы удаленного хранения за последний час. Полезно для ограничения количества активных временных рядов.

• -remoteWrite.maxDailySeries — ограничивает количество уникальных временных рядов, которые vmagent может записать в системы удаленного хранения за последний день. Полезно для ограничения ежедневной скорости изменения метрик.

Оба лимита можно установить одновременно. Если любой из этих лимитов достигнут, то выборки для новых временных рядов отбрасываются вместо отправки их в системы удаленного хранения. Образец отброшенных рядов помещается в журнал с уровнем WARNING. vmagent предоставляет следующие метрики на странице http://vmagent:8429/metrics (подробнее см. раздел «Мониторинг» для получения подробной информации):

• vmagent_hourly_series_limit_rows_dropped_total — количество метрик, отброшенных из-за превышения часового лимита на количество уникальных временных рядов.

• vmagent_hourly_series_limit_max_series — часовой лимит на ряды, установленный через -remoteWrite.maxHourlySeries.

• vmagent_hourly_series_limit_current_series — текущее количество уникальных рядов, зарегистрированных за последний час.

• vmagent_daily_series_limit_rows_dropped_total — количество метрик, отброшенных из-за превышения дневного лимита на количество уникальных временных рядов.

• vmagent_daily_series_limit_max_series — дневной лимит на ряды, установленный через -remoteWrite.maxDailySeries.

• vmagent_daily_series_limit_current_series — текущее количество уникальных рядов, зарегистрированных за последний день.

Эти лимиты являются приблизительными, поэтому vmagent может немного превысить или не достичь лимита (обычно менее 1%).

Мониторинг#

vmagent экспортирует различные метрики в формате экспозиции Prometheus на странице http://vmagent-host:8429/metrics. Рекомендуется настроить регулярный сбор метрик с этой страницы либо через сам vmagent, либо с помощью scraper, совместимого с Prometheus, чтобы впоследствии можно было анализировать экспортируемые метрики.

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

vmagent также экспортирует статус для различных целей на следующих страницах:

• http://vmagent-host:8429/targets- страница показывает текущий статус для каждой активной цели.

• http://vmagent-host:8429/service-discovery - страница показывает список обнаруженных целей с обнаруженными метками __meta_*.

• http://vmagent-host:8429/api/v1/targets- обработчик возвращает JSON-ответ, совместимый с соответствующей страницей из API Prometheus.

• http://vmagent-host:8429/ready - обработчик возвращает HTTP-код состояния 200, когда vmagent завершает свою инициализацию для всех конфигураций service_discovery.

Устранение неполадок#

• Рекомендуется увеличить максимальное количество открытых файлов в системе (ulimit -n) при сборе большого количества целей, поскольку vmagent устанавливает по крайней мере одно TCP-соединение с каждой целью.

• Если vmagent использует слишком много оперативной памяти или процессора, следуйте рекомендациям из раздела «Оптимизация производительности».

• Когда vmagent собирает метрики со многих ненадежных целей, он может заполнить журнал ошибок ошибками сбора метрик. Рекомендуется исследовать и исправлять эти ошибки. Если исправить все сообщенные ошибки невозможно, их можно подавить, передав флаг -promscrape.suppressScrapeErrors vmagent. Последнюю ошибку сбора метрик для каждой цели можно наблюдать на страницах http://vmagent-host:8429/targets и http://vmagent-host:8429/api/v1/targets.

• Страница http://vmagent-host:8429/service-discovery может быть полезна для отладки процесса relabeling целей сбора метрик. Эта страница содержит исходные метки для целей, отброшенных во время relabeling. По умолчанию здесь показываются до -promscrape.maxDroppedTargets целей. Если во время relabeling отбрасывается больше целей, увеличьте значение флага -promscrape.maxDroppedTargets, чтобы увидеть все отброшенные цели. Обратите внимание, что отслеживание каждой отброшенной цели требует до 10 Кб оперативной памяти. Поэтому большие значения для -promscrape.maxDroppedTargets могут привести к увеличению использования оперативной памяти, если во время relabeling отбрасывается большое количество целей сбора метрик.

• Рекомендуется увеличить -remoteWrite.queues, если метрика vmagent_remotewrite_pending_data_bytes постоянно растет. Также рекомендуется увеличить флаги -remoteWrite.maxBlockSize и -remoteWrite.maxRowsPerBlock в этом случае. Это может улучшить производительность приема данных в настроенные системы удаленного хранения за счет более высокого использования оперативной памяти.

• Если выявлены пробелы в данных, отправленных vmagent в удаленное хранилище, когда установлен -remoteWrite.maxDiskUsagePerURL, попробуйте увеличить -remoteWrite.queues. Такие пробелы могут появляться, потому что vmagent не может справиться с отправкой собранных данных в удаленное хранилище. Поэтому он начинает отбрасывать буферизованные данные, если размер буфера на диске превышает -remoteWrite.maxDiskUsagePerURL.

• vmagent отбрасывает блоки данных, если удаленное хранилище отвечает HTTP-ответами 400 Bad Request и 409 Conflict. Количество отброшенных блоков можно отслеживать с помощью метрики vmagent_remotewrite_packets_dropped_total, экспортируемой на странице /metrics (подробнее см. раздел «Мониторинг»).

• Используйте -remoteWrite.queues=1, когда -remoteWrite.url указывает на удаленное хранилище, которое не принимает выборки в произвольном порядке (также известные как дозапись данных). Такие системы хранения включают Prometheus, Mimir, Cortex и Thanos, которые обычно выдают ошибки out of order sample. Лучшее решение — использовать удаленное хранилище с поддержкой дозаписи, такое как Victoriametrics.

• vmagent буферизует собранные данные в каталоге -remoteWrite.tmpDataPath до тех пор, пока они не будут отправлены в -remoteWrite.url. Каталог может сильно вырасти, когда удаленное хранилище недоступно в течение длительного времени, и если максимальный размер каталога не ограничен с помощью флага -remoteWrite.maxDiskUsagePerURL. Если нет необходимости отправлять все буферизованные данные из каталога в удаленное хранилище, просто остановите vmagent и удалите каталог.

• Если vmagent работает на хосте с медленным постоянным хранилищем, которое не может справиться с объемом обрабатываемых выборок, можно отключить такое хранилище с помощью флага -remoteWrite.disableOnDiskQueue. Подробнее см. раздел «Отключение сохранения на диске».

• По умолчанию vmagent маскирует -remoteWrite.url значениями secret-url в журналах и на странице /metrics, потому что URL может содержать конфиденциальную информацию, такую как токены аутентификации или пароли. Передайте флаг -remoteWrite.showURL при запуске vmagent, чтобы увидеть все действительные URL.

• По умолчанию vmagent равномерно распределяет нагрузку сбора метрик во времени. Если конкретную цель сбора метрик необходимо собирать в начале некоторого интервала, то необходимо использовать опцию scrape_align_interval. Например, следующая конфигурация выравнивает сбор метрик по часам к началу часа: scrape_configs: - job_name: foo scrape_interval: 1h scrape_align_interval: 1h.

• По умолчанию vmagent равномерно распределяет нагрузку сбора метрик во времени. Если конкретную цель сбора метрик необходимо собирать в определенное смещение, то необходимо использовать опцию scrape_offset. Например, следующая конфигурация указывает vmagent собирать метрики с цели на 10-й секунде каждой минуты: scrape_configs: - job_name: foo scrape_interval: 1m scrape_offset: 10s.

• Ошибки skipping duplicate scrape target with identical labels при сборе метрик с подов Kubernetes могут свидетельствовать о том, что, скорее всего, эти поды прослушивают несколько портов или используют init-контейнер. Эти ошибки можно либо исправить, либо подавить с помощью флага командной строки -promscrape.suppressDuplicateScrapeTargetErrors. Варианты исправления корневой причины ошибки:

  • Следующее правило relabeling можно добавить в раздел relabel_configs, чтобы отфильтровать pod с ненужными портами:

    - action: keep_if_equal source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port, __meta_kubernetes_pod_container_port_number]
    

  • Следующее правило relabeling можно добавить в раздел relabel_configs, чтобы отфильтровать pod init-контейнера:

    - action: drop source_labels: [__meta_kubernetes_pod_container_init] regex: true`
    

Расчет дискового пространства для очереди сохранения#

vmagent буферизует собранные метрики на диске в каталоге, указанном через флаг -remoteWrite.tmpDataPath, до тех пор, пока метрики не будут отправлены в удаленное хранилище, настроенное через флаг -remoteWrite.url.

Каталог -remoteWrite.tmpDataPath может сильно вырасти, когда удаленное хранилище недоступно в течение длительного времени, и если максимальный размер каталога не ограничен с помощью флага -remoteWrite.maxDiskUsagePerURL.

Чтобы оценить выделенный размер диска для постоянной очереди или оценить значение флага -remoteWrite.maxDiskUsagePerURL, обратите внимание на следующие атрибуты:

• Размер в байтах потока данных, отправляемого vmagent:

  Выполните запрос sum(rate(vmagent_remotewrite_bytes_sent_total[1h])) by(instance,url) в VMUI или Grafana, чтобы получить количество байт, отправляемых каждым экземпляром vmagent в секунду.

• Время, в течение которого постоянная очередь должна хранить данные, прежде чем начать их отбрасывать:

  Например, если vmagent должен иметь возможность буферизовать данные как минимум в течение 6 часов, то для оценки необходимого объема дискового пространства в гигабайтах можно использовать следующий запрос: sum(rate(vmagent_remotewrite_bytes_sent_total[1h])) by(instance,url) * 6h / 1Gi.

Дополнительные примечания:

• Убедитесь, что мониторинг vmagent настроен правильно. Подробнее см. раздел «Мониторинг».

• Пересматривайте оценку каждый раз, когда:

  • увеличивается рабочая нагрузка vmagent;

  • изменяются правила relabeling, которые могут увеличить количество метрик для отправки;

  • изменяется количество настроенных адресов -remoteWrite.url.

• Минимальный размер диска, который необходимо выделить для постоянной очереди, составляет 500 МиБ для каждого -remoteWrite.url.

• Постоянную очередь на диске можно отключить, если это необходимо. Подробнее см. раздел «Отключение сохранения на диске».

Безопасность#

Защита mTLS#

По умолчанию vmagent принимает HTTP-запросы на порту 8429 (этот порт можно изменить с помощью флагов -httpListenAddr), поскольку ожидается, что он работает в изолированной доверенной сети. Корпоративная версия vmagent поддерживает возможность принимать запросы mTLS на этом порту, указав флаги -tls и -mtls.

Например, следующая команда запускает vmagent, который принимает только запросы mTLS на порту 8429:

./vmagent -tls -mtls -remoteWrite.url=...

По умолчанию для проверки клиентских сертификатов, если установлен флаг -mtls, используется системный TLS Root CA. Можно указать пользовательский TLS Root CA через флаг -mtlsCAFile.

Оптимизация производительности#

vmagent оптимизирован для низкого использования процессора и оперативной памяти без необходимости настройки каких-либо конфигураций. Иногда необходимо еще больше оптимизировать использование процессора/оперативной памяти vmagent. Например, если vmagent необходимо собирать метрики с тысяч целей в средах с ограниченными ресурсами. Тогда следующие параметры могут помочь снизить использование процессора и оперативной памяти vmagent:

• Установите переменную окружения GOGC в 100. Это снижает использование процессора за счет более высокого использования оперативной памяти.

• Установите переменную окружения GOMAXPROCS в значение, немного превышающее количество ядер процессора, используемых vmagent. Другой вариант — установить лимит CPU в Kubernetes / Docker на целочисленное значение, превышающее количество ядер процессора, используемых vmagent. Это снижает использование оперативной памяти и процессора, когда vmagent работает в среде с большим количеством доступных ядер процессора. Обратите внимание, что может потребоваться увеличить флаг -remoteWrite.queues до больших значений, если GOMAXPROCS установлен на слишком маленькие значения, поскольку по умолчанию -remoteWrite.queues пропорционален GOMAXPROCS.

• Отключите сжатие ответов на целях сбора метрик с помощью флага -promscrape.disableCompression или с помощью опции disable_compression: true в scrape_config. Это снижает использование процессора за счет более высокого использования сетевой полосы пропускания между vmagent и целями сбора метрик.

• Отключите отслеживание исходных меток для обнаруженных целей с помощью флага -promscrape.dropOriginalLabels. Это помогает снизить использование оперативной памяти, когда vmagent обнаруживает большое количество целей сбора метрик, и большинство этих целей отбрасываются. Это типичный случай, когда vmagent обнаруживает цели Kubernetes. Недостатком использования флага -promscrape.dropOriginalLabels является снижение возможности отладки неправильно настроенных relabeling для каждой цели.

• Отключите маркеры устаревания с помощью флага -promscrape.noStaleMarkers или с помощью опции no_stale_markers: true в scrape_config. Это снижает использование оперативной памяти и процессора. Обратите внимание, что отключение маркеров устаревания может привести к неожиданным результатам запросов, когда цели сбора метрик часто меняются (это типичный случай в Kubernetes).

• Установите флаг -memory.allowedBytes в значение, близкое к фактическому использованию памяти vmagent. Другой вариант — установить лимит памяти в Kubernetes / Docker на значение, на 50% превышающее фактическое использование памяти vmagent. Это должно снизить всплески использования памяти для vmagent, работающего в среде с большим объемом доступной памяти, когда удаленное хранилище не может справиться со скоростью приема данных. Увеличение значения флага -remoteWrite.queues также может помочь в этом случае.

• В крайних случаях может быть полезно установить флаг -promscrape.disableKeepAlive, чтобы сэкономить оперативную память на HTTP-соединениях с поддержкой keep-alive с тысячами целей сбора метрик.

• Увеличьте опцию scrape_interval в разделе global файла -promscrape.config и/или в каждом scrape_config, чтобы снизить использование процессора. Например, увеличение scrape_interval с 10s до 30s для всех целей снижает использование процессора vmagent до 3 раз.

Пример команды, которая запускает vmagent в оптимизированном режиме:

GOGC=100 GOMAXPROCS=1 ./vmagent -promscrape.disableCompression -promscrape.dropOriginalLabels -promscrape.noStaleMarkers -memory.allowedBytes=1GiB -promscrape.disableKeepAlive ...