VictoriaMetrics/app/vmagent/README.md

vmagent

vmagent collects metrics from various sources and pushes them to any remote storage for Prometheus from this list. The recommended remote storage is VictoriaMetrics.

Features

• Can be used as drop-in replacement for Prometheus for scraping targets such as node_exporter. Just use -promscrape.config=/path/to/prometheus.yml command-line flag.
• Accepts data via all the ingestion protocols supported by VictoriaMetrics:
  • Influx line protocol via http://<vmagent>:8429/write. See these docs.
  • JSON lines import protocol via http://<vmagent>:8429/api/v1/import. See these docs.
  • Graphite plaintext protocol if -graphiteListenAddr command-line flag is set. See these docs.
  • OpenTSDB telnet and http protocols if -opentsdbListenAddr command-line flag is set. See these docs.
  • Prometheus remote write protocol via http://<vmagent>:8429/api/v1/write.
• Prometheus relabeling can be applied to all the collected metrics. See these docs.
• Additional labels can be added to all the collected metrics before sending them to remote storage. Just pass these labels to -remoteWrite.label command-line flags: -remoteWrite.label="labelName=labelValue".
• Collected metrics can be sent simultaneously to multiple remote storage systems by providing multiple -remoteWrite.url args.
• Works in environments with unstable connections to remote storage. If the remote storage is unavailable, the collected metrics are buffered at -remoteWrite.tmpDataPath until free space is available. The buffered metrics are sent to remote storage as soon as connection to remote storage is recovered.
• Uses lower amounts of RAM, CPU, disk IO and network bandwidth comparing to Prometheus.

Quick start

Just pass the following flags to vmagent in order to start scraping Prometheus targets:

• -promscrape.config with the path to Prometheus config file (it is usually located at /etc/prometheus/prometheus.yml)
• -remoteWrite.url with the remote storage endpoint such as VictoriaMetrics. Multiple -remoteWrite.url args can be set in parallel in order to replicate data concurrently to multiple remote storage systems.

Example command line:

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

If you need collecting only Influx data, then the following command line would be enough:

/path/to/vmagent -remoteWrite.url=https://victoria-metrics-host:8428/api/v1/write

Then send Influx data to http://vmagent-host:8429/write. See these docs for more details.

How to collect metrics in Prometheus format?

Pass the path to prometheus.yml to -promscrape.config command-line flag. vmagent takes into account the following sections from Prometheus config file:

• global
• scrape_configs

All the other section are ignored, including remote_write section. Use -remoteWrite.* command-line flags instead for configuring remote write settings:

• -remoteWrite.url for pointing to remote storage. Data to remote storage can be sent either via HTTP or HTTPS. See -remoteWrite.tls* flags for details.
• -remoteWrite.label for adding labels to metrics before sending them to remote storage.
• -remoteWrite.relabelConfig for applying relabeling to metrics before sending them to remote storage.

The following scrape types in scrape_config section are supported:

• static_configs - for scraping statically defined targets. See these docs for details.
• file_sd_configs - for scraping targets defined in external files aka file-based service discover. See these docs for details.

File feature requests at our issue tracker if you need other service discovery mechanisms to be supported by vmagent.

Adding labels to metrics

Labels can be added to metrics via the following mechanisms:

• Via global -> external_labels section in -promscrape.config file. These labels are added only to metrics scraped from targets configured in -promscrape.config file.
• Via -remoteWrite.label command-line flag. These labels are added to all the collected metrics before sending them to -remoteWrite.url.

Relabeling

vmagent supports Prometheus relabeling. Additionally it provides the following extra actions:

• replace_all: replaces all the occurences of regex in the values of source_labels with the replacement and stores the result in the target_label
• labelmap_all: replaces all the occurences of regex in all the label names with the replacement

The relabeling can be defined in the following places:

• At scrape_config -> relabel_configs section in -promscrape.config file. This relabeling is applied to targets when parsing the file during vmagent startup or during config reload after sending SIGHUP signal to vmagent via kill -HUP.
• At scrape_config -> metric_relabel_configs section in -promscrape.config file. This relabeling is applied to metrics after each scrape for the configured targets.
• At -remoteWrite.relabelConfig file. This relabeling is aplied to all the collected metrics before sending them to -remoteWrite.url.

Read more about relabeling in the following articles:

• Life of a label
• Discarding targets and timeseries with relabeling
• Dropping labels at scrape time
• Extracting labels from legacy metric names
• relabel_configs vs metric_relabel_configs

Monitoring

vmagent exports various metrics in Prometheus exposition format at /metrics page. It is recommended setting up regular scraping of this page either via vmagent itself or via Prometheus, so the exported metrics could be analyzed later.

Troubleshooting

• It is recommended increasing the maximum number of open files in the system (ulimit -n) when scraping big number of targets, since vmagent establishes at least a single TCP connection per each target.

• It is recommended increasing -remoteWrite.queues if vmagent collects more than 100K samples per second and vmagent_remotewrite_pending_data_bytes metric exported by vmagent at /metrics page constantly grows.

• vmagent buffers scraped data at -remoteWrite.tmpDataPath directory until it is sent to -remoteWrite.url. The directory can grow big when remote storage is unvailable during extended periods of time. If you don't want sending all the data from the directory to remote storage, just stop vmagent and delete the directory.

How to build from sources

It is recommended using binary releases - vmagent is located in vmutils-* archives there.

Development build

1. Install Go. The minimum supported version is Go 1.12.
2. Run make vmagent from the root folder of the repository. It builds vmagent binary and puts it into the bin folder.

Production build

1. Install docker.
2. Run make vmagent-prod from the root folder of the repository. It builds vmagent-prod binary and puts it into the bin folder.

Building docker images

Run make package-vmagent. It builds victoriametrics/vmagent:<PKG_TAG> docker image locally. <PKG_TAG> is auto-generated image tag, which depends on source code in the repository. The <PKG_TAG> may be manually set via PKG_TAG=foobar make package-vmagent.