+ 
+
+
## Multitenancy
diff --git a/docs/FAQ.md b/docs/FAQ.md
index 89482f509..e8f91c2c8 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -10,9 +10,6 @@ aliases:
- /FAQ.html
- /faq.html
---
-
-# FAQ
-
## What is the main purpose of VictoriaMetrics?
To provide the best monitoring solution.
diff --git a/docs/LTS-releases.md b/docs/LTS-releases.md
index bbe9ac274..ac71ea6a1 100644
--- a/docs/LTS-releases.md
+++ b/docs/LTS-releases.md
@@ -9,9 +9,6 @@ menu:
aliases:
- /LTS-releases.html
---
-
-# Long-term support releases
-
[Enterprise version of VictoriaMetrics](https://docs.victoriametrics.com/enterprise/) provides long-term support lines of releases (aka LTS releases).
Every LTS line receives bugfixes and [security fixes](https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/SECURITY.md) for 12 months after
the initial release. New LTS lines are published every 6 months, so the latest two LTS lines are supported at any given moment. This gives up to 6 months
diff --git a/docs/Makefile b/docs/Makefile
index 00d51c6e2..577974ebd 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -1,3 +1,7 @@
+ROOTDIR := $(dir $(realpath $(lastword $(MAKEFILE_LIST))))
+REPODIR := $(ROOTDIR)/..
+WORKDIR := $(REPODIR)/..
+
# These commands must be run from the VictoriaMetrics repository root
# Converts images at docs folder to webp format
@@ -14,3 +18,21 @@ docs-images-to-webp-by-extension:
sh -c 'find /docs/ -type f ! -path "/docs/operator/*" ! -path "/docs/_site/*" -name "*.$(IMAGES_EXTENSION)" -print0 | \
xargs -0 -P $(MAKE_CONCURRENCY) -I {} sh -c '"'"'cwebp -preset drawing -m 6 -o "$${1%.*}.webp" $$1'"'"' _ {}'
find docs/ -type f ! -path 'docs/operator/*' ! -path 'docs/_site/*' -name '*.$(IMAGES_EXTENSION)' -print0 | xargs -0 rm -f
+
+docs-debug:
+ if [ ! -d $(WORKDIR)/vmdocs ]; then \
+ git clone git@github.com:VictoriaMetrics/vmdocs $(WORKDIR)/vmdocs; \
+ fi; \
+ cd $(WORKDIR)/vmdocs && \
+ git checkout main && \
+ git pull origin main && \
+ cd $(REPODIR) && \
+ docker build \
+ -t vmdocs \
+ $(WORKDIR)/vmdocs && \
+ docker rm -f vmdocs || true && \
+ docker run \
+ -d \
+ --name vmdocs \
+ -p 1313:1313 \
+ -v ./docs:/opt/docs/content vmdocs
diff --git a/docs/MetricsQL.md b/docs/MetricsQL.md
index ba795cefe..64b343f53 100644
--- a/docs/MetricsQL.md
+++ b/docs/MetricsQL.md
@@ -10,9 +10,6 @@ aliases:
- /ExtendedPromQL.html
- /MetricsQL.html
---
-
-# MetricsQL
-
[VictoriaMetrics](https://github.com/VictoriaMetrics/VictoriaMetrics) implements MetricsQL -
query language inspired by [PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/).
MetricsQL is backwards-compatible with PromQL, so Grafana dashboards backed by Prometheus datasource should work
diff --git a/docs/PerTenantStatistic.md b/docs/PerTenantStatistic.md
index b5d169ef4..95628c824 100644
--- a/docs/PerTenantStatistic.md
+++ b/docs/PerTenantStatistic.md
@@ -9,10 +9,7 @@ menu:
aliases:
- /PerTenantStatistic.html
---
-
-# VictoriaMetrics Cluster Per Tenant Statistic
-
-
+
***The per-tenant statistic is a part of [enterprise package](https://docs.victoriametrics.com/enterprise/). It is available for download and evaluation at [releases page](https://github.com/VictoriaMetrics/VictoriaMetrics/releases/latest).
To get the license key you can request a [free trial license](https://victoriametrics.com/products/enterprise/trial/).***
diff --git a/docs/Quick-Start.md b/docs/Quick-Start.md
index e921935cd..f5bbc3072 100644
--- a/docs/Quick-Start.md
+++ b/docs/Quick-Start.md
@@ -9,9 +9,6 @@ menu:
aliases:
- /Quick-Start.html
---
-
-# Quick start
-
## How to install
VictoriaMetrics is distributed in two forms:
diff --git a/docs/README.md b/docs/README.md
index 775066c2b..65212f14f 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -7,9 +7,9 @@
[](https://codecov.io/gh/VictoriaMetrics/VictoriaMetrics)
+
+
This allows Grafana to use a more efficient API to get label values.
@@ -498,7 +498,7 @@ via ["submit metrics" API](https://docs.datadoghq.com/api/latest/metrics/#submit
DataDog agent allows configuring destinations for metrics sending via ENV variable `DD_DD_URL`
or via [configuration file](https://docs.datadoghq.com/agent/guide/agent-configuration-files/) in section `dd_url`.
-
+
To configure DataDog agent via ENV variable add the following prefix:
@@ -525,7 +525,7 @@ pick [single-node or cluster URL](https://docs.victoriametrics.com/url-examples/
DataDog allows configuring [Dual Shipping](https://docs.datadoghq.com/agent/guide/dual-shipping/) for metrics
sending via ENV variable `DD_ADDITIONAL_ENDPOINTS` or via configuration file `additional_endpoints`.
-
+
Run DataDog using the following ENV variable with VictoriaMetrics as additional metrics receiver:
diff --git a/docs/Release-Guide.md b/docs/Release-Guide.md
index b37be2694..71684e92d 100644
--- a/docs/Release-Guide.md
+++ b/docs/Release-Guide.md
@@ -9,9 +9,6 @@ menu:
aliases:
- /Release-Guide.html
---
-
-# Release process guidance
-
## Pre-reqs
1. Make sure you have enterprise remote configured
@@ -154,7 +151,7 @@ Once updated, run the following commands:
1. Commit and push changes to `master`.
1. Run "Release" action on Github:
- 
+ 
1. Merge new PRs *"Automatic update CHANGELOGs and READMEs"* and *"Synchronize docs"* after pipelines are complete.
## Ansible Roles
diff --git a/docs/Single-server-VictoriaMetrics.md b/docs/Single-server-VictoriaMetrics.md
index 88471b7cd..d8c45d9d2 100644
--- a/docs/Single-server-VictoriaMetrics.md
+++ b/docs/Single-server-VictoriaMetrics.md
@@ -9,8 +9,6 @@ title: VictoriaMetrics
aliases:
- /Single-server-VictoriaMetrics.html
---
-# VictoriaMetrics
-
[](https://github.com/VictoriaMetrics/VictoriaMetrics/releases/latest)
[](https://hub.docker.com/r/victoriametrics/victoria-metrics)
[](https://slack.victoriametrics.com/)
@@ -20,9 +18,9 @@ aliases:
[](https://codecov.io/gh/VictoriaMetrics/VictoriaMetrics)
+
+
This allows Grafana to use a more efficient API to get label values.
@@ -511,7 +509,7 @@ via ["submit metrics" API](https://docs.datadoghq.com/api/latest/metrics/#submit
DataDog agent allows configuring destinations for metrics sending via ENV variable `DD_DD_URL`
or via [configuration file](https://docs.datadoghq.com/agent/guide/agent-configuration-files/) in section `dd_url`.
-
+
To configure DataDog agent via ENV variable add the following prefix:
@@ -538,7 +536,7 @@ pick [single-node or cluster URL](https://docs.victoriametrics.com/url-examples/
DataDog allows configuring [Dual Shipping](https://docs.datadoghq.com/agent/guide/dual-shipping/) for metrics
sending via ENV variable `DD_ADDITIONAL_ENDPOINTS` or via configuration file `additional_endpoints`.
-
+
Run DataDog using the following ENV variable with VictoriaMetrics as additional metrics receiver:
diff --git a/docs/Troubleshooting.md b/docs/Troubleshooting.md
index 7f7091545..ece608d74 100644
--- a/docs/Troubleshooting.md
+++ b/docs/Troubleshooting.md
@@ -9,9 +9,6 @@ menu:
aliases:
- /Troubleshooting.html
---
-
-# Troubleshooting
-
This document contains troubleshooting guides for most common issues when working with VictoriaMetrics:
- [General troubleshooting checklist](#general-troubleshooting-checklist)
diff --git a/docs/VictoriaLogs/CHANGELOG.md b/docs/VictoriaLogs/CHANGELOG.md
index 572a470c3..4705bc419 100644
--- a/docs/VictoriaLogs/CHANGELOG.md
+++ b/docs/VictoriaLogs/CHANGELOG.md
@@ -11,9 +11,6 @@ menu:
aliases:
- /VictoriaLogs/CHANGELOG.html
---
-
-# VictoriaLogs changelog
-
The following `tip` changes can be tested by building VictoriaLogs from the latest commit of [VictoriaMetrics](https://github.com/VictoriaMetrics/VictoriaMetrics/) repository
according to [these docs](https://docs.victoriametrics.com/victorialogs/quickstart/#building-from-source-code)
diff --git a/docs/VictoriaLogs/FAQ.md b/docs/VictoriaLogs/FAQ.md
index 5b0acf02f..b3989fd77 100644
--- a/docs/VictoriaLogs/FAQ.md
+++ b/docs/VictoriaLogs/FAQ.md
@@ -12,9 +12,6 @@ aliases:
- /VictoriaLogs/FAQ.html
- /VictoriaLogs/faq.html
---
-
-# VictoriaLogs FAQ
-
## What is the difference between VictoriaLogs and Elasticsearch (OpenSearch)?
Both Elasticsearch and VictoriaLogs allow ingesting structured and unstructured logs
diff --git a/docs/VictoriaLogs/LogsQL.md b/docs/VictoriaLogs/LogsQL.md
index 8c9c03e51..1cf4d3bdb 100644
--- a/docs/VictoriaLogs/LogsQL.md
+++ b/docs/VictoriaLogs/LogsQL.md
@@ -9,9 +9,6 @@ menu:
aliases:
- /VictoriaLogs/LogsQL.html
---
-
-# LogsQL
-
LogsQL is a simple yet powerful query language for [VictoriaLogs](https://docs.victoriametrics.com/victorialogs/).
See [examples](https://docs.victoriametrics.com/victorialogs/logsql-examples/) and [tutorial](#logsql-tutorial)
in order to feel the language.
diff --git a/docs/VictoriaLogs/QuickStart.md b/docs/VictoriaLogs/QuickStart.md
index edc5e686a..b67c5ee01 100644
--- a/docs/VictoriaLogs/QuickStart.md
+++ b/docs/VictoriaLogs/QuickStart.md
@@ -12,9 +12,6 @@ aliases:
- /victorialogs/quick-start.html
- /victorialogs/quick-start/
---
-
-# VictoriaLogs Quick Start
-
It is recommended to read [README](https://docs.victoriametrics.com/victorialogs/)
and [Key Concepts](https://docs.victoriametrics.com/victorialogs/keyconcepts/)
before you start working with VictoriaLogs.
diff --git a/docs/VictoriaLogs/Roadmap.md b/docs/VictoriaLogs/Roadmap.md
index 29878bb20..f4492f3e2 100644
--- a/docs/VictoriaLogs/Roadmap.md
+++ b/docs/VictoriaLogs/Roadmap.md
@@ -11,9 +11,6 @@ menu:
aliases:
- /VictoriaLogs/Roadmap.html
---
-
-# VictoriaLogs roadmap
-
The following functionality is available in [VictoriaLogs](https://docs.victoriametrics.com/victorialogs/):
- [Data ingestion](https://docs.victoriametrics.com/victorialogs/data-ingestion/).
diff --git a/docs/VictoriaLogs/data-ingestion/Filebeat.md b/docs/VictoriaLogs/data-ingestion/Filebeat.md
index 06a6c480b..84c8afdff 100644
--- a/docs/VictoriaLogs/data-ingestion/Filebeat.md
+++ b/docs/VictoriaLogs/data-ingestion/Filebeat.md
@@ -11,9 +11,6 @@ aliases:
- /victorialogs/data-ingestion/Filebeat.html
- /victorialogs/data-ingestion/filebeat.html
---
-
-# Filebeat setup
-
Specify [`output.elasticsearch`](https://www.elastic.co/guide/en/beats/filebeat/current/elasticsearch-output.html) section in the `filebeat.yml`
for sending the collected logs to [VictoriaLogs](https://docs.victoriametrics.com/victorialogs/):
diff --git a/docs/VictoriaLogs/data-ingestion/Fluentbit.md b/docs/VictoriaLogs/data-ingestion/Fluentbit.md
index 23352f2b1..e126134c7 100644
--- a/docs/VictoriaLogs/data-ingestion/Fluentbit.md
+++ b/docs/VictoriaLogs/data-ingestion/Fluentbit.md
@@ -17,7 +17,7 @@ aliases:
Specify [http output](https://docs.fluentbit.io/manual/pipeline/outputs/http) section in the `fluentbit.conf`
for sending the collected logs to [VictoriaLogs](https://docs.victoriametrics.com/victorialogs/):
-```conf
+```fluentbit
[Output]
Name http
Match *
@@ -37,7 +37,7 @@ and uses the correct [stream fields](https://docs.victoriametrics.com/victorialo
This can be done by specifying `debug` [parameter](https://docs.victoriametrics.com/victorialogs/data-ingestion/#http-parameters) in the `uri`
and inspecting VictoriaLogs logs then:
-```conf
+```fluentbit
[Output]
Name http
Match *
@@ -52,7 +52,7 @@ If some [log fields](https://docs.victoriametrics.com/victorialogs/keyconcepts/#
during data ingestion, then they can be put into `ignore_fields` [parameter](https://docs.victoriametrics.com/victorialogs/data-ingestion/#http-parameters).
For example, the following config instructs VictoriaLogs to ignore `log.offset` and `event.original` fields in the ingested logs:
-```conf
+```fluentbit
[Output]
Name http
Match *
@@ -66,7 +66,7 @@ For example, the following config instructs VictoriaLogs to ignore `log.offset`
If the Fluentbit sends logs to VictoriaLogs in another datacenter, then it may be useful enabling data compression via `compress gzip` option.
This usually allows saving network bandwidth and costs by up to 5 times:
-```conf
+```fluentbit
[Output]
Name http
Match *
@@ -82,7 +82,7 @@ By default, the ingested logs are stored in the `(AccountID=0, ProjectID=0)` [te
If you need storing logs in other tenant, then specify the needed tenant via `header` options.
For example, the following `fluentbit.conf` config instructs Fluentbit to store the data to `(AccountID=12, ProjectID=34)` tenant:
-```conf
+```fluentbit
[Output]
Name http
Match *
diff --git a/docs/VictoriaLogs/data-ingestion/Logstash.md b/docs/VictoriaLogs/data-ingestion/Logstash.md
index 1c232e506..d9d07bd67 100644
--- a/docs/VictoriaLogs/data-ingestion/Logstash.md
+++ b/docs/VictoriaLogs/data-ingestion/Logstash.md
@@ -11,13 +11,10 @@ aliases:
- /victorialogs/data-ingestion/logstash.html
- /victorialogs/data-ingestion/Logstash.html
---
-
-# Logstash setup
-
Specify [`output.elasticsearch`](https://www.elastic.co/guide/en/logstash/current/plugins-outputs-elasticsearch.html) section in the `logstash.conf` file
for sending the collected logs to [VictoriaLogs](https://docs.victoriametrics.com/victorialogs/):
-```conf
+```logstash
output {
elasticsearch {
hosts => ["http://localhost:9428/insert/elasticsearch/"]
@@ -39,7 +36,7 @@ and uses the correct [stream fields](https://docs.victoriametrics.com/victorialo
This can be done by specifying `debug` [parameter](https://docs.victoriametrics.com/victorialogs/data-ingestion/#http-parameters)
and inspecting VictoriaLogs logs then:
-```conf
+```logstash
output {
elasticsearch {
hosts => ["http://localhost:9428/insert/elasticsearch/"]
@@ -57,7 +54,7 @@ If some [log fields](https://docs.victoriametrics.com/victorialogs/keyconcepts/#
during data ingestion, then they can be put into `ignore_fields` [parameter](https://docs.victoriametrics.com/victorialogs/data-ingestion/#http-parameters).
For example, the following config instructs VictoriaLogs to ignore `log.offset` and `event.original` fields in the ingested logs:
-```conf
+```logstash
output {
elasticsearch {
hosts => ["http://localhost:9428/insert/elasticsearch/"]
@@ -74,7 +71,7 @@ output {
If the Logstash sends logs to VictoriaLogs in another datacenter, then it may be useful enabling data compression via `http_compression: true` option.
This usually allows saving network bandwidth and costs by up to 5 times:
-```conf
+```logstash
output {
elasticsearch {
hosts => ["http://localhost:9428/insert/elasticsearch/"]
@@ -92,7 +89,7 @@ By default, the ingested logs are stored in the `(AccountID=0, ProjectID=0)` [te
If you need storing logs in other tenant, then specify the needed tenant via `custom_headers` at `output.elasticsearch` section.
For example, the following `logstash.conf` config instructs Logstash to store the data to `(AccountID=12, ProjectID=34)` tenant:
-```conf
+```logstash
output {
elasticsearch {
hosts => ["http://localhost:9428/insert/elasticsearch/"]
diff --git a/docs/VictoriaLogs/data-ingestion/Promtail.md b/docs/VictoriaLogs/data-ingestion/Promtail.md
index c21bc85d3..ca0cdf76a 100644
--- a/docs/VictoriaLogs/data-ingestion/Promtail.md
+++ b/docs/VictoriaLogs/data-ingestion/Promtail.md
@@ -11,8 +11,6 @@ aliases:
- /victorialogs/data-ingestion/Promtail.html
- /victorialogs/data-ingestion/promtail.html
---
-# Promtail setup
-
[Promtail](https://grafana.com/docs/loki/latest/clients/promtail/) is a default log shipper for Grafana Loki.
Promtail can be configured to send the collected logs to VictoriaLogs according to the following docs.
diff --git a/docs/VictoriaLogs/data-ingestion/Vector.md b/docs/VictoriaLogs/data-ingestion/Vector.md
index 1e7bcb1a7..6d52fce50 100644
--- a/docs/VictoriaLogs/data-ingestion/Vector.md
+++ b/docs/VictoriaLogs/data-ingestion/Vector.md
@@ -11,9 +11,6 @@ aliases:
- /victorialogs/data-ingestion/Vector.html
- /victorialogs/data-ingestion/vector.html
---
-# Vector setup
-
-
## Elasticsearch sink
Specify [Elasticsearch sink type](https://vector.dev/docs/reference/configuration/sinks/elasticsearch/) in the `vector.toml`
diff --git a/docs/VictoriaLogs/data-ingestion/syslog.md b/docs/VictoriaLogs/data-ingestion/syslog.md
index 0fd664098..7d1343b48 100644
--- a/docs/VictoriaLogs/data-ingestion/syslog.md
+++ b/docs/VictoriaLogs/data-ingestion/syslog.md
@@ -7,9 +7,6 @@ menu:
parent: "victorialogs-data-ingestion"
weight: 10
---
-
-# Syslog setup
-
[VictoriaLogs](https://docs.victoriametrics.com/victorialogs/) can accept logs in [Syslog formats](https://en.wikipedia.org/wiki/Syslog) at the specified TCP and UDP addresses
via `-syslog.listenAddr.tcp` and `-syslog.listenAddr.udp` command-line flags. The following syslog formats are supported:
diff --git a/docs/VictoriaLogs/keyConcepts.md b/docs/VictoriaLogs/keyConcepts.md
index a5160568b..d6d47f3b8 100644
--- a/docs/VictoriaLogs/keyConcepts.md
+++ b/docs/VictoriaLogs/keyConcepts.md
@@ -10,9 +10,6 @@ menu:
aliases:
- /VictoriaLogs/keyConcepts.html
---
-
-# VictoriaLogs key concepts
-
## Data model
[VictoriaLogs](https://docs.victoriametrics.com/victorialogs/) works with both structured and unstructured logs.
diff --git a/docs/VictoriaLogs/logsql-examples.md b/docs/VictoriaLogs/logsql-examples.md
index a28eec5f5..878b4a0e2 100644
--- a/docs/VictoriaLogs/logsql-examples.md
+++ b/docs/VictoriaLogs/logsql-examples.md
@@ -7,9 +7,6 @@ menu:
parent: "victorialogs"
weight: 100
---
-
-# LogsQL examples
-
## How to select recently ingested logs?
[Run](https://docs.victoriametrics.com/victorialogs/querying/) the following query:
diff --git a/docs/VictoriaLogs/querying/README.md b/docs/VictoriaLogs/querying/README.md
index bdaad4a00..3752ad9be 100644
--- a/docs/VictoriaLogs/querying/README.md
+++ b/docs/VictoriaLogs/querying/README.md
@@ -206,14 +206,14 @@ The `
+
+{width="800"}
### Install in Kubernetes
diff --git a/docs/anomaly-detection/CHANGELOG.md b/docs/anomaly-detection/CHANGELOG.md
index 1bf25db6b..c9184f311 100644
--- a/docs/anomaly-detection/CHANGELOG.md
+++ b/docs/anomaly-detection/CHANGELOG.md
@@ -10,73 +10,70 @@ menu:
aliases:
- /anomaly-detection/CHANGELOG.html
---
-
-# CHANGELOG
-
Please find the changelog for VictoriaMetrics Anomaly Detection below.
-> **Important note: Users are strongly encouraged to upgrade to `vmanomaly` [v1.9.2](https://hub.docker.com/repository/docker/victoriametrics/vmanomaly/tags?page=1&ordering=name) or newer for optimal performance and accuracy. 
+
## How does vmanomaly work?
-`vmanomaly` applies built-in (or custom) [anomaly detection algorithms](/anomaly-detection/components/models.html), specified in a config file. Although a single config file supports one model, running multiple instances of `vmanomaly` with different configs is possible and encouraged for parallel processing or better support for your use case (i.e. simpler model for simple metrics, more sophisticated one for metrics with trends and seasonalities).
+`vmanomaly` applies built-in (or custom) [anomaly detection algorithms](./components/models.md), specified in a config file. Although a single config file supports one model, running multiple instances of `vmanomaly` with different configs is possible and encouraged for parallel processing or better support for your use case (i.e. simpler model for simple metrics, more sophisticated one for metrics with trends and seasonalities).
-1. For more detailed information, please visit the [overview section](/anomaly-detection/Overview.html#about).
-2. To view a diagram illustrating the interaction of components, please explore the [components section](/anomaly-detection/components/).
+1. For more detailed information, please visit the [overview section](./Overview.md#about).
+2. To view a diagram illustrating the interaction of components, please explore the [components section](./components/README.md).
## What data does vmanomaly operate on?
-`vmanomaly` operates on data fetched from VictoriaMetrics, where you can leverage full power of [MetricsQL](https://docs.victoriametrics.com/metricsql/) for data selection, sampling, and processing. Users can also [apply global filters](https://docs.victoriametrics.com/#prometheus-querying-api-enhancements) for more targeted data analysis, enhancing scope limitation and tenant visibility.
+`vmanomaly` operates on data fetched from VictoriaMetrics, where you can leverage full power of [MetricsQL](../MetricsQL.md) for data selection, sampling, and processing. Users can also [apply global filters](../README.md#prometheus-querying-api-enhancements) for more targeted data analysis, enhancing scope limitation and tenant visibility.
-Respective config is defined in a [`reader`](/anomaly-detection/components/reader.html#vm-reader) section.
+Respective config is defined in a [`reader`](./components/reader.md#vm-reader) section.
## Handling noisy input data
-`vmanomaly` operates on data fetched from VictoriaMetrics using [MetricsQL](https://docs.victoriametrics.com/metricsql/) queries, so the initial data quality can be fine-tuned with aggregation, grouping, and filtering to reduce noise and improve anomaly detection accuracy.
+`vmanomaly` operates on data fetched from VictoriaMetrics using [MetricsQL](../MetricsQL.md) queries, so the initial data quality can be fine-tuned with aggregation, grouping, and filtering to reduce noise and improve anomaly detection accuracy.
## Output produced by vmanomaly
-`vmanomaly` models generate [metrics](/anomaly-detection/components/models.html#vmanomaly-output) like `anomaly_score`, `yhat`, `yhat_lower`, `yhat_upper`, and `y`. These metrics provide a comprehensive view of the detected anomalies. The service also produces [health check metrics](/anomaly-detection/components/monitoring.html#metrics-generated-by-vmanomaly) for monitoring its performance.
+`vmanomaly` models generate [metrics](./components/models.md#vmanomaly-output) like `anomaly_score`, `yhat`, `yhat_lower`, `yhat_upper`, and `y`. These metrics provide a comprehensive view of the detected anomalies. The service also produces [health check metrics](./components/monitoring.md#metrics-generated-by-vmanomaly) for monitoring its performance.
## Choosing the right model for vmanomaly
-Selecting the best model for `vmanomaly` depends on the data's nature and the [types of anomalies](https://victoriametrics.com/blog/victoriametrics-anomaly-detection-handbook-chapter-2/#categories-of-anomalies) to detect. For instance, [Z-score](anomaly-detection/components/models.html#z-score) is suitable for data without trends or seasonality, while more complex patterns might require models like [Prophet](anomaly-detection/components/models.html#prophet).
+Selecting the best model for `vmanomaly` depends on the data's nature and the [types of anomalies](https://victoriametrics.com/blog/victoriametrics-anomaly-detection-handbook-chapter-2/#categories-of-anomalies) to detect. For instance, [Z-score](./components/models.md#z-score) is suitable for data without trends or seasonality, while more complex patterns might require models like [Prophet](./components/models.md#prophet).
-Also, starting from [v1.12.0](/anomaly-detection/changelog/#v1120) it's possible to auto-tune the most important params of selected model class, find [the details here](https://docs.victoriametrics.com/anomaly-detection/components/models/#autotuned).
+Also, starting from [v1.12.0](./CHANGELOG.md#v1120) it's possible to auto-tune the most important params of selected model class, find [the details here](./components/models.md#autotuned).
Please refer to [respective blogpost on anomaly types and alerting heuristics](https://victoriametrics.com/blog/victoriametrics-anomaly-detection-handbook-chapter-2/) for more details.
-Still not 100% sure what to use? We are [here to help](/anomaly-detection/#get-in-touch).
+Still not 100% sure what to use? We are [here to help](./README.md#get-in-touch).
## Alert generation in vmanomaly
-While `vmanomaly` detects anomalies and produces scores, it *does not directly generate alerts*. The anomaly scores are written back to VictoriaMetrics, where an external alerting tool, like [`vmalert`](/vmalert.html), can be used to create alerts based on these scores for integrating it with your alerting management system.
+While `vmanomaly` detects anomalies and produces scores, it *does not directly generate alerts*. The anomaly scores are written back to VictoriaMetrics, where an external alerting tool, like [`vmalert`](../vmalert.md), can be used to create alerts based on these scores for integrating it with your alerting management system.
## Preventing alert fatigue
-Produced anomaly scores are designed in such a way that values from 0.0 to 1.0 indicate non-anomalous data, while a value greater than 1.0 is generally classified as an anomaly. However, there are no perfect models for anomaly detection, that's why reasonable defaults expressions like `anomaly_score > 1` may not work 100% of the time. However, anomaly scores, produced by `vmanomaly` are written back as metrics to VictoriaMetrics, where tools like [`vmalert`](/vmalert.html) can use [MetricsQL](https://docs.victoriametrics.com/metricsql/) expressions to fine-tune alerting thresholds and conditions, balancing between avoiding [false negatives](https://victoriametrics.com/blog/victoriametrics-anomaly-detection-handbook-chapter-1/#false-negative) and reducing [false positives](https://victoriametrics.com/blog/victoriametrics-anomaly-detection-handbook-chapter-1/#false-positive).
+Produced anomaly scores are designed in such a way that values from 0.0 to 1.0 indicate non-anomalous data, while a value greater than 1.0 is generally classified as an anomaly. However, there are no perfect models for anomaly detection, that's why reasonable defaults expressions like `anomaly_score > 1` may not work 100% of the time. However, anomaly scores, produced by `vmanomaly` are written back as metrics to VictoriaMetrics, where tools like [`vmalert`](../vmalert.md) can use [MetricsQL](../MetricsQL.md) expressions to fine-tune alerting thresholds and conditions, balancing between avoiding [false negatives](https://victoriametrics.com/blog/victoriametrics-anomaly-detection-handbook-chapter-1/#false-negative) and reducing [false positives](https://victoriametrics.com/blog/victoriametrics-anomaly-detection-handbook-chapter-1/#false-positive).
## How to backtest particular configuration on historical data?
-Starting from [v1.7.2](/anomaly-detection/changelog/#v172) you can produce (and write back to VictoriaMetrics TSDB) anomaly scores for historical (backtesting) period, using `BacktestingScheduler` [component](/anomaly-detection/components/scheduler/#backtesting-scheduler) to imitate consecutive "production runs" of `PeriodicScheduler` [component](/anomaly-detection/components/scheduler/#periodic-scheduler). Please find an example config below:
+Starting from [v1.7.2](./CHANGELOG.md#v172) you can produce (and write back to VictoriaMetrics TSDB) anomaly scores for historical (backtesting) period, using `BacktestingScheduler` [component](./components/scheduler.md#backtesting-scheduler) to imitate consecutive "production runs" of `PeriodicScheduler` [component](./components/scheduler.md#periodic-scheduler). Please find an example config below:
```yaml
schedulers:
@@ -90,7 +87,7 @@ models:
# ...
schedulers: ['scheduler_alias'] # if omitted, all the defined schedulers will be attached
queries: ['query_alias1'] # if omitted, all the defined queries will be attached
- # https://docs.victoriametrics.com/anomaly-detection/components/models/#provide-series
+ # {{% ref "./components/models.md#provide-series" %}}
provide_series: ['anomaly_score']
# ... other models
@@ -100,23 +97,23 @@ reader:
query_alias1: 'some_metricsql_query'
sampling_frequency: '1m' # change to whatever you need in data granularity
# other params if needed
- # https://docs.victoriametrics.com/anomaly-detection/components/reader/#vm-reader
+ # {{% ref "./components/reader.md#vm-reader" %}}
writer:
datasource_url: 'some_url_to_write_produced_data_to'
# other params if needed
- # https://docs.victoriametrics.com/anomaly-detection/components/writer/#vm-writer
+ # {{% ref "./components/writer.md#vm-writer" %}}
# optional monitoring section if needed
-# https://docs.victoriametrics.com/anomaly-detection/components/monitoring/
+# {{% ref "./components/monitoring.md" %}}
```
-Configuration above will produce N intervals of full length (`fit_window`=14d + `fit_every`=1h) until `to_iso` timestamp is reached to run N consecutive `fit` calls to train models; Then these models will be used to produce `M = [fit_every / sampling_frequency]` infer datapoints for `fit_every` range at the end of each such interval, imitating M consecutive calls of `infer_every` in `PeriodicScheduler` [config](/anomaly-detection/components/scheduler/#periodic-scheduler). These datapoints then will be written back to VictoriaMetrics TSDB, defined in `writer` [section](/anomaly-detection/components/writer/#vm-writer) for further visualization (i.e. in VMUI or Grafana)
+Configuration above will produce N intervals of full length (`fit_window`=14d + `fit_every`=1h) until `to_iso` timestamp is reached to run N consecutive `fit` calls to train models; Then these models will be used to produce `M = [fit_every / sampling_frequency]` infer datapoints for `fit_every` range at the end of each such interval, imitating M consecutive calls of `infer_every` in `PeriodicScheduler` [config](./components/scheduler.md#periodic-scheduler). These datapoints then will be written back to VictoriaMetrics TSDB, defined in `writer` [section](./components/writer.md#vm-writer) for further visualization (i.e. in VMUI or Grafana)
## Resource consumption of vmanomaly
-`vmanomaly` itself is a lightweight service, resource usage is primarily dependent on [scheduling](/anomaly-detection/components/scheduler.html) (how often and on what data to fit/infer your models), [# and size of timeseries returned by your queries](/anomaly-detection/components/reader.html#vm-reader), and the complexity of the employed [models](anomaly-detection/components/models.html). Its resource usage is directly related to these factors, making it adaptable to various operational scales.
+`vmanomaly` itself is a lightweight service, resource usage is primarily dependent on [scheduling](./components/scheduler.md) (how often and on what data to fit/infer your models), [# and size of timeseries returned by your queries](./components/reader.md#vm-reader), and the complexity of the employed [models](./components/models.md). Its resource usage is directly related to these factors, making it adaptable to various operational scales.
-> **Note**: Starting from [v1.13.0](/anomaly-detection/changelog/#v1130), there is a mode to save anomaly detection models on host filesystem after `fit` stage (instead of keeping them in-memory by default). **Resource-intensive setups** (many models, many metrics, bigger [`fit_window` arg](/anomaly-detection/components/scheduler/#periodic-scheduler-config-example)) and/or 3rd-party models that store fit data (like [ProphetModel](/anomaly-detection/components/models/index.html#prophet) or [HoltWinters](/anomaly-detection/components/models/index.html#holt-winters)) will have RAM consumption greatly reduced at a cost of slightly slower `infer` stage. To enable it, you need to set environment variable `VMANOMALY_MODEL_DUMPS_DIR` to desired location. [Helm charts](https://github.com/VictoriaMetrics/helm-charts/blob/master/charts/victoria-metrics-anomaly/README.md) are being updated accordingly ([`StatefulSet`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) for persistent storage starting from chart version `1.3.0`).
+> **Note**: Starting from [v1.13.0](./CHANGELOG.md#v1130), there is a mode to save anomaly detection models on host filesystem after `fit` stage (instead of keeping them in-memory by default). **Resource-intensive setups** (many models, many metrics, bigger [`fit_window` arg](./components/scheduler.md#periodic-scheduler-config-example)) and/or 3rd-party models that store fit data (like [ProphetModel](./components/models.md#prophet) or [HoltWinters](./components/models.md#holt-winters)) will have RAM consumption greatly reduced at a cost of slightly slower `infer` stage. To enable it, you need to set environment variable `VMANOMALY_MODEL_DUMPS_DIR` to desired location. [Helm charts](https://github.com/VictoriaMetrics/helm-charts/blob/master/charts/victoria-metrics-anomaly/README.md) are being updated accordingly ([`StatefulSet`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) for persistent storage starting from chart version `1.3.0`).
Here's an example of how to set it up in docker-compose using volumes:
```yaml
@@ -150,13 +147,13 @@ volumes:
## Scaling vmanomaly
> **Note:** As of latest release we don't support cluster or auto-scaled version yet (though, it's in our roadmap for - better backends, more parallelization, etc.), so proposed workarounds should be addressed manually.
-`vmanomaly` can be scaled horizontally by launching multiple independent instances, each with its own [MetricsQL](https://docs.victoriametrics.com/metricsql/) queries and [configurations](/anomaly-detection/components/):
+`vmanomaly` can be scaled horizontally by launching multiple independent instances, each with its own [MetricsQL](../MetricsQL.md) queries and [configurations](./components/README.md):
-- By splitting **queries**, [defined in reader section](/anomaly-detection/components/reader/?highlight=queries#vm-reader) and spawn separate service around it. Also in case you have *only 1 query returning huge amount of timeseries*, you can further split it by applying MetricsQL filters, i.e. using "extra_filters" [param in reader](/anomaly-detection/components/reader/?highlight=extra_filters#vm-reader)
+- By splitting **queries**, [defined in reader section](./components/reader.md#vm-reader) and spawn separate service around it. Also in case you have *only 1 query returning huge amount of timeseries*, you can further split it by applying MetricsQL filters, i.e. using "extra_filters" [param in reader](./components/reader.md#vm-reader)
-- or **models** (in case you decide to run several models for each timeseries received i.e. for averaging anomaly scores in your alerting rules of `vmalert` or using a vote approach to reduce false positives) - see `queries` arg in [model config](/anomaly-detection/components/models/#queries)
+- or **models** (in case you decide to run several models for each timeseries received i.e. for averaging anomaly scores in your alerting rules of `vmalert` or using a vote approach to reduce false positives) - see `queries` arg in [model config](./components/models.md#queries)
-- or **schedulers** (in case you want the same models to be trained under several schedules) - see `schedulers` arg [model section](/anomaly-detection/components/models/#schedulers) and `scheduler` [component itself](/anomaly-detection/components/scheduler/)
+- or **schedulers** (in case you want the same models to be trained under several schedules) - see `schedulers` arg [model section](./components/models.md#schedulers) and `scheduler` [component itself](./components/scheduler.md)
Here's an example of how to split on `extra_filters` param
diff --git a/docs/anomaly-detection/Overview.md b/docs/anomaly-detection/Overview.md
index 10a73e4bf..5e2ded6ce 100644
--- a/docs/anomaly-detection/Overview.md
+++ b/docs/anomaly-detection/Overview.md
@@ -11,10 +11,6 @@ aliases:
- /anomaly-detection.html
- /anomaly-detection/overview.html
---
-
-
-# Overview
-
## About
**VictoriaMetrics Anomaly Detection** (or shortly, `vmanomaly`) is a service that continuously scans VictoriaMetrics time
@@ -37,7 +33,7 @@ metrics.
`vmanomaly` can be used as a helper to set up your own alerting. You can rely on the spikes you see in anomaly scores to form the metric queries for alerting rules.
-> **Note: `vmanomaly` is a part of [enterprise package](https://docs.victoriametrics.com/enterprise/). You need to get a [free trial license](https://victoriametrics.com/products/enterprise/trial/) for evaluation.**
+> **Note: `vmanomaly` is a part of [enterprise package](../enterprise.md). You need to get a [free trial license](https://victoriametrics.com/products/enterprise/trial/) for evaluation.**
## How?
@@ -53,9 +49,9 @@ processes in parallel, each using its own config.
## Models
Currently, vmanomaly ships with a set of built-in models:
-> For a detailed overview, see [model section](/anomaly-detection/components/models.html)
+> For a detailed overview, see [model section](./components/models.md)
-1. [**ZScore**](/anomaly-detection/components/models.html#z-score)
+1. [**ZScore**](./components/models.md#z-score)
_(useful for testing)_
@@ -63,7 +59,7 @@ Currently, vmanomaly ships with a set of built-in models:
from time-series mean (straight line). Keeps only two model parameters internally:
`mean` and `std` (standard deviation).
-1. [**Prophet**](/anomaly-detection/components/models.html#prophet)
+1. [**Prophet**](./components/models.md#prophet)
_(simplest in configuration, recommended for getting started)_
@@ -77,32 +73,32 @@ Currently, vmanomaly ships with a set of built-in models:
See [Prophet documentation](https://facebook.github.io/prophet/)
-1. [**Holt-Winters**](/anomaly-detection/components/models.html#holt-winters)
+1. [**Holt-Winters**](./components/models.md#holt-winters)
Very popular forecasting algorithm. See [statsmodels.org documentation](
https://www.statsmodels.org/stable/generated/statsmodels.tsa.holtwinters.ExponentialSmoothing.html)
for Holt-Winters exponential smoothing.
-1. [**Seasonal-Trend Decomposition**](/anomaly-detection/components/models.html#seasonal-trend-decomposition)
+1. [**Seasonal-Trend Decomposition**](./components/models.md#seasonal-trend-decomposition)
Extracts three components: season, trend, and residual, that can be plotted individually for
easier debugging. Uses LOESS (locally estimated scatterplot smoothing).
See [statsmodels.org documentation](https://www.statsmodels.org/dev/examples/notebooks/generated/stl_decomposition.html)
for LOESS STD.
-1. [**Rolling Quantile**](/anomaly-detection/components/models.html#rolling-quantile)
+1. [**Rolling Quantile**](./components/models.md#rolling-quantile)
A simple moving window of quantiles. Easy to use, easy to understand, but not as powerful as
other models.
-1. [**Isolation Forest**](/anomaly-detection/components/models.html#isolation-forest-multivariate)
+1. [**Isolation Forest**](./components/models.md#isolation-forest-multivariate)
Detects anomalies using binary trees. It works for both univariate and multivariate data. Be aware of [the curse of dimensionality](https://en.wikipedia.org/wiki/Curse_of_dimensionality) in the case of multivariate data - we advise against using a single model when handling multiple time series *if the number of these series significantly exceeds their average length (# of data points)*.
The algorithm has a linear time complexity and a low memory requirement, which works well with high-volume data. See [scikit-learn.org documentation](https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.IsolationForest.html) for Isolation Forest.
-1. [**MAD (Median Absolute Deviation)**](anomaly-detection/components/models.html#mad-median-absolute-deviation)
+1. [**MAD (Median Absolute Deviation)**](./components/models.md#mad-median-absolute-deviation)
A robust method for anomaly detection that is less sensitive to outliers in data compared to standard deviation-based models. It considers a point as an anomaly if the absolute deviation from the median is significantly large.
@@ -111,14 +107,14 @@ Currently, vmanomaly ships with a set of built-in models:
For example, here’s how Prophet predictions could look like on a real-data example
(Prophet auto-detected seasonality interval):
-
+
And here’s what Holt-Winters predictions real-world data could look like (seasonality manually
set to 1 week). Notice that it predicts anomalies in
different places than Prophet because the model noticed there are usually spikes on Friday
morning, so it accounted for that:
-
+
## Process
Upon starting, vmanomaly queries the initial range of data, and trains its model (“fit” by convention).
@@ -132,26 +128,26 @@ optionally preserving labels).
## Usage
-> Starting from [v1.5.0](/anomaly-detection/CHANGELOG.html#v150), vmanomaly requires a license key to run. You can obtain a trial license key [here](https://victoriametrics.com/products/enterprise/trial/).
+> Starting from [v1.5.0](./CHANGELOG.md#v150), vmanomaly requires a license key to run. You can obtain a trial license key [here](https://victoriametrics.com/products/enterprise/trial/).
-> See [Quickstart](/anomaly-detection/QuickStart.html).
+> See [Quickstart](./QuickStart.md).
-> See [Integration guide: vmanomaly and vmalert](/anomaly-detection/guides/guide-vmanomaly-vmalert.html).
+> See [Integration guide: vmanomaly and vmalert](./guides/guide-vmanomaly-vmalert/README.md).
### Config file
There are 4 required sections in config file:
-* [`schedulers`](/anomaly-detection/components/scheduler.html) - defines how often to run and make inferences, as well as what timerange to use to train the model.
-* [`models`](/anomaly-detection/components/models.html) - specific model parameters and configurations.
-* [`reader`](/anomaly-detection/components/reader.html) - how to read data and where it is located
-* [`writer`](/anomaly-detection/components/writer.html) - where and how to write the generated output.
+* [`schedulers`](./components/scheduler.md) - defines how often to run and make inferences, as well as what timerange to use to train the model.
+* [`models`](./components/models.md) - specific model parameters and configurations.
+* [`reader`](./components/reader.md) - how to read data and where it is located
+* [`writer`](./components/writer.md) - where and how to write the generated output.
[`monitoring`](#monitoring) - defines how to monitor work of *vmanomaly* service. This config section is *optional*.
-> For a detailed description, see [config sections](/anomaly-detection/components)
+> For a detailed description, see [config sections](./components/README.md)
#### Config example
-Here is an example of config file that will run [Facebook's Prophet model](/anomaly-detection/components/models.html#prophet), that will be retrained every 2 hours on 14 days of previous data. It will generate inference results (including `anomaly_score` metric) every 1 minute.
+Here is an example of config file that will run [Facebook's Prophet model](./components/models.md#prophet), that will be retrained every 2 hours on 14 days of previous data. It will generate inference results (including `anomaly_score` metric) every 1 minute.
You need to specify your datasource urls to use it:
@@ -183,7 +179,7 @@ writer:
*vmanomaly* can be monitored by using push or pull approach.
It can push metrics to VictoriaMetrics or expose metrics in Prometheus exposition format.
-> For a detailed description, see [monitoring section](/anomaly-detection/components/monitoring.html)
+> For a detailed description, see [monitoring section](./components/monitoring.md)
#### Push approach
@@ -201,7 +197,7 @@ monitoring:
#### Pull approach
*vmanomaly* can export internal metrics in Prometheus exposition format at `/metrics` page.
-These metrics can be scraped via [vmagent](https://docs.victoriametrics.com/vmagent/) or Prometheus.
+These metrics can be scraped via [vmagent](../vmagent.md) or Prometheus.
In order to enable pull approach, specify `pull` section in config file:
@@ -222,9 +218,9 @@ To use *vmanomaly* you need to pull docker image:
docker pull victoriametrics/vmanomaly:latest
```
-> Note: please check what is latest release in [CHANGELOG](/anomaly-detection/CHANGELOG.html)
+> Note: please check what is latest release in [CHANGELOG](./CHANGELOG.md)
-> Note: `us-docker.pkg.dev/victoriametrics-test/public/vmanomaly-trial` is deprecated since [v1.6.0](/anomaly-detection/CHANGELOG.html#v160). Use [DockerHub repo](https://hub.docker.com/r/victoriametrics/vmanomaly/tags) instead
+> Note: `us-docker.pkg.dev/victoriametrics-test/public/vmanomaly-trial` is deprecated since [v1.6.0](./CHANGELOG.md#v160). Use [DockerHub repo](https://hub.docker.com/r/victoriametrics/vmanomaly/tags) instead
You can put a tag on it for your convenience:
@@ -263,7 +259,7 @@ The license key can be passed via the following command-line flags:
In order to make it easier to monitor the license expiration date, the following metrics are exposed(see
[Monitoring](#monitoring) section for details on how to scrape them):
-```
+```promtextmetric
# HELP vm_license_expires_at When the license expires as a Unix timestamp in seconds
# TYPE vm_license_expires_at gauge
vm_license_expires_at 1.6963776e+09
@@ -272,7 +268,7 @@ vm_license_expires_at 1.6963776e+09
vm_license_expires_in_seconds 4.886608e+06
```
-Example alerts for [vmalert](https://docs.victoriametrics.com/vmalert/):
+Example alerts for [vmalert](../vmalert.md):
```yaml
groups:
diff --git a/docs/anomaly-detection/Presets.md b/docs/anomaly-detection/Presets.md
index c593a0c16..2a10f21e3 100644
--- a/docs/anomaly-detection/Presets.md
+++ b/docs/anomaly-detection/Presets.md
@@ -8,17 +8,16 @@ menu:
weight: 1
title: Presets
---
-# Anomaly detection presets
-> Please check the [Quick Start Guide](/anomaly-detection/quickstart/) to install and run `vmanomaly`
+> Please check the [Quick Start Guide](./QuickStart.md) to install and run `vmanomaly`
-> Presets are available starting from [v1.13.0](/anomaly-detection/CHANGELOG/#v1130)
+> Presets are available starting from [v1.13.0](./CHANGELOG.md#v1130)
**Preset** mode allows for simpler configuration and anomaly detection with `vmanomaly` on widely-recognized metrics, such as those generated by [node_exporter](https://github.com/prometheus/node_exporter), which are typically challenging to monitor using static threshold-based alerting rules.
-This approach represents a paradigm shift from traditional [static threshold-based alerting rules](https://victoriametrics.com/blog/victoriametrics-anomaly-detection-handbook-chapter-1/#rule-based-alerting), focused on *raw metric values*, to *static* rules based on [`anomaly_scores`](/anomaly-detection/faq/#what-is-anomaly-score). These scores offer a consistent, default threshold that remains stable over time, being adjusted for trends, seasonality, data scale, thus, reducing the engineering effort required for maintenance. Anomaly scores are produced by [machine learning models](/anomaly-detection/components/models), which are regularly retrained on varying time frames, ensuring alerts remain current and responsive to evolving data patterns.
+This approach represents a paradigm shift from traditional [static threshold-based alerting rules](https://victoriametrics.com/blog/victoriametrics-anomaly-detection-handbook-chapter-1/#rule-based-alerting), focused on *raw metric values*, to *static* rules based on [`anomaly_scores`](./FAQ.md#what-is-anomaly-score). These scores offer a consistent, default threshold that remains stable over time, being adjusted for trends, seasonality, data scale, thus, reducing the engineering effort required for maintenance. Anomaly scores are produced by [machine learning models](./components/models.md), which are regularly retrained on varying time frames, ensuring alerts remain current and responsive to evolving data patterns.
-Additionally, **preset mode** minimizes user input needed to run the service. You can configure `vmanomaly` by specifying only the preset name and data sources in the [`reader`](/anomaly-detection/components/reader/) and [`writer`](/anomaly-detection/components/writer/) sections of the configuration file. All other parameters are already preconfigured.
+Additionally, **preset mode** minimizes user input needed to run the service. You can configure `vmanomaly` by specifying only the preset name and data sources in the [`reader`](./components/reader.md) and [`writer`](./components/writer.md) sections of the configuration file. All other parameters are already preconfigured.
Available presets:
@@ -35,11 +34,12 @@ writer:
datasource_url: "http://victoriametrics:8428/" # your datasource url
# tenant_id: '0:0' # specify for cluster version
```
-Run a service using config file with one of the [available options](/anomaly-detection/quickstart/#how-to-install-and-run-vmanomaly).
+Run a service using config file with one of the [available options](./QuickStart.md#how-to-install-and-run-vmanomaly).
After you run `vmanomaly` with `preset` arg specified, available assets can be viewed, copied and downloaded at `http://localhost:8490/presets/` endpoint.
-
+
+{width="800px"}
## Node-Exporter
@@ -51,12 +51,12 @@ preset: "node-exporter"
```
### Generated anomaly scores
-Machine learning models will be fit for each timeseries, returned by underlying [MetricsQL](https://docs.victoriametrics.com/metricsql/) queries.
-Anomaly score metric labels will also contain [model classes](/anomaly-detection/components/models/) and [schedulers](/anomaly-detection/components/scheduler/) for labelset uniqueness.
+Machine learning models will be fit for each timeseries, returned by underlying [MetricsQL](../MetricsQL.md) queries.
+Anomaly score metric labels will also contain [model classes](./components/models.md) and [schedulers](./components/scheduler.md) for labelset uniqueness.
Here's an example of produced metrics:
-```shell
+```promtextmetric
anomaly_score{for="cpu_seconds_total", instance="node-exporter:9100", preset="node-exporter", mode="system", model_alias="prophet", scheduler_alias="1d_1m"} 0.23451242720277776
anomaly_score{for="cpu_seconds_total", instance="node-exporter:9100", preset="node-exporter", mode="user", model_alias="prophet", scheduler_alias="1d_1m"} 0.2637952255694444
anomaly_score{for="page_faults", instance="node-exporter:9100", job="node-exporter", preset="node-exporter", model_alias="prophet", scheduler_alias="1d_1m"} 0.00593712535
@@ -101,7 +101,7 @@ Grafana dashboard `.json` file can be found [here](https://github.com/VictoriaMe
The produced anomaly scores will have a label `for` containing the name of corresponding indicator.
-| Indicator | @@ -111,34 +111,94 @@ The produced anomaly scores will have a label `for` containing the name of corre|||||
|---|---|---|---|---|---|
page_faults |
- node_vmstat_pgmajfault |
- Number of major faults that have occurred since the last update. Major faults occur when a process tries to access a page in memory that is not currently mapped in the process's address space, and it requires loading data from the disk. | ++ +`page_faults` + | ++ +`node_vmstat_pgmajfault` + | ++ +Number of major faults that have occurred since the last update. Major faults occur when a process tries to access a page in memory that is not currently mapped in the process's address space, and it requires loading data from the disk. + |
context_switch |
- node_context_switches_total |
- This metric represents the total number of context switches across all CPUs. | ++ +`context_switch` + | ++ +`node_context_switches_total` + | ++ +This metric represents the total number of context switches across all CPUs. + |
cpu_seconds_total |
- node_cpu_seconds_total |
- Total amount of CPU time consumed by the system in seconds by CPU processing mode (e.g., user, system, idle). | ++ +`cpu_seconds_total` + | ++ +`node_cpu_seconds_total` + | ++ +Total amount of CPU time consumed by the system in seconds by CPU processing mode (e.g., user, system, idle). + |
host_network_receive_errors & host_network_transmit_errors |
- node_network_receive_errs_total, node_network_receive_packets_total, node_network_transmit_errs_total, node_network_transmit_packets_total
- | Total number of errors encountered while receiving/transmitting packets on the network interfaces of a node. | ++ +`host_network_receive_errors` & `host_network_transmit_errors` + | ++ +`node_network_receive_errs_total`, +`node_network_receive_packets_total`, +`node_network_transmit_errs_total`, +`node_network_transmit_packets_total` + | + +Total number of errors encountered while receiving/transmitting packets on the network interfaces of a node. + |
receive_bytes & transmit_bytes |
- node_network_receive_bytes_total, node_network_transmit_bytes_total |
- Total number of bytes received/transmitted on network interfaces of a node. | ++ +`receive_bytes` & `transmit_bytes` + | ++ +`node_network_receive_bytes_total`, +`node_network_transmit_bytes_total` + | ++ +Total number of bytes received/transmitted on network interfaces of a node. + |
read_latency & write_latency |
- node_disk_read_time_seconds_total, node_disk_reads_completed_total, node_disk_write_time_seconds_total, node_disk_writes_completed_total |
- Disk latency. The total read/write time spent in seconds. / The total number of reads/writes completed successfully. | ++ +`read_latency` & `write_latency` + | ++ +`node_disk_read_time_seconds_total`, +`node_disk_reads_completed_total`, +`node_disk_write_time_seconds_total`, +`node_disk_writes_completed_total` + | ++ +Disk latency. The total read/write time spent in seconds. / The total number of reads/writes completed successfully. + |
+
+{width="800px"}
At this timestamp on the **'Number of Anomalous Indicators by Node'** graph we can identify the node that had the most anomalies: `10.142.0.27`
-
+
+{width="800px"}
Now you can select anomalous node to drill down further (local):
-
+
+{width="800px"}
For this node from the timestamp `2024-06-03 10:35:00` CPU time spent handling software interrupts started to grow.
(`cpu_seconds_total{mode="softirq"}`)
-
+
+{width="800px"}
At the same time `cpu_seconds_total` for `steal` mode started to grow as well.
-
+
+{width="800px"}
diff --git a/docs/anomaly-detection/QuickStart.md b/docs/anomaly-detection/QuickStart.md
index 873f8e677..2fb20fa7e 100644
--- a/docs/anomaly-detection/QuickStart.md
+++ b/docs/anomaly-detection/QuickStart.md
@@ -10,11 +10,8 @@ menu:
aliases:
- /anomaly-detection/QuickStart.html
---
-
-# VictoriaMetrics Anomaly Detection Quick Start
-
-For service introduction visit [README](/anomaly-detection/) page
-and [Overview](/anomaly-detection/overview.html) of how `vmanomaly` works.
+For service introduction visit [README](./README.md) page
+and [Overview](./Overview.md) of how `vmanomaly` works.
## How to install and run vmanomaly
@@ -25,7 +22,7 @@ The following options are available:
- [To run Docker image](#docker)
- [To run in Kubernetes with Helm charts](#kubernetes-with-helm-charts)
-> **Note**: Starting from [v1.13.0](/anomaly-detection/changelog/#v1130) there is a mode to keep anomaly detection models on host filesystem after `fit` stage (instead of keeping them in-memory by default); This may lead to **noticeable reduction of RAM used** on bigger setups. See instructions [here](/anomaly-detection/faq/#resource-consumption-of-vmanomaly).
+> **Note**: Starting from [v1.13.0](./CHANGELOG.md#v1130) there is a mode to keep anomaly detection models on host filesystem after `fit` stage (instead of keeping them in-memory by default); This may lead to **noticeable reduction of RAM used** on bigger setups. See instructions [here](./FAQ.md#resource-consumption-of-vmanomaly).
### Docker
@@ -84,13 +81,13 @@ services:
# ...
```
-For a complete docker-compose example please refer to [our alerting guide](/anomaly-detection/guides/guide-vmanomaly-vmalert/), chapter [docker-compose](/anomaly-detection/guides/guide-vmanomaly-vmalert/#docker-compose)
+For a complete docker-compose example please refer to [our alerting guide](./guides/guide-vmanomaly-vmalert/README.md), chapter [docker-compose](./guides/guide-vmanomaly-vmalert/README.md#docker-compose)
See also:
-- Verify the license online OR offline. See the details [here](/anomaly-detection/overview/#licensing).
+- Verify the license online OR offline. See the details [here](./Overview.md#licensing).
- [How to configure `vmanomaly`](#how-to-configure-vmanomaly)
### Kubernetes with Helm charts
@@ -110,47 +107,47 @@ Here is an example of config file that will run [Facebook Prophet](https://faceb
```yaml
schedulers:
2h_1m:
- # https://docs.victoriametrics.com/anomaly-detection/components/scheduler/#periodic-scheduler
+ # {{% ref "./components/scheduler.md#periodic-scheduler" %}}
class: 'periodic'
infer_every: '1m'
fit_every: '2h'
fit_window: '2w'
models:
- # https://docs.victoriametrics.com/anomaly-detection/components/models/#prophet
+ # {{% ref "./components/models.md#prophet" %}}
prophet_model:
class: "prophet" # or "model.prophet.ProphetModel" until v1.13.0
args:
interval_width: 0.98
reader:
- # https://docs.victoriametrics.com/anomaly-detection/components/reader/#vm-reader
+ # {{% ref "./components/reader.md#vm-reader" %}}
datasource_url: "http://victoriametrics:8428/" # [YOUR_DATASOURCE_URL]
sampling_period: "1m"
queries:
- # define your queries with MetricsQL - https://docs.victoriametrics.com/metricsql/
+ # define your queries with MetricsQL - {{% ref "../../MetricsQL.md" %}}
cache: "sum(rate(vm_cache_entries))"
writer:
- # https://docs.victoriametrics.com/anomaly-detection/components/writer/#vm-writer
+ # {{% ref "./components/writer.md#vm-writer" %}}
datasource_url: "http://victoriametrics:8428/" # [YOUR_DATASOURCE_URL]
```
Next steps:
-- Define how often to run and make inferences in the [scheduler](/anomaly-detection/components/scheduler/) section of a config file.
-- Setup the datasource to read data from in the [reader](/anomaly-detection/components/reader/) section.
-- Specify where and how to store anomaly detection metrics in the [writer](/anomaly-detection/components/writer/) section.
-- Configure built-in models parameters according to your needs in the [models](/anomaly-detection/components/models/) section.
-- Integrate your [custom models](/anomaly-detection/components/models/#custom-model-guide) with `vmanomaly`.
-- Define queries for input data using [MetricsQL](https://docs.victoriametrics.com/metricsql/).
+- Define how often to run and make inferences in the [scheduler](./components/scheduler.md) section of a config file.
+- Setup the datasource to read data from in the [reader](./components/reader.md) section.
+- Specify where and how to store anomaly detection metrics in the [writer](./components/writer.md) section.
+- Configure built-in models parameters according to your needs in the [models](./components/models.md) section.
+- Integrate your [custom models](./components/models.md#custom-model-guide) with `vmanomaly`.
+- Define queries for input data using [MetricsQL](../../MetricsQL.md).
## Check also
Here are other materials that you might find useful:
-- [Guide: Anomaly Detection and Alerting Setup](/anomaly-detection/guides/guide-vmanomaly-vmalert/)
-- [FAQ](/anomaly-detection/faq/)
-- [Changelog](/anomaly-detection/changelog/)
-- [Anomaly Detection Blog](https://victoriametrics.com/blog/tags/anomaly-detection/)
\ No newline at end of file
+- [Guide: Anomaly Detection and Alerting Setup](./guides/guide-vmanomaly-vmalert/README.md)
+- [FAQ](./FAQ.md)
+- [Changelog](./CHANGELOG.md)
+- [Anomaly Detection Blog](https://victoriametrics.com/blog/tags/anomaly-detection/)
diff --git a/docs/anomaly-detection/README.md b/docs/anomaly-detection/README.md
index ef24abc35..9177c1b27 100644
--- a/docs/anomaly-detection/README.md
+++ b/docs/anomaly-detection/README.md
@@ -1,28 +1,28 @@
-In the dynamic and complex world of system monitoring, VictoriaMetrics Anomaly Detection, being a part of our [Enterprise offering](https://victoriametrics.com/products/enterprise/), stands as a pivotal tool for achieving advanced observability. It empowers SREs and DevOps teams by automating the intricate task of identifying abnormal behavior in time-series data. It goes beyond traditional threshold-based alerting, utilizing machine learning techniques to not only detect anomalies but also minimize false positives, thus reducing alert fatigue. By providing simplified alerting mechanisms atop of [unified anomaly scores](/anomaly-detection/components/models.html#vmanomaly-output), it enables teams to spot and address potential issues faster, ensuring system reliability and operational efficiency.
+In the dynamic and complex world of system monitoring, VictoriaMetrics Anomaly Detection, being a part of our [Enterprise offering](https://victoriametrics.com/products/enterprise/), stands as a pivotal tool for achieving advanced observability. It empowers SREs and DevOps teams by automating the intricate task of identifying abnormal behavior in time-series data. It goes beyond traditional threshold-based alerting, utilizing machine learning techniques to not only detect anomalies but also minimize false positives, thus reducing alert fatigue. By providing simplified alerting mechanisms atop of [unified anomaly scores](./components/models.md#vmanomaly-output), it enables teams to spot and address potential issues faster, ensuring system reliability and operational efficiency.
## Practical Guides and Installation
Begin your VictoriaMetrics Anomaly Detection journey with ease using our guides and installation instructions:
-- **Quickstart**: Check out how to get `vmanomaly` up and running [here](/anomaly-detection/QuickStart.html).
-- **Overview**: Find out how `vmanomaly` service operates [here](/anomaly-detection/Overview.html)
-- **Integration**: Integrate anomaly detection into your observability ecosystem. Get started [here](/anomaly-detection/guides/guide-vmanomaly-vmalert.html).
-- **Anomaly Detection Presets**: Enable anomaly detection on predefined set of indicators, that require frequently changing static thresholds for alerting. Find more information [here](/anomaly-detection/presets/).
+- **Quickstart**: Check out how to get `vmanomaly` up and running [here](./QuickStart.md).
+- **Overview**: Find out how `vmanomaly` service operates [here](./Overview.md)
+- **Integration**: Integrate anomaly detection into your observability ecosystem. Get started [here](./guides/guide-vmanomaly-vmalert/README.md).
+- **Anomaly Detection Presets**: Enable anomaly detection on predefined set of indicators, that require frequently changing static thresholds for alerting. Find more information [here](./Presets.md).
- **Installation Options**: Select the method that aligns with your technical requirements:
- - **Docker Installation**: Suitable for containerized environments. See [Docker guide](/anomaly-detection/Overview.html#run-vmanomaly-docker-container).
+ - **Docker Installation**: Suitable for containerized environments. See [Docker guide](./Overview.md#run-vmanomaly-docker-container).
- **Helm Chart Installation**: Appropriate for those using Kubernetes. See our [Helm charts](https://github.com/VictoriaMetrics/helm-charts/tree/master/charts/victoria-metrics-anomaly).
-> **Note**: starting from [v1.5.0](./CHANGELOG.md#v150) `vmanomaly` requires a [license key](/anomaly-detection/Overview.html#licensing) to run. You can obtain a trial license key [**here**](https://victoriametrics.com/products/enterprise/trial/).
+> **Note**: starting from [v1.5.0](./CHANGELOG.md#v150) `vmanomaly` requires a [license key](./Overview.md#licensing) to run. You can obtain a trial license key [**here**](https://victoriametrics.com/products/enterprise/trial/).
## Key Components
Explore the integral components that configure VictoriaMetrics Anomaly Detection:
-* [Explore components and their interation](/anomaly-detection/components)
- - [Models](/anomaly-detection/components/models)
- - [Reader](/anomaly-detection/components/reader)
- - [Scheduler](/anomaly-detection/components/scheduler)
- - [Writer](/anomaly-detection/components/writer)
- - [Monitoring](/anomaly-detection/components/monitoring)
+* [Explore components and their interation](./components/README.md)
+ - [Models](./components/models.md)
+ - [Reader](./components/reader.md)
+ - [Scheduler](./components/scheduler.md)
+ - [Writer](./components/writer.md)
+ - [Monitoring](./components/monitoring.md)
## Deep Dive into Anomaly Detection
Enhance your knowledge with our handbook on Anomaly Detection & Root Cause Analysis and stay updated:
@@ -35,7 +35,7 @@ Enhance your knowledge with our handbook on Anomaly Detection & Root Cause Analy
## Frequently Asked Questions (FAQ)
Got questions about VictoriaMetrics Anomaly Detection? Chances are, we've got the answers ready for you.
-Dive into [our FAQ section](/anomaly-detection/FAQ) to find responses to common questions.
+Dive into [our FAQ section](./FAQ.md) to find responses to common questions.
## Get in Touch
We are eager to connect with you and adapt our solutions to your specific needs. Here's how you can engage with us:
diff --git a/docs/anomaly-detection/components/README.md b/docs/anomaly-detection/components/README.md
index 663f274cf..e26547be6 100644
--- a/docs/anomaly-detection/components/README.md
+++ b/docs/anomaly-detection/components/README.md
@@ -1,28 +1,28 @@
-This chapter describes different components, that correspond to respective sections of a config to launch VictoriaMetrics Anomaly Detection (or simply [`vmanomaly`](/anomaly-detection/overview.html)) service:
+This chapter describes different components, that correspond to respective sections of a config to launch VictoriaMetrics Anomaly Detection (or simply [`vmanomaly`](../Overview.md)) service:
-- [Model(s) section](models.html) - Required
-- [Reader section](reader.html) - Required
-- [Scheduler(s) section](scheduler.html) - Required
-- [Writer section](writer.html) - Required
-- [Monitoring section](monitoring.html) - Optional
+- [Model(s) section](./models.md) - Required
+- [Reader section](./reader.md) - Required
+- [Scheduler(s) section](./scheduler.md) - Required
+- [Writer section](./writer.md) - Required
+- [Monitoring section](./monitoring.md) - Optional
-> **Note**: starting from [v1.7.0](/anomaly-detection/CHANGELOG#v172), once the service starts, automated config validation is performed. Please see container logs for errors that need to be fixed to create fully valid config, visiting sections above for examples and documentation.
+> **Note**: starting from [v1.7.0](../CHANGELOG.md#v172), once the service starts, automated config validation is performed. Please see container logs for errors that need to be fixed to create fully valid config, visiting sections above for examples and documentation.
-> **Note**: starting from [v1.13.0](/anomaly-detection/CHANGELOG#v1130), components' class can be referenced by a short alias instead of a full class path - i.e. `model.zscore.ZscoreModel` becomes `zscore`, `reader.vm.VmReader` becomes `vm`, `scheduler.periodic.PeriodicScheduler` becomes `periodic`, etc. Please see according sections for the details.
+> **Note**: starting from [v1.13.0](../CHANGELOG.md#v1130), components' class can be referenced by a short alias instead of a full class path - i.e. `model.zscore.ZscoreModel` becomes `zscore`, `reader.vm.VmReader` becomes `vm`, `scheduler.periodic.PeriodicScheduler` becomes `periodic`, etc. Please see according sections for the details.
-> **Note:** Starting from [v1.13.0](/anomaly-detection/CHANGELOG#v1130) `preset` modes are available for `vmanomaly`. Please find the guide [here](/anomaly-detection/presets/).
+> **Note:** Starting from [v1.13.0](../CHANGELOG.md#v1130) `preset` modes are available for `vmanomaly`. Please find the guide [here](../Presets.md).
Below, you will find an example illustrating how the components of `vmanomaly` interact with each other and with a single-node VictoriaMetrics setup.
-> **Note**: [Reader](/anomaly-detection/components/reader.html#vm-reader) and [Writer](/anomaly-detection/components/writer.html#vm-writer) also support [multitenancy](/Cluster-VictoriaMetrics.html#multitenancy), so you can read/write from/to different locations - see `tenant_id` param description.
+> **Note**: [Reader](./reader.md#vm-reader) and [Writer](./writer.md#vm-writer) also support [multitenancy](../../Cluster-VictoriaMetrics.md#multitenancy), so you can read/write from/to different locations - see `tenant_id` param description.
-
+
+{width="800px"}
-Here's a minimalistic full config example, demonstrating many-to-many configuration (actual for [latest version](/anomaly-detection/CHANGELOG/)):
+Here's a minimalistic full config example, demonstrating many-to-many configuration (actual for [latest version](../CHANGELOG.md)):
```yaml
-# how and when to run the models is defined by schedulers
-# https://docs.victoriametrics.com/anomaly-detection/components/scheduler/
+{{% ref "./scheduler.md" %}}
schedulers:
periodic_1d: # alias
class: 'periodic' # scheduler class
@@ -36,7 +36,7 @@ schedulers:
fit_window: "7d"
# what model types and with what hyperparams to run on your data
-# https://docs.victoriametrics.com/anomaly-detection/components/models/
+# {{% ref "./models.md" %}}
models:
zscore: # alias
class: 'zscore' # model class
@@ -53,7 +53,7 @@ models:
interval_width: 0.98
# where to read data from
-# https://docs.victoriametrics.com/anomaly-detection/components/reader/
+# {{% ref "./reader.md" %}}
reader:
datasource_url: "http://victoriametrics:8428/"
tenant_id: "0:0"
@@ -64,12 +64,12 @@ reader:
host_network_receive_errors: 'rate(node_network_receive_errs_total[3m]) / rate(node_network_receive_packets_total[3m])'
# where to write data to
-# https://docs.victoriametrics.com/anomaly-detection/components/writer/
+# {{% ref "./writer.md" %}}
writer:
datasource_url: "http://victoriametrics:8428/"
# enable self-monitoring in pull and/or push mode
-# https://docs.victoriametrics.com/anomaly-detection/components/monitoring/
+# {{% ref "./monitoring.md" %}}
monitoring:
pull: # Enable /metrics endpoint.
addr: "0.0.0.0"
diff --git a/docs/anomaly-detection/components/models.md b/docs/anomaly-detection/components/models.md
index 961c42fc1..25f72778d 100644
--- a/docs/anomaly-detection/components/models.md
+++ b/docs/anomaly-detection/components/models.md
@@ -13,15 +13,12 @@ aliases:
- /anomaly-detection/components/models/custom_model.html
- /anomaly-detection/components/models/models.html
---
-
-# Models
-
-This section describes `Models` component of VictoriaMetrics Anomaly Detection (or simply [`vmanomaly`](/anomaly-detection/overview/)) and the guide of how to define a respective section of a config to launch the service.
+This section describes `Models` component of VictoriaMetrics Anomaly Detection (or simply [`vmanomaly`](../Overview.md)) and the guide of how to define a respective section of a config to launch the service.
- `vmanomaly` includes various [built-in models](#built-in-models).
- you can also integrate your custom model - see [custom model](#custom-model-guide).
-> **Note: Starting from [v1.10.0](/anomaly-detection/changelog#v1100) model section in config supports multiple models via aliasing. 
+
+{width="800px"}
When set to `above_expected`, anomalies are tracked only when `y > yhat`.
*Example metrics*: Error rate, response time, page load time, number of failed transactions - metrics where *lower values are better*, so **higher** values are typically tracked.
-
+
+{width="800px"}
When set to `below_expected`, anomalies are tracked only when `y < yhat`.
*Example metrics*: Service Level Agreement (SLA) compliance, conversion rate, Customer Satisfaction Score (CSAT) - metrics where *higher values are better*, so **lower** values are typically tracked.
-
+
+{width="800px"}
Config with a split example:
@@ -185,7 +185,7 @@ reader:
### Minimal deviation from expected
-Introduced in [v1.13.0](/anomaly-detection/CHANGELOG/#1130), the `min_dev_from_expected` argument is designed to **reduce [false positives](https://victoriametrics.com/blog/victoriametrics-anomaly-detection-handbook-chapter-1/#false-positive)** in scenarios where deviations between the actual value (`y`) and the expected value (`yhat`) are **relatively** high. Such deviations can cause models to generate high [anomaly scores](/anomaly-detection/faq/#what-is-anomaly-score). However, these deviations may not be significant enough in **absolute values** from a business perspective to be considered anomalies. This parameter ensures that anomaly scores for data points where `|y - yhat| < min_dev_from_expected` are explicitly set to 0. By default, if this parameter is not set, it behaves as `min_dev_from_expected=0` to maintain backward compatibility.
+Introduced in [v1.13.0](../CHANGELOG.md#1130), the `min_dev_from_expected` argument is designed to **reduce [false positives](https://victoriametrics.com/blog/victoriametrics-anomaly-detection-handbook-chapter-1/#false-positive)** in scenarios where deviations between the actual value (`y`) and the expected value (`yhat`) are **relatively** high. Such deviations can cause models to generate high [anomaly scores](../FAQ.md#what-is-anomaly-score). However, these deviations may not be significant enough in **absolute values** from a business perspective to be considered anomalies. This parameter ensures that anomaly scores for data points where `|y - yhat| < min_dev_from_expected` are explicitly set to 0. By default, if this parameter is not set, it behaves as `min_dev_from_expected=0` to maintain backward compatibility.
> **Note**: `min_dev_from_expected` must be >= 0. The higher the value of `min_dev_from_expected`, the fewer data points will be available for anomaly detection, and vice versa.
@@ -193,11 +193,14 @@ Introduced in [v1.13.0](/anomaly-detection/CHANGELOG/#1130), the `min_dev_from_e
Visualizations below demonstrate this concept; the green zone defined as the `[yhat - min_dev_from_expected, yhat + min_dev_from_expected]` range excludes actual data points (`y`) from generating anomaly scores if they fall within that range.
-
+
+{width="800px"}
-
+
+{width="800px"}
-
+
+{width="800px}
Example config of how to use this param based on query results:
@@ -238,7 +241,7 @@ Each of these models can also be
For a univariate type, **one separate model** is fit/used for inference per **each time series**, defined in its [queries](#queries) arg.
-For example, if you have some **univariate** model, defined to use 3 [MetricQL queries](https://docs.victoriametrics.com/metricsql/), each returning 5 time series, there will be 3*5=15 models created in total. Each such model produce **individual [output](#vmanomaly-output)** for each of time series.
+For example, if you have some **univariate** model, defined to use 3 [MetricQL queries](../../MetricsQL.md), each returning 5 time series, there will be 3*5=15 models created in total. Each such model produce **individual [output](#vmanomaly-output)** for each of time series.
If during an inference, you got a series having **new labelset** (not present in any of fitted models), the inference will be skipped until you get a model, trained particularly for such labelset during forthcoming re-fit step.
@@ -247,13 +250,14 @@ If during an inference, you got a series having **new labelset** (not present in
**Examples:** [Prophet](#prophet), [Holt-Winters](#holt-winters)
-
+
+{width="800px"}
### Multivariate Models
For a multivariate type, **one shared model** is fit/used for inference on **all time series** simultaneously, defined in its [queries](#queries) arg.
-For example, if you have some **multivariate** model to use 3 [MetricQL queries](https://docs.victoriametrics.com/metricsql/), each returning 5 time series, there will be one shared model created in total. Once fit, this model will expect **exactly 15 time series with exact same labelsets as an input**. This model will produce **one shared [output](#vmanomaly-output)**.
+For example, if you have some **multivariate** model to use 3 [MetricQL queries](../../MetricsQL.md), each returning 5 time series, there will be one shared model created in total. Once fit, this model will expect **exactly 15 time series with exact same labelsets as an input**. This model will produce **one shared [output](#vmanomaly-output)**.
If during an inference, you got a **different amount of series** or some series having a **new labelset** (not present in any of fitted models), the inference will be skipped until you get a model, trained particularly for such labelset during forthcoming re-fit step.
@@ -262,7 +266,8 @@ If during an inference, you got a **different amount of series** or some series
**Examples:** [IsolationForest](#isolation-forest-multivariate)
-
+
+{width="800px"}
### Rolling Models
@@ -270,16 +275,17 @@ A rolling model is a model that, once trained, **cannot be (naturally) used to m
An instance of rolling model is **simultaneously fit and used for inference** during its `infer` method call.
-As a result, such model instances are **not stored** between consecutive re-fit calls (defined by `fit_every` [arg](/anomaly-detection/components/scheduler/?highlight=fit_every#periodic-scheduler) in `PeriodicScheduler`), leading to **lower RAM** consumption.
+As a result, such model instances are **not stored** between consecutive re-fit calls (defined by `fit_every` [arg](./scheduler.md#periodic-scheduler) in `PeriodicScheduler`), leading to **lower RAM** consumption.
Such models put **more pressure** on your reader's source, i.e. if your model should be fit on large amount of data (say, 14 days with 1-minute resolution) and at the same time you have **frequent inference** (say, once per minute) on new chunks of data - that's because such models require (fit + infer) window of data to be fit first to be used later in each inference call.
-> **Note**: Rolling models require `fit_every` to be set equal to `infer_every` in your [PeriodicScheduler](/anomaly-detection/components/scheduler/?highlight=fit_every#periodic-scheduler).
+> **Note**: Rolling models require `fit_every` to be set equal to `infer_every` in your [PeriodicScheduler](./scheduler.md#periodic-scheduler).
**Examples:** [RollingQuantile](#rolling-quantile)
-
+
+{width="800px"}
### Non-Rolling Models
@@ -291,12 +297,13 @@ Such models put **less pressure** on your reader's source, i.e. if you fit on la
> **Note**: However, it's still highly recommended, to keep your model up-to-date with tendencies found in your data as it evolves in time.
-Produced model instances are **stored in-memory** between consecutive re-fit calls (defined by `fit_every` [arg](/anomaly-detection/components/scheduler/?highlight=fit_every#periodic-scheduler) in `PeriodicScheduler`), leading to **higher RAM** consumption.
+Produced model instances are **stored in-memory** between consecutive re-fit calls (defined by `fit_every` [arg](./scheduler#periodic-scheduler) in `PeriodicScheduler`), leading to **higher RAM** consumption.
**Examples:** [Prophet](#prophet)
-
+
+{width="800px}
## Built-in Models
@@ -322,12 +329,12 @@ VM Anomaly Detection (`vmanomaly` hereinafter) models support 2 groups of parame
### AutoTuned
-Tuning hyperparameters of a model can be tricky and often requires in-depth knowledge of Machine Learning. `AutoTunedModel` is designed specifically to take the cognitive load off the user - specify as little as `anomaly_percentage` param from `(0, 0.5)` interval and `tuned_model_class` (i.e. [`model.zscore.ZscoreModel`](/anomaly-detection/components/models/#z-score)) to get it working with best settings that match your data.
+Tuning hyperparameters of a model can be tricky and often requires in-depth knowledge of Machine Learning. `AutoTunedModel` is designed specifically to take the cognitive load off the user - specify as little as `anomaly_percentage` param from `(0, 0.5)` interval and `tuned_model_class` (i.e. [`model.zscore.ZscoreModel`](./models.md#z-score)) to get it working with best settings that match your data.
*Parameters specific for vmanomaly*:
-* `class` (string) - model class name `"model.auto.AutoTunedModel"` (or `auto` starting from [v1.13.0](/anomaly-detection/CHANGELOG/#1130) with class alias support)
-* `tuned_class_name` (string) - Built-in model class to tune, i.e. `model.zscore.ZscoreModel` (or `zscore` starting from [v1.13.0](/anomaly-detection/CHANGELOG/#1130) with class alias support).
+* `class` (string) - model class name `"model.auto.AutoTunedModel"` (or `auto` starting from [v1.13.0](../CHANGELOG.md#1130) with class alias support)
+* `tuned_class_name` (string) - Built-in model class to tune, i.e. `model.zscore.ZscoreModel` (or `zscore` starting from [v1.13.0](../CHANGELOG.md#1130) with class alias support).
* `optimization_params` (dict) - Optimization parameters for unsupervised model tuning. Control % of found anomalies, as well as a tradeoff between time spent and the accuracy. The more `timeout` and `n_trials` are, the better model configuration can be found for `tuned_class_name`, but the longer it takes and vice versa. Set `n_jobs` to `-1` to use all the CPUs available, it makes sense if only you have a big dataset to train on during `fit` calls, otherwise overhead isn't worth it.
- `anomaly_percentage` (float) - expected percentage of anomalies that can be seen in training data, from (0, 0.5) interval.
- `seed` (int) - Random seed for reproducibility and deterministic nature of underlying optimizations.
@@ -335,7 +342,8 @@ Tuning hyperparameters of a model can be tricky and often requires in-depth know
- `n_trials` (int) - How many trials to sample from hyperparameter search space. The higher, the longer it takes but the better the results can be. Defaults to 128.
- `timeout` (float) - How many seconds in total can be spent on each model to tune hyperparameters. The higher, the longer it takes, allowing to test more trials out of defined `n_trials`, but the better the results can be.
-
+
+{width="800px"}
```yaml
# ...
@@ -356,7 +364,7 @@ models:
> **Note**: There are some expected limitations of Autotune mode:
> - It can't be made on your [custom model](#custom-model-guide).
> - It can't be applied to itself (like `tuned_class_name: 'model.auto.AutoTunedModel'`)
-> - `AutoTunedModel` can't be used on [rolling models](/anomaly-detection/components/models/#rolling-models) like [`RollingQuantile`](/anomaly-detection/components/models/#rolling-quantile) in combination with [on-disk model storage mode](/anomaly-detection/faq/#resource-consumption-of-vmanomaly), as the rolling models exists only during `infer` calls and aren't persisted neither in RAM, nor on disk.
+> - `AutoTunedModel` can't be used on [rolling models](./models.md#rolling-models) like [`RollingQuantile`](./models.md#rolling-quantile) in combination with [on-disk model storage mode](../FAQ.md#resource-consumption-of-vmanomaly), as the rolling models exists only during `infer` calls and aren't persisted neither in RAM, nor on disk.
### [Prophet](https://facebook.github.io/prophet/)
@@ -364,7 +372,7 @@ Here we utilize the Facebook Prophet implementation, as detailed in their [libra
*Parameters specific for vmanomaly*:
-* `class` (string) - model class name `"model.prophet.ProphetModel"` (or `prophet` starting from [v1.13.0](/anomaly-detection/CHANGELOG/#1130) with class alias support)
+* `class` (string) - model class name `"model.prophet.ProphetModel"` (or `prophet` starting from [v1.13.0](../CHANGELOG.md#1130) with class alias support)
* `seasonalities` (list[dict], optional) - Extra seasonalities to pass to Prophet. See [`add_seasonality()`](https://facebook.github.io/prophet/docs/seasonality,_holiday_effects,_and_regressors.html#modeling-holidays-and-special-events:~:text=modeling%20the%20cycle-,Specifying,-Custom%20Seasonalities) Prophet param.
**Note**: Apart from standard `vmanomaly` output, Prophet model can provide [additional metrics](#additional-output-metrics-produced-by-fb-prophet).
@@ -404,7 +412,7 @@ Resulting metrics of the model are described [here](#vmanomaly-output)
### [Z-score](https://en.wikipedia.org/wiki/Standard_score)
*Parameters specific for vmanomaly*:
-* `class` (string) - model class name `"model.zscore.ZscoreModel"` (or `zscore` starting from [v1.13.0](/anomaly-detection/CHANGELOG/#1130) with class alias support)
+* `class` (string) - model class name `"model.zscore.ZscoreModel"` (or `zscore` starting from [v1.13.0](../CHANGELOG.md#1130) with class alias support)
* `z_threshold` (float, optional) - [standard score](https://en.wikipedia.org/wiki/Standard_score) for calculation boundaries and anomaly score. Defaults to `2.5`.
*Config Example*
@@ -425,7 +433,7 @@ Here we use Holt-Winters Exponential Smoothing implementation from `statsmodels`
*Parameters specific for vmanomaly*:
-* `class` (string) - model class name `"model.holtwinters.HoltWinters"` (or `holtwinters` starting from [v1.13.0](/anomaly-detection/CHANGELOG/#1130) with class alias support)
+* `class` (string) - model class name `"model.holtwinters.HoltWinters"` (or `holtwinters` starting from [v1.13.0](../CHANGELOG.md#1130) with class alias support)
* `frequency` (string) - Must be set equal to sampling_period. Model needs to know expected data-points frequency (e.g. '10m'). If omitted, frequency is guessed during fitting as **the median of intervals between fitting data timestamps**. During inference, if incoming data doesn't have the same frequency, then it will be interpolated. E.g. data comes at 15 seconds resolution, and our resample_freq is '1m'. Then fitting data will be downsampled to '1m' and internal model is trained at '1m' intervals. So, during inference, prediction data would be produced at '1m' intervals, but interpolated to "15s" to match with expected output, as output data must have the same timestamps. As accepted by pandas.Timedelta (e.g. '5m').
@@ -467,7 +475,7 @@ The MAD model is a robust method for anomaly detection that is *less sensitive*
*Parameters specific for vmanomaly*:
-* `class` (string) - model class name `"model.mad.MADModel"` (or `mad` starting from [v1.13.0](/anomaly-detection/CHANGELOG/#1130) with class alias support)
+* `class` (string) - model class name `"model.mad.MADModel"` (or `mad` starting from [v1.13.0](../CHANGELOG.md#1130) with class alias support)
* `threshold` (float, optional) - The threshold multiplier for the MAD to determine anomalies. Defaults to `2.5`. Higher values will identify fewer points as anomalies.
*Config Example*
@@ -487,7 +495,7 @@ Resulting metrics of the model are described [here](#vmanomaly-output).
*Parameters specific for vmanomaly*:
-* `class` (string) - model class name `"model.rolling_quantile.RollingQuantileModel"` (or `rolling_quantile` starting from [v1.13.0](/anomaly-detection/CHANGELOG/#1130) with class alias support)
+* `class` (string) - model class name `"model.rolling_quantile.RollingQuantileModel"` (or `rolling_quantile` starting from [v1.13.0](../CHANGELOG.md#1130) with class alias support)
* `quantile` (float) - quantile value, from 0.5 to 1.0. This constraint is implied by 2-sided confidence interval.
* `window_steps` (integer) - size of the moving window. (see 'sampling_period')
@@ -508,7 +516,7 @@ Here we use Seasonal Decompose implementation from `statsmodels` [library](https
*Parameters specific for vmanomaly*:
-* `class` (string) - model class name `"model.std.StdModel"` (or `std` starting from [v1.13.0](/anomaly-detection/CHANGELOG/#1130) with class alias support)
+* `class` (string) - model class name `"model.std.StdModel"` (or `std` starting from [v1.13.0](../CHANGELOG.md#1130) with class alias support)
* `period` (integer) - Number of datapoints in one season.
* `z_threshold` (float, optional) - [standard score](https://en.wikipedia.org/wiki/Standard_score) for calculating boundaries to define anomaly score. Defaults to `2.5`.
@@ -541,11 +549,11 @@ Here we use Isolation Forest implementation from `scikit-learn` [library](https:
*Parameters specific for vmanomaly*:
-* `class` (string) - model class name `"model.isolation_forest.IsolationForestMultivariateModel"` (or `isolation_forest_multivariate` starting from [v1.13.0](/anomaly-detection/CHANGELOG/#1130) with class alias support)
+* `class` (string) - model class name `"model.isolation_forest.IsolationForestMultivariateModel"` (or `isolation_forest_multivariate` starting from [v1.13.0](../CHANGELOG.md#1130) with class alias support)
* `contamination` (float or string, optional) - The amount of contamination of the data set, i.e. the proportion of outliers in the data set. Used when fitting to define the threshold on the scores of the samples. Default value - "auto". Should be either `"auto"` or be in the range (0.0, 0.5].
-* `seasonal_features` (list of string) - List of seasonality to encode through [cyclical encoding](https://towardsdatascience.com/cyclical-features-encoding-its-about-time-ce23581845ca), i.e. `dow` (day of week). **Introduced in [1.12.0](/anomaly-detection/CHANGELOG/#v1120)**.
+* `seasonal_features` (list of string) - List of seasonality to encode through [cyclical encoding](https://towardsdatascience.com/cyclical-features-encoding-its-about-time-ce23581845ca), i.e. `dow` (day of week). **Introduced in [1.12.0](../CHANGELOG.md#v1120)**.
- Empty by default for backward compatibility.
- Example: `seasonal_features: ['dow', 'hod']`.
- Supported seasonalities:
@@ -601,12 +609,12 @@ The default metrics produced by `vmanomaly` include:
## vmanomaly monitoring metrics
-Each model exposes [several monitoring metrics](/anomaly-detection/components/monitoring/#models-behaviour-metrics) to its `health_path` endpoint:
+Each model exposes [several monitoring metrics](./monitoring.md#models-behaviour-metrics) to its `health_path` endpoint:
## Custom Model Guide
-Apart from `vmanomaly` [built-in models](/anomaly-detection/components/models/#built-in-models), users can create their own custom models for anomaly detection.
+Apart from `vmanomaly` [built-in models](./models.md#built-in-models), users can create their own custom models for anomaly detection.
Here in this guide, we will
- Make a file containing our custom model definition
@@ -698,8 +706,8 @@ class CustomModel(Model):
### 2. Configuration file
Next, we need to create `config.yaml` file with `vmanomaly` configuration and model input parameters.
-In the config file's `models` section we need to set our model class to `model.custom.CustomModel` (or `custom` starting from [v1.13.0](/anomaly-detection/CHANGELOG/#1130) with class alias support) and define all parameters used in `__init__` method.
-You can find out more about configuration parameters in `vmanomaly` [config docs](/anomaly-detection/components/).
+In the config file's `models` section we need to set our model class to `model.custom.CustomModel` (or `custom` starting from [v1.13.0](../CHANGELOG.md#1130) with class alias support) and define all parameters used in `__init__` method.
+You can find out more about configuration parameters in `vmanomaly` [config docs](./README.md).
```yaml
schedulers:
@@ -762,7 +770,7 @@ victoriametrics/vmanomaly:latest /config.yaml \
--license-file=/license
```
-Please find more detailed instructions (license, etc.) [here](/anomaly-detection/overview.html#run-vmanomaly-docker-container)
+Please find more detailed instructions (license, etc.) [here](../Overview.md#run-vmanomaly-docker-container)
### Output
diff --git a/docs/anomaly-detection/components/monitoring.md b/docs/anomaly-detection/components/monitoring.md
index 27be41d0b..d7c4a879f 100644
--- a/docs/anomaly-detection/components/monitoring.md
+++ b/docs/anomaly-detection/components/monitoring.md
@@ -8,16 +8,13 @@ menu:
weight: 5
identifier: "vmanomaly-monitoring"
aliases:
- - /anomaly-detection/components/monitoring.html
+ - ./monitoring.html
---
-
-# Monitoring
-
-There are 2 models to monitor VictoriaMetrics Anomaly Detection behavior - [push](https://docs.victoriametrics.com/keyconcepts/#push-model) and [pull](https://docs.victoriametrics.com/keyconcepts/#pull-model). Parameters for each of them should be specified in the config file, `monitoring` section.
+There are 2 models to monitor VictoriaMetrics Anomaly Detection behavior - [push](../../keyConcepts.md#push-model) and [pull](../../keyConcepts.md#pull-model). Parameters for each of them should be specified in the config file, `monitoring` section.
## Pull Model Config parameters
-| Parameter | @@ -27,13 +24,25 @@ There are 2 models to monitor VictoriaMetrics Anomaly Detection behavior - [push|||||||
|---|---|---|---|---|---|---|---|
addr |
- "0.0.0.0" |
+ + +`addr` + | ++ +`"0.0.0.0"` + | Server IP Address | |||
port |
- 8080 |
+ + +`port` + | ++ +`8080` + | Port |
| Parameter | @@ -51,42 +60,84 @@ There are 2 models to monitor VictoriaMetrics Anomaly Detection behavior - [push|||||||
|---|---|---|---|---|---|---|---|
url |
+ + +`url` + | - | Link where to push metrics to. Example: "http://localhost:8480/" |
+ + +Link where to push metrics to. Example: `"http://localhost:8480/"` + | |||
tenant_id |
+ + +`tenant_id` + | - | Tenant ID for cluster version. Example: "0:0" |
+ + +Tenant ID for cluster version. Example: `"0:0"` + | |||
health_path |
- "health" |
- Deprecated since v1.8.0. Absolute, to override /health path |
+ + +`health_path` + | ++ +`"health"` + | ++ +Deprecated since [v1.8.0](../CHANGELOG.md#v180). Absolute, to override `/health` path + | ||
user |
+ + +`user` + | BasicAuth username | |||||
password |
+ + +`password` + | BasicAuth password | |||||
verify_tls |
- False |
+ + +`verify_tls` + | ++ +`False` + | Allows disabling TLS verification of the remote certificate. | |||
timeout |
- "5s" |
+ + +`timeout` + | ++ +`"5s"` + | Stop waiting for a response after a given number of seconds. | |||
extra_labels |
+ + +`extra_labels` + | Section for custom labels specified by user. |
| Metric | @@ -124,7 +175,10 @@ monitoring:|||||||
|---|---|---|---|---|---|---|---|
vmanomaly_start_time_seconds |
+ + +`vmanomaly_start_time_seconds` + | Gauge | vmanomaly start time in UNIX time |
| Metric | @@ -147,40 +201,76 @@ Label names [description](#labelnames)|||||
|---|---|---|---|---|---|
vmanomaly_model_runs |
+ + +`vmanomaly_model_runs` + | Counter | How many times models ran (per model) | -stage, query_key, model_alias, scheduler_alias, preset |
+ + +`stage, query_key, model_alias, scheduler_alias, preset` + |
vmanomaly_model_run_duration_seconds |
+ + +`vmanomaly_model_run_duration_seconds` + | Summary | How much time (in seconds) model invocations took | -stage, query_key, model_alias, scheduler_alias, preset |
+ + +`stage, query_key, model_alias, scheduler_alias, preset` + |
vmanomaly_model_datapoints_accepted |
+ + +`vmanomaly_model_datapoints_accepted` + | Counter | How many datapoints did models accept | -stage, query_key, model_alias, scheduler_alias, preset |
+ + +`stage, query_key, model_alias, scheduler_alias, preset` + |
vmanomaly_model_datapoints_produced |
+ + +`vmanomaly_model_datapoints_produced` + | Counter | How many datapoints were generated by models | -stage, query_key, model_alias, scheduler_alias, preset |
+ + +`stage, query_key, model_alias, scheduler_alias, preset` + |
vmanomaly_models_active |
+ + +`vmanomaly_models_active` + | Gauge | How many models are currently inferring | -query_key, model_alias, scheduler_alias, preset |
+ + +`query_key, model_alias, scheduler_alias, preset` + |
vmanomaly_model_runs_skipped |
+ + +`vmanomaly_model_runs_skipped` + | Counter | How many times a run was skipped (per model) | -stage, query_key, model_alias, scheduler_alias, preset |
+ + +`stage, query_key, model_alias, scheduler_alias, preset` + |
| Metric | @@ -199,40 +289,76 @@ Label names [description](#labelnames)|||||
|---|---|---|---|---|---|
vmanomaly_writer_request_duration_seconds |
+ + +`vmanomaly_writer_request_duration_seconds` + | Summary | How much time (in seconds) did requests to VictoriaMetrics take | -url, query_key |
+ + +`url, query_key` + |
vmanomaly_writer_response_count |
+ + +`vmanomaly_writer_response_count` + | Counter | Response code counts we got from VictoriaMetrics | -url, query_key, code |
+ + +`url, query_key, code` + |
vmanomaly_writer_sent_bytes |
+ + +`vmanomaly_writer_sent_bytes` + | Counter | How much bytes were sent to VictoriaMetrics | -url, query_key |
+ + +`url, query_key` + |
vmanomaly_writer_request_serialize_seconds |
+ + +`vmanomaly_writer_request_serialize_seconds` + | Summary | How much time (in seconds) did serializing take | -query_key |
+ + +`query_key` + |
vmanomaly_writer_datapoints_sent |
+ + +`vmanomaly_writer_datapoints_sent` + | Counter | How many datapoints were sent to VictoriaMetrics | -query_key |
+ + +`query_key` + |
vmanomaly_writer_timeseries_sent |
+ + +`vmanomaly_writer_timeseries_sent` + | Counter | How many timeseries were sent to VictoriaMetrics | -query_key |
+ + +`query_key` + |
| Metric | @@ -251,57 +377,87 @@ Label names [description](#labelnames)|||||
|---|---|---|---|---|---|
vmanomaly_reader_request_duration_seconds |
+ + +`vmanomaly_reader_request_duration_seconds` + | Summary | How much time (in seconds) did queries to VictoriaMetrics take | -url, query_key |
+ + +`url, query_key` + |
vmanomaly_reader_response_count |
+ + +`vmanomaly_reader_response_count` + | Counter | Response code counts we got from VictoriaMetrics | -url, query_key, code |
+ + +`url, query_key, code` + |
vmanomaly_reader_received_bytes |
+ + +`vmanomaly_reader_received_bytes` + | Counter | How much bytes were received in responses | -query_key |
+ + +`query_key` + |
vmanomaly_reader_response_parsing_seconds |
+ + +`vmanomaly_reader_response_parsing_seconds` + | Summary | How much time (in seconds) did parsing take for each step | -step |
+ + +`step` + |
vmanomaly_reader_timeseries_received |
+ + +`vmanomaly_reader_timeseries_received` + | Counter | How many timeseries were received from VictoriaMetrics | -query_key |
+ + +`query_key` + |
vmanomaly_reader_datapoints_received |
+ + +`vmanomaly_reader_datapoints_received` + | Counter | How many rows were received from VictoriaMetrics | -query_key |
+ + +`query_key` + |
stage - stage of model - 'fit', 'infer' or 'fit_infer' for models that do it simultaneously, see [model types](/anomaly-detection/components/models/#model-types).
-query_key - query alias from [`reader`](/anomaly-detection/components/reader.html) config section.
-
-model_alias - model alias from [`models`](/anomaly-detection/components/models.html) config section. **Introduced in [v1.10.0](/anomaly-detection/changelog/#v1100).**
-
-scheduler_alias - scheduler alias from [`schedulers`](anomaly-detection/components/scheduler/) config section. **Introduced in [v1.11.0](/anomaly-detection/changelog/#v1110).**
-
-preset - preset alias for forthcoming `preset` section compatibility. **Introduced in [v1.12.0](/anomaly-detection/changelog/#v1120).**
-
-url - writer or reader url endpoint.
-
-code - response status code or `connection_error`, `timeout`.
-
-step - json or dataframe reading step.
+* `stage` - stage of model - 'fit', 'infer' or 'fit_infer' for models that do it simultaneously, see [model types](./models/#model-types).
+* `query_key` - query alias from [`reader`](./reader.md) config section.
+* `model_alias` - model alias from [`models`](./models.md) config section. **Introduced in [v1.10.0](../CHANGELOG.md#v1100).**
+* `scheduler_alias` - scheduler alias from [`schedulers`](./scheduler.md) config section. **Introduced in [v1.11.0](../CHANGELOG.md#v1110).**
+* `preset` - preset alias for forthcoming `preset` section compatibility. **Introduced in [v1.12.0](../CHANGELOG.md#v1120).**
+* `url` - writer or reader url endpoint.
+* `code` - response status code or `connection_error`, `timeout`.
+* `step` - json or dataframe reading step.
diff --git a/docs/anomaly-detection/components/reader.md b/docs/anomaly-detection/components/reader.md
index 666d46b0b..4991eab92 100644
--- a/docs/anomaly-detection/components/reader.md
+++ b/docs/anomaly-detection/components/reader.md
@@ -9,14 +9,11 @@ menu:
aliases:
- /anomaly-detection/components/reader.html
---
-
-# Reader
-
-VictoriaMetrics Anomaly Detection (`vmanomaly`) primarily uses [VmReader](#vm-reader) to ingest data. This reader focuses on fetching time-series data directly from VictoriaMetrics with the help of powerful [MetricsQL](https://docs.victoriametrics.com/metricsql/) expressions for aggregating, filtering and grouping your data, ensuring seamless integration and efficient data handling.
+VictoriaMetrics Anomaly Detection (`vmanomaly`) primarily uses [VmReader](#vm-reader) to ingest data. This reader focuses on fetching time-series data directly from VictoriaMetrics with the help of powerful [MetricsQL](../../MetricsQL.md) expressions for aggregating, filtering and grouping your data, ensuring seamless integration and efficient data handling.
Future updates will introduce additional readers, expanding the range of data sources `vmanomaly` can work with.
@@ -25,7 +22,7 @@ Future updates will introduce additional readers, expanding the range of data so
### Config parameters
-| Parameter | @@ -35,69 +32,186 @@ Future updates will introduce additional readers, expanding the range of data so|||||
|---|---|---|---|---|---|
class |
- "reader.vm.VmReader" (or "vm" starting from v1.13.0) |
- Name of the class needed to enable reading from VictoriaMetrics or Prometheus. VmReader is the default option, if not specified. | ++ +`class` + | ++ +`reader.vm.VmReader` (or `vm` starting from [v1.13.0](../CHANGELOG.md#v1130)) + | ++ +Name of the class needed to enable reading from VictoriaMetrics or Prometheus. VmReader is the default option, if not specified. + |
queries |
- "ingestion_rate: 'sum(rate(vm_rows_inserted_total[5m])) by (type) > 0'" |
- PromQL/MetricsQL query to select data in format: QUERY_ALIAS: "QUERY". As accepted by "/query_range?query=%s". |
+ + +`queries` + | ++ +`ingestion_rate: 'sum(rate(vm_rows_inserted_total[5m])) by (type) > 0'` + | ++ +PromQL/MetricsQL query to select data in format: `QUERY_ALIAS: "QUERY"`. As accepted by `/query_range?query=%s`. + |
datasource_url |
- "http://localhost:8481/" |
- Datasource URL address | ++ +`datasource_url` + | ++ +`http://localhost:8481/` + | ++ +Datasource URL address + |
tenant_id |
- "0:0" |
- For VictoriaMetrics Cluster version only, tenants are identified by accountID or accountID:projectID. See VictoriaMetrics Cluster multitenancy docs | ++ +`tenant_id` + | ++ +`0:0` + | ++ +For VictoriaMetrics Cluster version only, tenants are identified by accountID or accountID:projectID. See VictoriaMetrics Cluster [multitenancy docs](../../Cluster-VictoriaMetrics.md#multitenancy) + |
sampling_period |
- "1h" |
- Frequency of the points returned. Will be converted to "/query_range?step=%s" param (in seconds). Required since v1.9.0. |
+ + +`sampling_period` + | ++ +`1h` + | ++ +Frequency of the points returned. Will be converted to `/query_range?step=%s` param (in seconds). **Required** since [v1.9.0](../CHANGELOG.md#v190). + |
query_range_path |
- "api/v1/query_range" |
- Performs PromQL/MetricsQL range query. Default "api/v1/query_range" |
+ + +`query_range_path` + | ++ +`/api/v1/query_range` + | ++ +Performs PromQL/MetricsQL range query + |
health_path |
- "health" |
- Absolute or relative URL address where to check availability of the datasource. Default is "health". |
+ + +`health_path` + | ++ +`health` + | ++ +Absolute or relative URL address where to check availability of the datasource. + |
user |
- "USERNAME" |
- BasicAuth username | ++ +`user` + | ++ +`USERNAME` + | ++ +BasicAuth username + |
password |
- "PASSWORD" |
- BasicAuth password | ++ +`password` + | ++ +`PASSWORD` + | ++ +BasicAuth password + |
timeout |
- "30s" |
- Timeout for the requests, passed as a string. Defaults to "30s" | ++ +`timeout` + | ++ +`30s` + | ++ +Timeout for the requests, passed as a string + |
verify_tls |
- "false" |
- Allows disabling TLS verification of the remote certificate. | ++ +`verify_tls` + | ++ +`false` + | ++ +Allows disabling TLS verification of the remote certificate. + |
bearer_token |
- "token" |
- Token is passed in the standard format with header: "Authorization: bearer {token}" | ++ +`bearer_token` + | ++ +`token` + | ++ +Token is passed in the standard format with header: `Authorization: bearer {token}` + |
extra_filters |
- "[]" |
- List of strings with series selector. See: Prometheus querying API enhancements | ++ +`extra_filters` + | ++ +`[]` + | ++ +List of strings with series selector. See: [Prometheus querying API enhancements](../../README.md##prometheus-querying-api-enhancements) + |
| @@ -107,7 +104,7 @@ Examples: `"50s"`, `"4m"`, `"3h"`, `"2d"`, `"1w"`. |
|---|
| Parameter | @@ -118,22 +115,43 @@ Examples: `"50s"`, `"4m"`, `"3h"`, `"2d"`, `"1w"`.||||||
|---|---|---|---|---|---|---|
fit_window |
+ + +`fit_window` + | str | -"14d" |
+ + +`"14d"` + | What time range to use for training the models. Must be at least 1 second. | |
infer_every |
+ + +`infer_every` + | str | -"1m" |
+ + +`"1m"` + | How often a model will write its conclusions on newly added data. Must be at least 1 second. | |
fit_every |
+ + +`fit_every` + | str, Optional | -"1h" |
- How often to completely retrain the models. If missing value of infer_every is used and retrain on every inference run. |
+ + +`"1h"` + | ++ +How often to completely retrain the models. If missing value of `infer_every` is used and retrain on every inference run. + |
| Format | @@ -178,27 +196,48 @@ If a time zone is omitted, a timezone-naive datetime is used.|||||||
|---|---|---|---|---|---|---|---|
| ISO 8601 | -fit_start_iso |
+ + +`fit_start_iso` + | str | -"2022-04-01T00:00:00Z", "2022-04-01T00:00:00+01:00", "2022-04-01T00:00:00+0100", "2022-04-01T00:00:00+01" |
+ + +`"2022-04-01T00:00:00Z", "2022-04-01T00:00:00+01:00", "2022-04-01T00:00:00+0100", "2022-04-01T00:00:00+01"` + | Start datetime to use for training a model. ISO string or UNIX time in seconds. | |
| UNIX time | -fit_start_s |
+ + +`fit_start_s` + | float | 1648771200 | |||
| ISO 8601 | -fit_end_iso |
+ + +`fit_end_iso` + | str | -"2022-04-10T00:00:00Z", "2022-04-10T00:00:00+01:00", "2022-04-10T00:00:00+0100", "2022-04-10T00:00:00+01" |
- End datetime to use for training a model. Must be greater than fit_start_*. ISO string or UNIX time in seconds. |
+ + +`"2022-04-10T00:00:00Z", "2022-04-10T00:00:00+01:00", "2022-04-10T00:00:00+0100", "2022-04-10T00:00:00+01"` + | +End datetime to use for training a model. Must be greater than + +`fit_start_*` +. ISO string or UNIX time in seconds. |
| UNIX time | -fit_end_s |
+ + +`fit_end_s` + | float | 1649548800 |
| Format | @@ -219,27 +258,48 @@ If a time zone is omitted, a timezone-naive datetime is used.|||||||
|---|---|---|---|---|---|---|---|
| ISO 8601 | -infer_start_iso |
+ + +`infer_start_iso` + | str | -"2022-04-11T00:00:00Z", "2022-04-11T00:00:00+01:00", "2022-04-11T00:00:00+0100", "2022-04-11T00:00:00+01" |
+ + +`"2022-04-11T00:00:00Z", "2022-04-11T00:00:00+01:00", "2022-04-11T00:00:00+0100", "2022-04-11T00:00:00+01"` + | Start datetime to use for a model inference. ISO string or UNIX time in seconds. | |
| UNIX time | -infer_start_s |
+ + +`infer_start_s` + | float | 1649635200 | |||
| ISO 8601 | -infer_end_iso |
+ + +`infer_end_iso` + | str | -"2022-04-14T00:00:00Z", "2022-04-14T00:00:00+01:00", "2022-04-14T00:00:00+0100", "2022-04-14T00:00:00+01" |
- End datetime to use for a model inference. Must be greater than infer_start_*. ISO string or UNIX time in seconds. |
+ + +`"2022-04-14T00:00:00Z", "2022-04-14T00:00:00+01:00", "2022-04-14T00:00:00+0100", "2022-04-14T00:00:00+01"` + | +End datetime to use for a model inference. Must be greater than + +`infer_start_*` +. ISO string or UNIX time in seconds. |
| UNIX time | -infer_end_s |
+ + +`infer_end_s` + | float | 1649894400 |
| Parameter | @@ -295,10 +355,19 @@ If a time zone is omitted, a timezone-naive datetime is used.||||||
|---|---|---|---|---|---|---|
n_jobs |
+ + +`n_jobs` + | int | -1 |
- Allows proportionally faster (yet more resource-intensive) evaluations of a config on historical data. Default value is 1, that implies sequential execution. Introduced in v1.13.0 | ++ +`1` + | ++ +Allows *proportionally faster (yet more resource-intensive)* evaluations of a config on historical data. Default value is 1, that implies *sequential* execution. Introduced in [v1.13.0](../CHANGELOG.md#v1130) + |
| Format | @@ -319,27 +388,48 @@ This timeframe will be used for slicing on intervals `(fit_window, infer_window|||||||
|---|---|---|---|---|---|---|---|
| ISO 8601 | -from_iso |
+ + +`from_iso` + | str | -"2022-04-01T00:00:00Z", "2022-04-01T00:00:00+01:00", "2022-04-01T00:00:00+0100", "2022-04-01T00:00:00+01" |
+ + +`"2022-04-01T00:00:00Z", "2022-04-01T00:00:00+01:00", "2022-04-01T00:00:00+0100", "2022-04-01T00:00:00+01"` + | Start datetime to use for backtesting. | |
| UNIX time | -from_s |
+ + +`from_s` + | float | 1648771200 | |||
| ISO 8601 | -to_iso |
+ + +`to_iso` + | str | -"2022-04-10T00:00:00Z", "2022-04-10T00:00:00+01:00", "2022-04-10T00:00:00+0100", "2022-04-10T00:00:00+01" |
- End datetime to use for backtesting. Must be greater than from_start_*. |
+ + +`"2022-04-10T00:00:00Z", "2022-04-10T00:00:00+01:00", "2022-04-10T00:00:00+0100", "2022-04-10T00:00:00+01"` + | +End datetime to use for backtesting. Must be greater than + +`from_start_*` + |
| UNIX time | -to_s |
+ + +`to_s` + | float | 1649548800 |
| Format | @@ -361,21 +451,30 @@ The same *explicit* logic as in [Periodic scheduler](#periodic-scheduler)||||||
|---|---|---|---|---|---|---|
| ISO 8601 | -fit_window |
+ + +`fit_window` + | str | -"PT1M", "P1H" |
+ + +`"PT1M", "P1H"` + | What time range to use for training the models. Must be at least 1 second. |
| Prometheus-compatible | -"1m", "1h" |
+ + +`"1m", "1h"` + |
| Format | @@ -388,14 +487,23 @@ In `BacktestingScheduler`, the inference window is *implicitly* defined as a per||||||
|---|---|---|---|---|---|---|
| ISO 8601 | -fit_every |
+ + +`fit_every` + | str | -"PT1M", "P1H" |
+ + +`"PT1M", "P1H"` + | What time range to use previously trained model to infer on new data until next retrain happens. |
| Prometheus-compatible | -"1m", "1h" |
+ + +`"1m", "1h"` + |
| Parameter | @@ -30,71 +27,190 @@ Future updates will introduce additional export methods, offering users more fle|||||
|---|---|---|---|---|---|
class |
- "writer.vm.VmWriter" (or "vm" starting from v1.13.0) |
- Name of the class needed to enable writing to VictoriaMetrics or Prometheus. VmWriter is the default option, if not specified. | ++ +`class` + | ++ +`writer.vm.VmWriter` or `vm` starting from [`v1.13.0`](../CHANGELOG.md#v1130) + | ++ +Name of the class needed to enable writing to VictoriaMetrics or Prometheus. VmWriter is the default option, if not specified. + |
datasource_url |
- "http://localhost:8481/" |
- Datasource URL address | ++ +`datasource_url` + | ++ +`http://localhost:8481/` + | ++ +Datasource URL address + |
tenant_id |
- "0:0" |
- For VictoriaMetrics Cluster version only, tenants are identified by accountID or accountID:projectID. See VictoriaMetrics Cluster multitenancy docs | ++ +`tenant_id` + | ++ +`0:0` + | ++ +For VictoriaMetrics Cluster version only, tenants are identified by accountID or accountID:projectID. See VictoriaMetrics Cluster [multitenancy docs](../../Cluster-VictoriaMetrics.md#multitenancy) + |
metric_format |
- __name__: "vmanomaly_$VAR" |
- Metrics to save the output (in metric names or labels). Must have __name__ key. Must have a value with $VAR placeholder in it to distinguish between resulting metrics. Supported placeholders:
+ | + +`metric_format` + | ++ +`__name__: "vmanomaly_$VAR"` + | +
+
+Metrics to save the output (in metric names or labels). Must have `__name__` key. Must have a value with `$VAR` placeholder in it to distinguish between resulting metrics. Supported placeholders:
|
for: "$QUERY_KEY" | |||||
run: "test_metric_format" | |||||
config: "io_vm_single.yaml" | |||||
| + +`for: "$QUERY_KEY"` + | +|||||
| + +`run: "test_metric_format"` + | +|||||
| + +`config: "io_vm_single.yaml"` + | +|||||
import_json_path |
- "/api/v1/import" |
- Optional, to override the default import path | ++ +`import_json_path` + | ++ +`/api/v1/import` + | ++ +Optional, to override the default import path + |
health_path |
- "health" |
- Absolute or relative URL address where to check the availability of the datasource. Optional, to override the default "/health" path. |
+ + +`health_path` + | ++ +`/health` + | ++ +Absolute or relative URL address where to check the availability of the datasource. Optional, to override the default `/health` path. + |
user |
- "USERNAME" |
- BasicAuth username | ++ +`user` + | ++ +`USERNAME` + | ++ +BasicAuth username + |
password |
- "PASSWORD" |
- BasicAuth password | ++ +`password` + | ++ +`PASSWORD` + | ++ +BasicAuth password + |
timeout |
- "5s" |
- Timeout for the requests, passed as a string. Defaults to "5s" | ++ +`timeout` + | ++ +`5s` + | ++ +Timeout for the requests, passed as a string + |
verify_tls |
- "false" |
- Allows disabling TLS verification of the remote certificate. | ++ +`verify_tls` + | ++ +`false` + | ++ +Allows disabling TLS verification of the remote certificate. + |
bearer_token |
- "token" |
- Token is passed in the standard format with the header: "Authorization: bearer {token}" | ++ +`bearer_token` + | ++ +`token` + | ++ +Token is passed in the standard format with the header: `Authorization: bearer {token}` + |
+
> **Note: Configurations used throughout this guide can be found [here](https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/deployment/docker/vmanomaly/vmanomaly-integration/)**
-> **Note:** Starting from [v1.13.0](/anomaly-detection/CHANGELOG#v1130) `node-exporter` observability preset is available for `vmanomaly`. Please find the guide [here](/anomaly-detection/presets/#node-exporter).
+> **Note:** Starting from [v1.13.0](../../CHANGELOG.md#v1130) `node-exporter` observability preset is available for `vmanomaly`. Please find the guide [here](../../Presets.md#node-exporter).
## 1. What is vmanomaly?
-*VictoriaMetrics Anomaly Detection* ([vmanomaly](/anomaly-detection/overview/)) is a service that continuously scans time series stored in VictoriaMetrics and detects unexpected changes within data patterns in real-time. It does so by utilizing user-configurable machine learning models.
+*VictoriaMetrics Anomaly Detection* ([vmanomaly](../../Overview.md)) is a service that continuously scans time series stored in VictoriaMetrics and detects unexpected changes within data patterns in real-time. It does so by utilizing user-configurable machine learning models.
All the service parameters are defined in a config file.
-> **Note**: Starting from [1.10.0](/anomaly-detection/changelog/#v1100), each `vmanomaly` configuration file can support more that one model type. To utilize *different models* on your data, it is no longer necessary to run multiple instances of the `vmanomaly` process. Please refer to [model](/anomaly-detection/components/models/) config section for more details.
+> **Note**: Starting from [1.10.0](../../CHANGELOG.md#v1100), each `vmanomaly` configuration file can support more that one model type. To utilize *different models* on your data, it is no longer necessary to run multiple instances of the `vmanomaly` process. Please refer to [model](../..//components/models.md) config section for more details.
-> **Note**: Starting from [1.11.0](/anomaly-detection/changelog/#v1110), each `vmanomaly` configuration file can support more that one model type, each attached to one (or more) schedulers. To utilize *different models* with *different schedulers* on your data, it is no longer necessary to run multiple instances of the `vmanomaly` process. Please refer to [model](/anomaly-detection/components/models/#schedulers) and [scheduler](/anomaly-detection/components/scheduler/) config sections for more details.
+> **Note**: Starting from [1.11.0](../../CHANGELOG.md#v1110), each `vmanomaly` configuration file can support more that one model type, each attached to one (or more) schedulers. To utilize *different models* with *different schedulers* on your data, it is no longer necessary to run multiple instances of the `vmanomaly` process. Please refer to [model](../../components/models.md#schedulers) and [scheduler](../../components/scheduler.md) config sections for more details.
**vmanomaly** does the following:
@@ -61,9 +44,9 @@ Then, users can enable alerting rules based on the **anomaly score** with [vmale
## 2. What is vmalert?
-[vmalert](https://docs.victoriametrics.com/vmalert/) is an alerting tool for VictoriaMetrics. It executes a list of the given alerting or recording rules against configured `-datasource.url`.
+[vmalert](../../../vmalert.md) is an alerting tool for VictoriaMetrics. It executes a list of the given alerting or recording rules against configured `-datasource.url`.
-[Alerting rules](https://docs.victoriametrics.com/vmalert/#alerting-rules) allow you to define conditions that, when met, will notify the user. The alerting condition is defined in a form of a query expression via [MetricsQL query language](https://docs.victoriametrics.com/metricsql/). For example, in our case, the expression `anomaly_score > 1.0` will notify a user when the calculated anomaly score exceeds a threshold of `1.0`.
+[Alerting rules](../../../vmalert.md#alerting-rules) allow you to define conditions that, when met, will notify the user. The alerting condition is defined in a form of a query expression via [MetricsQL query language](../../../MetricsQL.md). For example, in our case, the expression `anomaly_score > 1.0` will notify a user when the calculated anomaly score exceeds a threshold of `1.0`.
## 3. How does vmanomaly works with vmalert?
@@ -72,9 +55,9 @@ Compared to classical alerting rules, anomaly detection is more "hands-off" and
Practical use case is to put anomaly score generated by vmanomaly into alerting rules with some threshold.
**In this tutorial we are going to:**
- - Configure docker-compose file with all needed services ([VictoriaMetrics Single-Node](https://docs.victoriametrics.com/single-server-victoriametrics/), [vmalert](https://docs.victoriametrics.com/vmalert/), [vmagent](https://docs.victoriametrics.com/vmagent/), [Grafana](https://grafana.com/), [Node Exporter](https://prometheus.io/docs/guides/node-exporter/) and [vmanomaly](https://docs.victoriametrics.com/anomaly-detection/overview/) ).
- - Explore configuration files for [vmanomaly](https://docs.victoriametrics.com/anomaly-detection/overview/) and [vmalert](https://docs.victoriametrics.com/vmalert/).
- - Run our own [VictoriaMetrics](https://docs.victoriametrics.com/single-server-victoriametrics/) database with data scraped from [Node Exporter](https://prometheus.io/docs/guides/node-exporter/).
+ - Configure docker-compose file with all needed services ([VictoriaMetrics Single-Node](../../../Single-Server-VictoriaMetrics.md), [vmalert](../../../vmalert.md), [vmagent](../../../vmagent.md), [Grafana](https://grafana.com/), [Node Exporter](https://prometheus.io/docs/guides/node-exporter/) and [vmanomaly](../../Overview.md) ).
+ - Explore configuration files for [vmanomaly](../../Overview.md) and [vmalert](../../../vmalert.md).
+ - Run our own [VictoriaMetrics](../../../Single-Server-VictoriaMetrics.md) database with data scraped from [Node Exporter](https://prometheus.io/docs/guides/node-exporter/).
- Explore data for analysis in [Grafana](https://grafana.com/).
- Explore `vmanomaly` results.
- Explore `vmalert` alerts
@@ -105,10 +88,10 @@ node_cpu_seconds_total{cpu="1",mode="iowait"} 51.22
In this context, the metric `node_cpu_seconds_total` provides a comprehensive breakdown of the time each CPU core has spent in various operational modes. These modes include: _user_, _system_, _iowait_, _idle_, _irq&softirq_, _guest_, and _steal_. Each of these eight modes is mutually exclusive, offering distinct insights into CPU activity. For instance, a predominant _iowait_ suggests disk or network bottlenecks, while elevated levels in _user_ or _system_ indicate significant CPU utilization.
-The `node_cpu_seconds_total` metric is classified as a [counter](https://docs.victoriametrics.com/keyconcepts/#counter) type. To analyze the duration each CPU core spends in these modes, it is necessary to compute the rate of change per second using the [rate function](https://docs.victoriametrics.com/metricsql/#rate): `rate(node_cpu_seconds_total)`. For a more refined and smoother aggregation of data by mode, we apply the sum function. The resulting query is formulated as follows: `sum(rate(node_cpu_seconds_total[5m])) by (mode, instance, job)`.
+The `node_cpu_seconds_total` metric is classified as a [counter](../../../keyConcepts.md#counter) type. To analyze the duration each CPU core spends in these modes, it is necessary to compute the rate of change per second using the [rate function](../../../MetricsQL.md#rate): `rate(node_cpu_seconds_total)`. For a more refined and smoother aggregation of data by mode, we apply the sum function. The resulting query is formulated as follows: `sum(rate(node_cpu_seconds_total[5m])) by (mode, instance, job)`.
Below is an illustrative example of how this query might be visualized in Grafana:
-
+
This query will yield a total of eight time series, each corresponding to a CPU mode. The number of series is unaffected by the number of CPU cores, due to the `by` aggregation applied. These series serve as the input for `vmanomaly`, where the service independently fits a separate instance of the configured model type to each of time series.
@@ -119,25 +102,25 @@ This query will yield a total of eight time series, each corresponding to a CPU
**Parameter description**:
The configuration file for `vmanomaly` comprises 4 essential sections:
-1. [`scheduler`](/anomaly-detection/components/scheduler.html) - This section determines the frequency of model inferences and training, including the time range for model training. Starting from [v1.11.0](/anomaly-detection/changelog/#v1110), multiple individual schedulers are supported for each model type in a single config.
+1. [`scheduler`](../../components/scheduler.md) - This section determines the frequency of model inferences and training, including the time range for model training. Starting from [v1.11.0](../../CHANGELOG.md#v1110), multiple individual schedulers are supported for each model type in a single config.
-2. [`models`](/anomaly-detection/components/models.html) - Here, you define specific parameters and configurations for the models being used for anomaly detection. Starting from [v1.10.0](/anomaly-detection/changelog/#v1100), multiple model configurations are supported in a single config.
+2. [`models`](../../components/models.md) - Here, you define specific parameters and configurations for the models being used for anomaly detection. Starting from [v1.10.0](../../CHANGELOG.md#v1100), multiple model configurations are supported in a single config.
-3. [`reader`](/anomaly-detection/components/reader.html) - This section outlines the methodology for data reading, including the data source location.
+3. [`reader`](../../components/reader.md) - This section outlines the methodology for data reading, including the data source location.
-4. [`writer`](/anomaly-detection/components/writer.html) - Specifies the destination and method for writing the generated output.
+4. [`writer`](../../components/writer.md) - Specifies the destination and method for writing the generated output.
-5. [`monitoring`](/anomaly-detection/components/monitoring.html) (optional) - Describes how to monitor and expose health check metrics of `vmanomaly`.
+5. [`monitoring`](../../components/monitoring.md) (optional) - Describes how to monitor and expose health check metrics of `vmanomaly`.
Detailed parameters in each section:
-* `schedulers` ([PeriodicScheduler](/anomaly-detection/components/scheduler/#periodic-scheduler) is used here)
+* `schedulers` ([PeriodicScheduler](../../components/scheduler.md#periodic-scheduler) is used here)
* `infer_every` - Specifies the frequency at which the trained models perform inferences on new data, essentially determining how often new anomaly score data points are generated. Format examples: 30s, 4m, 2h, 1d (time units: 's' for seconds, 'm' for minutes, 'h' for hours, 'd' for days). This parameter essentially asks, at regular intervals (e.g., every 1 minute), whether the latest data points appear abnormal based on historical data.
* `fit_every` - Sets the frequency for retraining the models. A higher frequency ensures more updated models but requires more CPU resources. If omitted, models are retrained in each `infer_every` cycle. Format is similar to `infer_every`.
* `fit_window` - Defines the data interval for training the models. Longer intervals allow for capturing extensive historical behavior and better seasonal pattern detection but may slow down the model's response to permanent metric changes and increase resource consumption. A minimum of two full seasonal cycles is recommended. Example format: 3h for three hours of data.
* `models`
- * `class` - Specifies the model to be used. Options include custom models ([guide here](/anomaly-detection/components/models.html#custom-model-guide)) or a selection from [built-in models](/anomaly-detection/components/models.html#built-in-models), such as the [Facebook Prophet](/anomaly-detection/components/models.html#prophet) (`model.prophet.ProphetModel`).
+ * `class` - Specifies the model to be used. Options include custom models ([guide here](../../components/models.md#custom-model-guide)) or a selection from [built-in models](../../components/models.md#built-in-models), such as the [Facebook Prophet](../../components/models.md#prophet) (`model.prophet.ProphetModel`).
* `args` - Model-specific parameters, formatted as a YAML dictionary in the `key: value` structure. Parameters available in [FB Prophet](https://facebook.github.io/prophet/docs/quick_start.html) can be used as an example.
* `reader`
@@ -210,7 +193,7 @@ groups:
summary: Anomaly Score exceeded 1.0. `sum(rate(node_cpu_seconds_total))` is showing abnormal behavior.
```
-In the query expression `expr`, it's crucial to establish a criterion based on the generated anomaly scores. Typically, an [anomaly score](/anomaly-detection/faq/#what-is-anomaly-score) ranging from 0.0 to 1.0 indicates that the analyzed value falls within normal behavior. Scores exceeding 1.0 signal increasing confidence from our model that the observed value is anomalous.
+In the query expression `expr`, it's crucial to establish a criterion based on the generated anomaly scores. Typically, an [anomaly score](../../FAQ.md#what-is-anomaly-score) ranging from 0.0 to 1.0 indicates that the analyzed value falls within normal behavior. Scores exceeding 1.0 signal increasing confidence from our model that the observed value is anomalous.
Selecting an appropriate threshold for the anomaly score depends on your specific requirements and the context of the data. One effective method for determining this threshold is through visual analysis. By plotting the `anomaly_score` metric in conjunction with the predicted 'expected' range, delineated by `yhat_lower` and `yhat_upper`, you can make a more informed decision. Later in this tutorial, we will demonstrate this process with a practical example.
@@ -306,7 +289,7 @@ scrape_configs:
We will utilize the license key stored locally in the file `vmanomaly_license`.
-For additional licensing options, please refer to the [VictoriaMetrics Anomaly Detection documentation on licensing](https://docs.victoriametrics.com/anomaly-detection/overview/#licensing).
+For additional licensing options, please refer to the [VictoriaMetrics Anomaly Detection documentation on licensing](../../Overview.md#licensing).
### Alertmanager setup
@@ -452,7 +435,7 @@ networks:
Before running our docker-compose make sure that your directory contains all required files:
-
+
This docker-compose file will pull docker images, set up each service and run them all together with the command:
@@ -489,7 +472,7 @@ Each of these metrics will contain same labels our query `sum(rate(node_cpu_seco
### Anomaly scores for each metric with its according labels.
Query: `anomaly_score`
-
+
+
Boundaries of 'normal' metric values according to model inference.
@@ -508,10 +491,10 @@ Boundaries of 'normal' metric values according to model inference.
On the page `http://localhost:8880/vmalert/groups` you can find our configured Alerting rule:
-
+
According to the rule configured for vmalert we will see Alert when anomaly score exceed 1. You will see an alert on Alert tab. `http://localhost:8880/vmalert/alerts`:
-
+
## 10. Conclusion
@@ -529,4 +512,4 @@ Key takeaways include:
As you continue to use VictoriaMetrics Anomaly Detection and `vmalert`, remember that the effectiveness of anomaly detection largely depends on the appropriateness of the model chosen, the accuracy of configurations and the data patterns observed. This guide serves as a starting point, and we encourage you to experiment with different configurations and models to best suit your specific data needs and use cases. In case you need a helping hand - [contact us](https://victoriametrics.com/contact-us/).
-> **Note:** Starting from [v1.13.0](/anomaly-detection/CHANGELOG#v1130) `node-exporter` observability preset is available for `vmanomaly`. Please find the guide [here](/anomaly-detection/presets/#node-exporter).
+> **Note:** Starting from [v1.13.0](../../CHANGELOG.md#v1130) `node-exporter` observability preset is available for `vmanomaly`. Please find the guide [here](../../Presets.md#node-exporter).
diff --git a/docs/anomaly-detection/guides/guide-vmanomaly-vmalert/_index.md b/docs/anomaly-detection/guides/guide-vmanomaly-vmalert/_index.md
new file mode 100644
index 000000000..3725875ab
--- /dev/null
+++ b/docs/anomaly-detection/guides/guide-vmanomaly-vmalert/_index.md
@@ -0,0 +1,15 @@
+---
+weight: 1
+sort: 1
+title: Anomaly Detection and Alerting Setup
+menu:
+ docs:
+ parent: "anomaly-detection-guides"
+ weight: 1
+aliases:
+- /anomaly-detection/guides/guide-vmanomaly-vmalert.html
+- /guides/guide-vmanomaly-vmalert.html
+- /guides/vmanomaly-integration.html
+- /guides/anomaly-detection-and-alerting-setup.html
+---
+{{% content "README.md" %}}
diff --git a/docs/data-ingestion/Proxmox.md b/docs/data-ingestion/Proxmox.md
index 5411ed88f..7780d9d70 100644
--- a/docs/data-ingestion/Proxmox.md
+++ b/docs/data-ingestion/Proxmox.md
@@ -12,8 +12,6 @@ aliases:
- /data-ingestion/proxmox.html
- /data-ingestion/Proxmox.html
---
-
-# Proxmox Data Ingestion
Since Proxmox Virtual Environment(PVE) and Proxmox Backup Server(PBS) support sending data using the InfluxDB We can use the InfluxDB write support built into VictoriaMetrics
Currently PVE and PBS only support using an Authorization Token for authentication and does not support basic auth or a username and password.
@@ -23,7 +21,7 @@ If want help Sending your data to Managed VictoriaMetrics check out [our blog](h
1. Login to PVE as an administrator
2. Go to DataCenter > MetricServer > Add > InfluxDB
-
+
3. Set the parameters as follows:
- Name: VictoriaMetrics (can be changed to any string)
@@ -36,7 +34,7 @@ If want help Sending your data to Managed VictoriaMetrics check out [our blog](h
- If you need to ignore TLS/SSL errors check the advanced box and uncheck the verify certificate box
4. Click the `Create` button
-
+
5. Run `system_uptime{object="nodes"}` in vmui or in the explore view in Grafana to verify metrics from PVE are being sent to VictoriaMetrics.
You should see 1 time series per node in your PVE cluster.
@@ -46,7 +44,7 @@ You should see 1 time series per node in your PVE cluster.
2. Go to Configuration > Metrics Server > Add > InfluxDB
-
+
3. Set the parameters as follows:
@@ -60,7 +58,7 @@ You should see 1 time series per node in your PVE cluster.
4. Click the `Create` button
-
+
5. Run `cpustat_idle{object="host"}` in vmui or in the explore view in Grafana to verify metrics from PBS are being to VictoriaMetrics.
diff --git a/docs/data-ingestion/Telegraf.md b/docs/data-ingestion/Telegraf.md
index 744dcd1cd..a74e588f5 100644
--- a/docs/data-ingestion/Telegraf.md
+++ b/docs/data-ingestion/Telegraf.md
@@ -12,7 +12,6 @@ aliases:
- /data-ingestion/telegraf.html
- /data-ingestion/Telegraf.html
---
-# Telegraf Setup
You will need to add the following output section to a Telegraf configuration file and reload Telegraf to enable shipping data from Telegraf to VictoriaMetrics.
All the options examples below can be combined to fit your use case
diff --git a/docs/data-ingestion/Vector.md b/docs/data-ingestion/Vector.md
index 072dee48a..47489111e 100644
--- a/docs/data-ingestion/Vector.md
+++ b/docs/data-ingestion/Vector.md
@@ -12,7 +12,6 @@ aliases:
- /data-ingestion/Vector.html
- /data-ingestion/vector.html
---
-# Vector
To Send data to Vector you need to configure with a Prometheus remote write sink and forward metrics to that sink from at least 1 source.
You will need to replace the values in `<>` with your to match your setup.
diff --git a/docs/enterprise.md b/docs/enterprise.md
index 7f1a0fcde..cb53954e7 100644
--- a/docs/enterprise.md
+++ b/docs/enterprise.md
@@ -9,9 +9,6 @@ menu:
aliases:
- /enterprise.html
---
-
-# VictoriaMetrics Enterprise
-
VictoriaMetrics components are provided in two kinds - [Community edition](https://victoriametrics.com/products/open-source/)
and [Enterprise edition](https://victoriametrics.com/products/enterprise/).
diff --git a/docs/goals.md b/docs/goals.md
index 9e6577d24..64d6a3f1a 100644
--- a/docs/goals.md
+++ b/docs/goals.md
@@ -7,9 +7,6 @@ menu:
parent: 'victoriametrics'
weight: 500
---
-
-# VictoriaMetrics development goals
-
## Goals
1. The main goal - **to help users and [clients](https://docs.victoriametrics.com/enterprise/) resolving issues with VictoriaMetrics components,
diff --git a/docs/guides/README.md b/docs/guides/README.md
index 4e374fa2a..8f6a7bda6 100644
--- a/docs/guides/README.md
+++ b/docs/guides/README.md
@@ -8,4 +8,4 @@
1. [How to delete or replace metrics in VictoriaMetrics](guide-delete-or-replace-metrics.html)
1. [How to monitor kubernetes cluster using Managed VictoriaMetrics](/managed-victoriametrics/how-to-monitor-k8s.html)
1. [How to configure vmgateway for multi-tenant access using Grafana and OpenID Connect](grafana-vmgateway-openid-configuration.html)
-1. [How to setup vmanomaly together with vmalert](/anomaly-detection/guides/guide-vmanomaly-vmalert.html)
+1. [How to setup vmanomaly together with vmalert](/anomaly-detection/guides/guide-vmanomaly-vmalert/README.md)
diff --git a/docs/guides/_index.md b/docs/guides/_index.md
index c7fbe306d..d58ebd9f7 100644
--- a/docs/guides/_index.md
+++ b/docs/guides/_index.md
@@ -1,6 +1,7 @@
---
sort: 26
weight: 01
+title: Guides
disableToc: true
menu:
docs:
diff --git a/docs/guides/getting-started-with-opentelemetry.md b/docs/guides/getting-started-with-opentelemetry.md
index 7d5afe912..eb77aefef 100644
--- a/docs/guides/getting-started-with-opentelemetry.md
+++ b/docs/guides/getting-started-with-opentelemetry.md
@@ -6,7 +6,6 @@ menu:
parent: "guides"
weight: 5
---
-
VictoriaMetrics supports metrics ingestion with [OpenTelemetry metrics format](https://opentelemetry.io/docs/specs/otel/metrics/).
This guide covers data ingestion via [opentelemetry-collector](https://opentelemetry.io/docs/collector/) and direct metrics push from application.
@@ -45,7 +44,7 @@ Read Data:
## Using opentelemetry-collector with VictoriaMetrics
-
+
### Deploy opentelemetry-collector and configure metrics forwarding
@@ -164,14 +163,14 @@ for i in `seq 1 20`; do curl http://localhost:8080/rolldice; done
```
After a few seconds you should start to see metrics sent over to the vmui interface by visiting `http://localhost:8428/vmui/#/?g0.expr=dice.rolls` in your browser or by querying the metric `dice.rolls` in the vmui interface.
-
+
## Direct metrics push
Metrics could be ingested into VictoriaMetrics directly with HTTP requests. You can use any compatible OpenTelemetry
instrumentation [clients](https://opentelemetry.io/docs/languages/).
In our example, we'll create a WEB server in [Golang](https://go.dev/) and instrument it with metrics.
-
+
### Building the Go application instrumented with metrics
@@ -350,7 +349,7 @@ curl http://localhost:8081/api/slow
Open [vmui](https://docs.victoriametrics.com/#vmui) and query `http_requests_total` or `http_active_requests`
with [metricsql](https://docs.victoriametrics.com/metricsql/).
-
+
## Limitations
diff --git a/docs/guides/getting-started-with-vm-operator.md b/docs/guides/getting-started-with-vm-operator.md
index a7f072952..c218492bc 100644
--- a/docs/guides/getting-started-with-vm-operator.md
+++ b/docs/guides/getting-started-with-vm-operator.md
@@ -8,8 +8,6 @@ menu:
aliases:
- /guides/getting-started-with-vm-operator.html
---
-# Getting started with VM Operator
-
**The guide covers:**
* The setup of a [VM Operator](https://github.com/VictoriaMetrics/helm-charts/tree/master/charts/victoria-metrics-operator) via Helm in [Kubernetes](https://kubernetes.io/) with Helm charts.
@@ -215,7 +213,7 @@ Forwarding from [::1]:8429 -> 8429
To check that `VMAgent` collects metrics from the k8s cluster open in the browser [http://127.0.0.1:8429/targets](http://127.0.0.1:8429/targets) .
You will see something like this:
-
+
`VMAgent` connects to [kubernetes service discovery](https://kubernetes.io/docs/concepts/services-networking/service/) and gets targets which needs to be scraped. This service discovery is controlled by [VictoriaMetrics Operator](https://github.com/VictoriaMetrics/operator)
@@ -289,11 +287,11 @@ EOF
To check that [VictoriaMetrics](https://victoriametrics.com) collecting metrics from the k8s cluster open in your browser [http://127.0.0.1:3000/dashboards](http://127.0.0.1:3000/dashboards) and choose the `VictoriaMetrics - cluster` dashboard. Use `admin` for login and the `password` that you previously got from kubectl.
-
+
The expected output is:
-
+
## 6. Summary
diff --git a/docs/guides/grafana-vmgateway-openid-configuration.md b/docs/guides/grafana-vmgateway-openid-configuration/README.md
similarity index 88%
rename from docs/guides/grafana-vmgateway-openid-configuration.md
rename to docs/guides/grafana-vmgateway-openid-configuration/README.md
index a90037ae3..a3d247a64 100644
--- a/docs/guides/grafana-vmgateway-openid-configuration.md
+++ b/docs/guides/grafana-vmgateway-openid-configuration/README.md
@@ -1,15 +1,3 @@
----
-weight: 5
-title: How to configure vmgateway for multi-tenant access using Grafana and OpenID Connect
-menu:
- docs:
- parent: "guides"
- weight: 5
-aliases:
-- /guides/grafana-vmgateway-openid-configuration.html
----
-# How to configure vmgateway for multi-tenant access using Grafana and OpenID Connect
-
Using [Grafana](https://grafana.com/) with [vmgateway](https://docs.victoriametrics.com/vmgateway/) is a great way to provide [multi-tenant](https://docs.victoriametrics.com/cluster-victoriametrics/#multitenancy) access to your metrics.
vmgateway provides a way to authenticate users using [JWT tokens](https://en.wikipedia.org/wiki/JSON_Web_Token) issued by an external identity provider.
Those tokens can include information about the user and the tenant they belong to, which can be used
@@ -48,21 +36,21 @@ See details about all supported options in the [vmgateway documentation](https:/
Use `OpenID Connect` as `Client Type`.
+ 
1. Enable `Client authentication`.
+
This allows Grafana to use a more efficient API to get label values.
@@ -207,7 +195,7 @@ You can also use VictoriaMetrics [Grafana datasource](https://github.com/Victori
See installation instructions [here](https://docs.victoriametrics.com/victoriametrics-datasource/#installation).
Enable `Forward OAuth identity` flag.
+
Now you can use Grafana to query metrics from the specified tenant.
Users with `vm_access` claim will be able to query metrics from the specified tenant.
@@ -330,22 +318,22 @@ vmagent will write data into VictoriaMetrics single-node and cluster(with tenant
Grafana datasources configuration will be the following:
-
+[Test datasources](grafana-vmgateway-openid-configuration/grafana-test-datasources.webp)
Let's login as user with `team=dev` labels limitation set via claims.
Using `vmgateway-cluster` results into `No data` response as proxied request will go to tenant `0:1`.
Since vmagent is only configured to write to `0:0` `No data` is an expected response.
-
+[Dev cluster nodata](grafana-vmgateway-openid-configuration/dev-cluster-nodata.webp)
Switching to `vmgateway-single` does have data. Note that it is limited to metrics with `team=dev` label.
-
+[Dev single data](grafana-vmgateway-openid-configuration/dev-single-data.webp)
Now lets login as user with `team=admin`.
Both cluster and single node datasources now return metrics for `team=admin`.
-
-
+[Admin cluster data](grafana-vmgateway-openid-configuration/admin-cluster-data.webp)
+[Admin single data](grafana-vmgateway-openid-configuration/admin-single-data.webp)
diff --git a/docs/guides/grafana-vmgateway-openid-configuration/_index.md b/docs/guides/grafana-vmgateway-openid-configuration/_index.md
new file mode 100644
index 000000000..3d33c4e6b
--- /dev/null
+++ b/docs/guides/grafana-vmgateway-openid-configuration/_index.md
@@ -0,0 +1,11 @@
+---
+weight: 5
+title: How to configure vmgateway for multi-tenant access using Grafana and OpenID Connect
+menu:
+ docs:
+ parent: "guides"
+ weight: 5
+aliases:
+- /guides/grafana-vmgateway-openid-configuration.html
+---
+{{% content "README.md" %}}
diff --git a/docs/guides/guide-delete-or-replace-metrics.md b/docs/guides/guide-delete-or-replace-metrics.md
index 90c2c2558..90bf0e4da 100644
--- a/docs/guides/guide-delete-or-replace-metrics.md
+++ b/docs/guides/guide-delete-or-replace-metrics.md
@@ -8,8 +8,6 @@ menu:
aliases:
- /guides/guide-delete-or-replace-metrics.html
---
-# How to delete or replace metrics in VictoriaMetrics
-
Data deletion is an operation people expect a database to have. [VictoriaMetrics](https://victoriametrics.com) supports
[delete operation](https://docs.victoriametrics.com/single-server-victoriametrics/#how-to-delete-time-series) but to a limited extent. Due to implementation details, VictoriaMetrics remains an [append-only database](https://en.wikipedia.org/wiki/Append-only), which perfectly fits the case for storing time series data. But the drawback of such architecture is that it is extremely expensive to mutate the data. Hence, `delete` or `update` operations support is very limited. In this guide, we'll walk through the possible workarounds for deleting or changing already written data in VictoriaMetrics.
@@ -31,7 +29,7 @@ To check that metrics are present in **VictoriaMetrics Cluster** run the followi
_Warning: response can return many metrics, so be careful with series selector._
-```curl
+```sh
curl -s 'http://vmselect:8481/select/0/prometheus/api/v1/series?match[]=process_cpu_cores_available' | jq
```
@@ -81,7 +79,7 @@ The expected output:
When you're sure [time series selector](https://prometheus.io/docs/prometheus/latest/querying/basics/#time-series-selectors) is correct, send a POST request to [delete API](https://docs.victoriametrics.com/url-examples/#apiv1admintsdbdelete_series) with [`match[]=
+
**Implementation Details**
diff --git a/docs/guides/k8s-ha-monitoring-via-vm-cluster.md b/docs/guides/k8s-ha-monitoring-via-vm-cluster.md
index 49a530825..3bfdc82d6 100644
--- a/docs/guides/k8s-ha-monitoring-via-vm-cluster.md
+++ b/docs/guides/k8s-ha-monitoring-via-vm-cluster.md
@@ -8,9 +8,6 @@ menu:
aliases:
- /guides/k8s-ha-monitoring-via-vm-cluster.html
---
-# HA monitoring setup in Kubernetes via VictoriaMetrics Cluster
-
-
**The guide covers:**
* High availability monitoring via [VictoriaMetrics cluster](https://docs.victoriametrics.com/cluster-victoriametrics/) in [Kubernetes](https://kubernetes.io/) with Helm charts
@@ -300,7 +297,7 @@ kubectl port-forward svc/vmcluster-victoria-metrics-cluster-vmselect 8481:8481
Execute the following command to get metrics via `curl`:
-```curl
+```sh
curl -sg 'http://127.0.0.1:8481/select/0/prometheus/api/v1/query_range?query=count(up{kubernetes_pod_name=~".*vmselect.*"})&start=-10m&step=1m' | jq
```
@@ -362,15 +359,15 @@ The expected result of the query `count(up{kubernetes_pod_name=~".*vmselect.*"})
To test via Grafana, we need to install it first. [Install and connect Grafana to VictoriaMetrics](https://docs.victoriametrics.com/guides/k8s-monitoring-via-vm-cluster.html#4-install-and-connect-grafana-to-victoriametrics-with-helm), login into Grafana and open the metrics [Explore](http://127.0.0.1:3000/explore) page.
-
+
Choose `victoriametrics` from the list of datasources and enter `count(up{kubernetes_pod_name=~".*vmselect.*"})` to the **Metric browser** field as shown on the screenshot, then press **Run query** button:
-
+
The expected output is:
-
+
## 5. High Availability
@@ -398,13 +395,13 @@ Return to Grafana Explore and press the **Run query** button again.
The expected output is:
-
+
As you can see, after we scaled down the `vmstorage` replicas number from three to two pods, metrics are still available and correct. The response is not partial as it was before scaling. Also we see that query `count(up{kubernetes_pod_name=~".*vmselect.*"})` returns the same value as before.
To confirm that the number of `vmstorage` pods is equivalent to two, execute the following request in Grafana Explore:
-
+
## 6. Final thoughts
diff --git a/docs/guides/k8s-monitoring-via-vm-cluster.md b/docs/guides/k8s-monitoring-via-vm-cluster.md
index 566ba7746..e05fd3e44 100644
--- a/docs/guides/k8s-monitoring-via-vm-cluster.md
+++ b/docs/guides/k8s-monitoring-via-vm-cluster.md
@@ -8,9 +8,6 @@ menu:
aliases:
- /guides/k8s-monitoring-via-vm-cluster.html
---
-# Kubernetes monitoring with VictoriaMetrics Cluster
-
-
**This guide covers:**
* The setup of a [VictoriaMetrics cluster](https://docs.victoriametrics.com/cluster-victoriametrics/) in [Kubernetes](https://kubernetes.io/) via Helm charts
@@ -26,7 +23,7 @@ We will use:
* [Helm 3 ](https://helm.sh/docs/intro/install)
* [kubectl 1.21](https://kubernetes.io/docs/tasks/tools/install-kubectl)
-
+
## 1. VictoriaMetrics Helm repository
@@ -506,19 +503,19 @@ kubectl --namespace default port-forward $POD_NAME 3000
To check that [VictoriaMetrics](https://victoriametrics.com) collects metrics from k8s cluster open in browser [http://127.0.0.1:3000/dashboards](http://127.0.0.1:3000/dashboards) and choose the `Kubernetes Cluster Monitoring (via Prometheus)` dashboard. Use `admin` for login and `password` that you previously got from kubectl.
-
+
You will see something like this:
-
+
The VictoriaMetrics dashboard is also available to use:
-
+
vmagent has its own dashboard:
-
+
## 6. Final thoughts
diff --git a/docs/guides/k8s-monitoring-via-vm-single.md b/docs/guides/k8s-monitoring-via-vm-single.md
index 5d4759b7a..414e6ee31 100644
--- a/docs/guides/k8s-monitoring-via-vm-single.md
+++ b/docs/guides/k8s-monitoring-via-vm-single.md
@@ -8,9 +8,6 @@ menu:
aliases:
- /guides/k8s-monitoring-via-vm-single.html
---
-# Kubernetes monitoring via VictoriaMetrics Single
-
-
**This guide covers:**
* The setup of a [VictoriaMetrics Single](https://docs.victoriametrics.com/single-server-victoriametrics/) in [Kubernetes](https://kubernetes.io/) via Helm charts
@@ -26,7 +23,7 @@ We will use:
* [Helm 3 ](https://helm.sh/docs/intro/install)
* [kubectl 1.21](https://kubernetes.io/docs/tasks/tools/install-kubectl)
-
+
## 1. VictoriaMetrics Helm repository
@@ -308,15 +305,15 @@ Now Grafana should be accessible on the [http://127.0.0.1:3000](http://127.0.0.1
To check that VictoriaMetrics has collects metrics from the k8s cluster open in browser [http://127.0.0.1:3000/dashboards](http://127.0.0.1:3000/dashboards) and choose `Kubernetes Cluster Monitoring (via Prometheus)` dashboard. Use `admin` for login and `password` that you previously obtained from kubectl.
-
+
You will see something like this:
-
+
VictoriaMetrics dashboard also available to use:
-
+
## 5. Final thoughts
diff --git a/docs/guides/migrate-from-influx.md b/docs/guides/migrate-from-influx.md
index efd900bde..998051edd 100644
--- a/docs/guides/migrate-from-influx.md
+++ b/docs/guides/migrate-from-influx.md
@@ -8,8 +8,6 @@ menu:
aliases:
- /guides/migrate-from-influx.html
---
-# Migrate from InfluxDB to VictoriaMetrics
-
InfluxDB is a well-known time series database built for
[IoT](https://en.wikipedia.org/wiki/Internet_of_things) monitoring, Application Performance Monitoring (APM) and
analytics. It has its query language, unique data model, and rich tooling for collecting and processing metrics.
@@ -142,7 +140,7 @@ for serving read queries. This API is used in various integrations such as
by [VMUI](https://docs.victoriametrics.com/single-server-victoriametrics/#vmui) - a graphical User Interface for
querying and visualizing metrics:
-
+
See more about [how to query data in VictoriaMetrics](https://docs.victoriametrics.com/keyconcepts/#query-data).
@@ -171,7 +169,7 @@ The data sample consists data points for a measurement `foo`
and a field `bar` with additional tag `instance=localhost`. If we would like plot this data as a time series in Grafana
it might have the following look:
-
+
The query used for this panel is written in
[InfluxQL](https://docs.influxdata.com/influxdb/v1.8/query_language/):
@@ -206,7 +204,7 @@ InfluxQL query might be translated to MetricsQL let's break it into components f
In result, executing the `foo_bar{instance="localhost"}` MetricsQL expression with `step=1m` for the same set of data in
Grafana will have the following form:
-
+
Visualizations from both databases are a bit different - VictoriaMetrics shows some extra points
filling the gaps in the graph. This behavior is described in more
diff --git a/docs/guides/multi-regional-setup-dedicated-regions.md b/docs/guides/multi-regional-setup-dedicated-regions.md
index aea278324..8b6c53843 100644
--- a/docs/guides/multi-regional-setup-dedicated-regions.md
+++ b/docs/guides/multi-regional-setup-dedicated-regions.md
@@ -8,15 +8,13 @@ menu:
aliases:
- /guides/multi-regional-setup-dedicated-regions.html
---
-# Multi-regional setup with VictoriaMetrics: Dedicated regions for monitoring
-
### Scenario
Let's cover the case. You have multiple regions with workloads and want to collect metrics.
The monitoring setup is in the dedicated regions as shown below:
-
+
Every workload region (Earth, Mars, Venus) has a vmagent that sends data to multiple regions with a monitoring setup.
The monitoring setup (Ground Control 1,2) contains VictoriaMetrics Time Series Database(TSDB) cluster or single.
diff --git a/docs/guides/understand-your-setup-size.md b/docs/guides/understand-your-setup-size.md
index 742116db1..93062c60f 100644
--- a/docs/guides/understand-your-setup-size.md
+++ b/docs/guides/understand-your-setup-size.md
@@ -8,8 +8,6 @@ menu:
aliases:
- /guides/understand-your-setup-size.html
---
-# Understand Your Setup Size
-
The docs provide a simple and high-level overview of Ingestion Rate, Active Time Series, and Query per Second. These terms are a part of capacity planning ([Single-Node](https://docs.victoriametrics.com/single-server-victoriametrics/#capacity-planning), [Cluster](https://docs.victoriametrics.com/cluster-victoriametrics/#capacity-planning)) and [Managed VictoriaMetrics](https://docs.victoriametrics.com/managed-victoriametrics/) pricing.
## Terminology
diff --git a/docs/keyConcepts.md b/docs/keyConcepts.md
index c44074116..b8d20dcca 100644
--- a/docs/keyConcepts.md
+++ b/docs/keyConcepts.md
@@ -10,9 +10,6 @@ aliases:
- /keyConcepts.html
- /keyсoncepts.html
---
-
-# Key concepts
-
## Data model
### What is a metric
@@ -138,7 +135,7 @@ So, the `counter` metric shows the number of observed events since the service s
In programming, `counter` is a variable that you **increment** each time something happens.
-
+
`vm_http_requests_total` is a typical example of a counter. The interpretation of a graph
above is that time series `vm_http_requests_total{instance="localhost:8428", job="victoriametrics", path="api/v1/query_range"}`
@@ -164,7 +161,7 @@ by humans from other metric types.
Gauge is used for measuring a value that can go up and down:
-
+
The metric `process_resident_memory_anon_bytes` on the graph shows the memory usage of the application at every given time.
It is changing frequently, going up and down showing how the process allocates and frees the memory.
@@ -262,7 +259,7 @@ Such a combination of `counter` metrics allows
plotting [Heatmaps in Grafana](https://grafana.com/docs/grafana/latest/visualizations/heatmap/)
and calculating [quantiles](https://prometheus.io/docs/practices/histograms/#quantiles):
-
+
Grafana doesn't understand buckets with `vmrange` labels, so the [prometheus_buckets](https://docs.victoriametrics.com/metricsql/#prometheus_buckets)
function must be used for converting buckets with `vmrange` labels to buckets with `le` labels before building heatmaps in Grafana.
@@ -304,7 +301,7 @@ go_gc_duration_seconds_count 83
The visualization of summaries is pretty straightforward:
-
+
Such an approach makes summaries easier to use but also puts significant limitations compared to [histograms](#histogram):
@@ -375,7 +372,7 @@ VictoriaMetrics supports both models used in modern monitoring applications: [pu
Client regularly sends the collected metrics to the server in the push model:
-
+
The client (application) decides when and where to send its metrics. VictoriaMetrics supports many protocols
for data ingestion (aka `push protocols`) - see [the full list here](https://docs.victoriametrics.com/#how-to-import-time-series-data).
@@ -420,7 +417,7 @@ The cons of push protocol:
Pull model is an approach popularized by [Prometheus](https://prometheus.io/), where the monitoring system decides when
and where to pull metrics from:
-
+
In pull model, the monitoring system needs to be aware of all the applications it needs to monitor. The metrics are
scraped (pulled) from the known applications (aka `scrape targets`) via HTTP protocol on a regular basis (aka `scrape_interval`).
@@ -451,7 +448,7 @@ models for data collection. Many installations use exclusively one of these mode
The most common approach for data collection is using both models:
-
+
In this approach the additional component is used - [vmagent](https://docs.victoriametrics.com/vmagent/). Vmagent is
a lightweight agent whose main purpose is to collect, filter, relabel and deliver metrics to VictoriaMetrics.
@@ -466,7 +463,7 @@ installation for querying collected data.
VictoriaMetrics components allow building more advanced topologies. For example, vmagents can push metrics from separate datacenters to the central VictoriaMetrics:
-
+
VictoriaMetrics in this example may be either [single-node VictoriaMetrics](https://docs.victoriametrics.com/single-server-victoriametrics/)
or [VictoriaMetrics Cluster](https://docs.victoriametrics.com/cluster-victoriametrics/). Vmagent also allows
@@ -530,7 +527,8 @@ foo_bar 4.00 1652170560000 # 2022-05-10 10:16:00
The data above contains a list of samples for the `foo_bar` time series with time intervals between samples
ranging from 1m to 3m. If we plot this data sample on the graph, it will have the following form:
-
+
+{width="500"}
To get the value of the `foo_bar` series at some specific moment of time, for example `2022-05-10 10:03:00`, in
VictoriaMetrics we need to issue an **instant query**:
@@ -564,7 +562,8 @@ In response, VictoriaMetrics returns a single sample-timestamp pair with a value
we'll see that there is no raw sample at `2022-05-10 10:03`. When there is no raw sample at the
requested timestamp, VictoriaMetrics will try to locate the closest sample before the requested timestamp:
-
+
+{width="500"}
The time range in which VictoriaMetrics will try to locate a replacement for a missing data sample is equal to `5m`
by default and can be overridden via the `step` parameter.
@@ -704,7 +703,8 @@ see that it contains only 13 raw samples. What happens here is that the range qu
an [instant query](#instant-query) executed `1 + (start-end)/step` times on the time range from `start` to `end`. If we plot
this request in VictoriaMetrics the graph will be shown as the following:
-
+
+{width="500"}
The blue dotted lines in the figure are the moments when the instant query was executed. Since the instant query retains the
ability to return replacements for missing points, the graph contains two types of data points: `real` and `ephemeral`.
@@ -745,12 +745,14 @@ This flag prevents from non-consistent results due to the fact that only part of
Here is an illustration of a potential problem when `-search.latencyOffset` is set to zero:
-
+
+{width="1000"}
When this flag is set, the VM will return the last metric value collected before the `-search.latencyOffset`
duration throughout the `-search.latencyOffset` duration:
-
+
+{width="1000"}
It can be overridden on per-query basis via `latency_offset` query arg.
@@ -948,7 +950,7 @@ VictoriaMetrics has a built-in graphical User Interface for querying and visuali
[VMUI](https://docs.victoriametrics.com/single-server-victoriametrics/#vmui).
Open `http://victoriametrics:8428/vmui` page, type the query and see the results:
-
+
VictoriaMetrics supports [Prometheus HTTP API](https://docs.victoriametrics.com/single-server-victoriametrics/#prometheus-querying-api-usage)
which makes it possible to [query it with Grafana](https://docs.victoriametrics.com/single-server-victoriametrics/#grafana-setup)
diff --git a/docs/managed-victoriametrics/alerting-vmalert-managed-victoria-metrics.md b/docs/managed-victoriametrics/alerting-vmalert-managed-victoria-metrics.md
index 865328c7f..f42ac24b5 100644
--- a/docs/managed-victoriametrics/alerting-vmalert-managed-victoria-metrics.md
+++ b/docs/managed-victoriametrics/alerting-vmalert-managed-victoria-metrics.md
@@ -9,11 +9,9 @@ menu:
aliases:
- /managed-victoriametrics/alerting-vmalert-managed-victoria-metrics.html
---
-# Alerting with vmalert and Managed VictoriaMetrics
-
This guide explains the different ways in which you can use vmalert in conjunction with Managed VictoriaMetrics
-
+
## Preconditions
@@ -55,14 +53,14 @@ For instructions on how to create tokens, please refer to this section of the [d
#### Single-Node
-
-
+
+
#### Cluster
-
-
-
+
+
+
### vmalert configuration
diff --git a/docs/managed-victoriametrics/alertmanager-setup-for-deployment.md b/docs/managed-victoriametrics/alertmanager-setup-for-deployment.md
index 4355f2007..255d05d4c 100644
--- a/docs/managed-victoriametrics/alertmanager-setup-for-deployment.md
+++ b/docs/managed-victoriametrics/alertmanager-setup-for-deployment.md
@@ -9,9 +9,6 @@ menu:
aliases:
- /managed-victoriametrics/alertmanager-setup-for-deployment.html
---
-
-# Alerting stack configuration and Managed VictoriaMetrics
-
Managed VictoriaMetrics supports configuring alerting rules, powered by vmalert, and sending notifications with hosted Alertmanager.
## Configure Alertmanager
@@ -19,9 +16,9 @@ Managed VictoriaMetrics supports configuring alerting rules, powered by vmalert,
You have two options to configure Cloud Alertmanager:
1. From integrations section: Menu **"Integrations" `->` "Cloud Alertmanager" `->` "New configuration"**:
- 
+ 
2. From deployment page: **"Deployment page" `->` "Rules" tab `->` "Settings" `->` "Connect notifier" `/` "New notifier"**:
- 
+ 
For creating a new configuration, you need to provide the following parameters:
@@ -34,7 +31,7 @@ After creating the configuration, you can connect it to one or multiple deployme
In order to do this you need to go to the "Deployment page" `->` "Rules" tab `->` "Settings" `,
select the created notifier and confirm the action:
-
+
Alertmanager is now set up for your deployment, and you be able to get notifications from it.
@@ -129,7 +126,7 @@ If for some reason Cloud Alertmanager is not suitable for you, you can use Manag
For that select Custom Alertmanager instead of Cloud Alertmanager when [creating the Alertmanager](#configure-alertmanager):
-
+
Limitations for the Custom Alertmanager:
@@ -143,7 +140,7 @@ You can test the connection to your custom Alertmanager by clicking the "Test co
Alerting and recording rules could be uploaded on **"Deployment page" `->` "Rules" tab `->` "Settings"**:
-
+
You can click on the upload area or drag and drop the files with rules there.
@@ -161,7 +158,7 @@ You can also use API for uploading rules. Switch to **"Upload with API"** on the
- Choose the API key for uploading rules
- After that you can copy the curl command for uploading rules and execute it in your terminal
-
+
You can use the following API endpoints for the automation with rules:
@@ -202,13 +199,13 @@ groups:
The state of created rules is located in the `Rules` section of your deployment:
-
+
### Debug
It's possible to debug the alerting stack with logs for vmalert and Alertmanager, which are accessible in the `Logs` section of the deployment.
-
+
### Monitoring
diff --git a/docs/managed-victoriametrics/how-to-monitor-k8s.md b/docs/managed-victoriametrics/how-to-monitor-k8s.md
index 85ae7ef1a..410981f1c 100644
--- a/docs/managed-victoriametrics/how-to-monitor-k8s.md
+++ b/docs/managed-victoriametrics/how-to-monitor-k8s.md
@@ -9,8 +9,6 @@ menu:
aliases:
- /managed-victoriametrics/how-to-monitor-k8s.html
---
-# Kubernetes Monitoring with Managed VictoriaMetrics
-
Monitoring kubernetes cluster is necessary to build SLO/SLI, to analyze performance and cost-efficiency of your workloads.
To enable kubernetes cluster monitoring, we will be collecting metrics about cluster performance and utilization from kubernetes components like `kube-api-server`, `kube-controller-manager`, `kube-scheduler`, `kube-state-metrics`, `etcd`, `core-dns`, `kubelet` and `kube-proxy`. We will also install some recording rules, alert rules and dashboards to provide visibility of cluster performance, as well as alerting for cluster metrics.
@@ -47,7 +45,7 @@ Install the Helm chart in a custom namespace
```
You can find your access token on the "Access" tab of your deployment
- 
+ 
1. Set up a Helm repository using the following commands:
```shell
@@ -129,7 +127,7 @@ Connect to grafana and create your datasource
Choose VictoriaMetrics or Prometheus as datasource type. Make sure you made this datasource as default for dashboards to work.
> You can find token and URL in your deployment, on Access tab
- 
+ 
## Test it
diff --git a/docs/managed-victoriametrics/overview.md b/docs/managed-victoriametrics/overview.md
index d18ae16a4..32401e875 100644
--- a/docs/managed-victoriametrics/overview.md
+++ b/docs/managed-victoriametrics/overview.md
@@ -9,9 +9,6 @@ menu:
aliases:
- /managed-victoriametrics/overview.html
---
-
-# Overview of Managed VictoriaMetrics
-
VictoriaMetrics is a fast and easy-to-use monitoring solution and time series database.
It integrates well with existing monitoring systems such as Grafana, Prometheus, Graphite,
InfluxDB, OpenTSDB and DataDog - see [these docs](https://docs.victoriametrics.com/#how-to-import-time-series-data) for details.
diff --git a/docs/managed-victoriametrics/quickstart.md b/docs/managed-victoriametrics/quickstart.md
index c853e1e45..86f1587ce 100644
--- a/docs/managed-victoriametrics/quickstart.md
+++ b/docs/managed-victoriametrics/quickstart.md
@@ -9,8 +9,6 @@ menu:
aliases:
- /managed-victoriametrics/quickstart.html
---
-# Quick Start
-
Managed VictoriaMetrics is a hosted monitoring platform, where users can run the VictoriaMetrics
that they know and love on AWS without the need to perform typical DevOps tasks such as proper configuration,
monitoring, logs collection, access protection, software updates, backups, etc.
@@ -34,66 +32,66 @@ There are two different methods to create an account:
### Create an account via Google Auth service:
1. Click `Continue with Google` button on the [Sign Up page](https://cloud.victoriametrics.com/signUp?utm_source=website&utm_campaign=docs_quickstart)
-
+
1. Choose Google account you want to use for registration
-
+
1. You will be automatically redirected to the main page of the Managed VictoriaMetrics
-
+
### Create an account by filling in a registration form:
1. Fill in your email, password and password confirmation on [Sign Up page](https://cloud.victoriametrics.com/signUp?utm_source=website&utm_campaign=docs_quickstart).
-
+
1.All fields are required. Any errors will be shown in the interface, so it is easy to understand what should be adjusted.
- 
+ 
1. Press `Create account` button when all fields are filled in.
- 
+ 
You will be redirected to the main page with a notification message to confirm your email.
-
+ 
You will also receive an email with a confirmation link as shown on the picture below:
- 
+ 
It is necessary to confirm your email address. Otherwise, you won't be able to create a deployment.
After successful confirmation of your email address, you'll be able to [create your first deployment](#creating-deployments) or [add a payment method](#adding-a-payment-method).
- 
+ 
## Adding a payment method
1. Navigate to a [Billing](https://cloud.victoriametrics.com/billing?utm_source=website&utm_campaign=docs_quickstart) page or click on `Upgrade` button as shown below:
- 
+ 
1. Choose a payment method
- 
+ 
### Pay with a card
1. Click on an `Add card` panel and fill in all the fields in the form and press `Add card` button
- 
+ 
1. An error message will appear if a card us invalid
- 
+ 
1. Successfully added card will be shown on the page as follows:
- 
+ 
### Link your AWS billing account via AWS Marketplace
@@ -102,28 +100,28 @@ When you need to unify your AWS billing, you can start a subscription on AWS Mar
1. Click on the `Buy on AWS Marketplace` panel:
- 
+ 
1. You will be redirected to the Managed VictoriaMetrics product page.
1. Click on `View purchase option` button, and you will be redirected to an AWS login page or to a subscribe page on AWS Marketplace.
- 
+ 
1. Go to the Managed VictoriaMetrics product page and click `Continue to Subscribe` button:
- 
+ 
1. Press the `Subscribe` button:
- 
+ 
1. After that you will see a success message where you should click `Set up your account` button:
- 
+ 
1. You'll be redirected back to Managed VictoriaMetrics billing page:
- 
+ 
### Switching between payment methods
@@ -132,17 +130,17 @@ If both payment methods are added, it is possible to easily switch between them.
Click on the radio button like on the picture below and confirm the change:
- 
+ 
- 
+ 
If the payment method was changed successfully, the following message will appear:
- 
+ 
## Password restoration
@@ -151,31 +149,31 @@ If you forgot your password, it can be restored in the following way:
1. Click `Forgot password?` link on the [Sign In](https://cloud.victoriametrics.com/signIn?utm_source=website&utm_campaign=docs_quickstart) page:
- 
+ 
1. Enter your email and click `Reset password` button:
- 
+ 
- 
+ 
1. Follow the instructions sent to your email in order to get access to your Managed VictoriaMetrics account:
- 
+ 
1. Navigate to the Profile page by clicking the corresponding link in the top right corner:
- 
+ 
1. Enter a new password on the Profile page and press `Save`:
- 
+ 
## Creating deployments
@@ -186,11 +184,11 @@ will see a list of your existing deployments and will be able to manage them.
To create a deployment click on the button `Start sending metrics` button:
- 
+ 
When you already have at least one deployment you can create a new one by clicking on the `Create deployment` button:
- 
+ 
On the opened screen, choose parameters of your new deployment:
@@ -204,7 +202,7 @@ On the opened screen, choose parameters of your new deployment:
* `Size` of your deployment [based on your needs](https://docs.victoriametrics.com/guides/understand-your-setup-size.html)
- 
+ 
When all parameters are configured, click on the `Create` button, and deployment will be created.
@@ -214,11 +212,11 @@ while the hardware spins-up, just wait for a couple of minutes and reload the pa
You'll also be notified via email once your deployment is ready to use:
- 
+ 
- 
+ 
## Start writing and reading data
@@ -229,7 +227,7 @@ and is ready to accept write and read requests.
Click on deployment name and navigate to the Access tab to get the access token:
- 
+ 
Access tokens are used in token-based authentication to allow an application to access the VictoriaMetrics API.
@@ -237,11 +235,11 @@ Supported token types are `Read-Only`, `Write-Only` and `Read-Write`. Click on t
to see usage examples:
- 
+ 
- 
+ 
Follow usage examples in order to configure access to VictoriaMetrics for your Prometheus,
@@ -254,13 +252,13 @@ deployment's page.
It is important to know that downgrade for cluster is currently not available.
- 
+ 
To discover additional configuration options click on `Advanced Settings` button, so you should see the following:
- 
+ 
In that section, additional params can be set:
diff --git a/docs/managed-victoriametrics/setup-notifications.md b/docs/managed-victoriametrics/setup-notifications.md
index b49b7ec90..c09dc7701 100644
--- a/docs/managed-victoriametrics/setup-notifications.md
+++ b/docs/managed-victoriametrics/setup-notifications.md
@@ -9,8 +9,6 @@ menu:
aliases:
- /managed-victoriametrics/setup-notifications.html
---
-# Notifications in Managed VictoriaMetrics
-
The guide covers how to enable email and Slack notifications.
Table of content:
@@ -21,7 +19,7 @@ Table of content:
When you enter the notification section, you will be able to fill in the channels in which you
want to receive notifications
-
+
## Setup Slack notifications
@@ -29,22 +27,22 @@ want to receive notifications
How to do this is indicated on the following link
https://api.slack.com/messaging/webhooks
-
+ 
1. Specify Slack channels
Enter one or more channels into input and press enter or choose it after each input.
- 
- 
+ 
+ 
## Setup emails notifications
You can specify one or multiple emails for notifications in the input field. By default,
email notifications are enabled for the account owner
- 
- 
+ 
+ 
## Send test notification
@@ -55,18 +53,18 @@ If only Slack channels and webhook are specified correctly, you will receive the
If only the emails are specified, you will receive notifications to those emails.
When both notifications are specified, all notifications will be sent to Slack channels and emails.
- 
+ 
If the Save button is pressed, then entered channels will be only saved, and you get a success message.
If the Save and Test button is pressed, then all entered information will be saved,
and test notifications will be sent to the entered channels
- 
+ 
Examples of the test notification messages:
- 
+ 
- 
+ 
diff --git a/docs/managed-victoriametrics/user-managment.md b/docs/managed-victoriametrics/user-managment.md
index 8e7011c44..41e22ca24 100644
--- a/docs/managed-victoriametrics/user-managment.md
+++ b/docs/managed-victoriametrics/user-managment.md
@@ -9,8 +9,6 @@ menu:
aliases:
- /managed-victoriametrics/user-management.html
---
-# User Management in Managed VictoriaMetrics
-
The user management system enables admins to control user access and onboard and offboard users to the Managed VictoriaMetrics. It organizes users according to their needs and role.
The document covers the following topics
@@ -29,7 +27,7 @@ You assign the role to the user during the user creation procedure. You can chan
### Roles definition
-| User Role | Categories | @@ -85,7 +83,7 @@ You assign the role to the user during the user creation procedure. You can chan ### User statuses -
| Active | The user can log in and use Managed VictoriaMetrics. The user role defines the access level. | @@ -105,12 +103,12 @@ You assign the role to the user during the user creation procedure. You can chan It shows all users with different roles, and you can apply provided actions with them. -
| Email: | Registration user email | @@ -138,7 +136,7 @@ In the table, there is additional information about the users: Click on `Invite user` button the user invitation button and fill out the form in the modal, which will appear after you click. All fields are mandatory. -
+
In the table, there is additional information about the users:
-
+
After filling out the form, click on the `Invite` button.
The user will be saved, and an invitation email to the provided email address will be sent. As a confirmation, you will see the success message.
@@ -148,7 +146,7 @@ The user will be saved, and an invitation email to the provided email address wi
The user will be at Pending Invitation status. After accepting the invitation user status changes to Active.
-
+
## How to Update User
@@ -156,17 +154,17 @@ The user will be at Pending Invitation status. After accepting the invitation us
To edit the user role and details, activate or deactivate a user, and click on
-
+
or `user email` to edit the user.
User editing form:
-
+
To save changes, click the `Save changes` button. If changes are saved successfully, you will see a message at the top of the page.
-
+
## How to Delete User
@@ -174,15 +172,15 @@ You can delete a user from your account. However, you will need to invite them a
Click on `Delete` button to delete the user.
-
+
To confirm the deletion of a user, you will need to re-enter their email address and press the **Delete** button
-
+
You will be redirected to the main page with a success or error message
-
+
## How to resend invitation
@@ -190,12 +188,12 @@ If the invitation is expired, it is possible to resend email to the user
Click `Resend invitation` button
-
+
Confirm resend invitation by clicking `Resend` button in the modal dialog
-
+
If invitation successfully resented to the user success message will appear
-
+
diff --git a/docs/relabeling.md b/docs/relabeling.md
index ff29ae5c8..0c95ab192 100644
--- a/docs/relabeling.md
+++ b/docs/relabeling.md
@@ -9,9 +9,6 @@ menu:
aliases:
- /relabeling.html
---
-
-# Relabeling cookbook
-
VictoriaMetrics and [vmagent](https://docs.victoriametrics.com/vmagent/) support
[Prometheus-compatible relabeling](https://docs.victoriametrics.com/vmagent/#relabeling)
with [additional enhancements](https://docs.victoriametrics.com/vmagent/#relabeling-enhancements).
diff --git a/docs/scrape_config_examples.md b/docs/scrape_config_examples.md
index 62c723ef2..d11037985 100644
--- a/docs/scrape_config_examples.md
+++ b/docs/scrape_config_examples.md
@@ -9,9 +9,6 @@ menu:
aliases:
- /scrape_config_examples.html
---
-
-# Scrape config examples
-
- [Static configs](#static-configs)
- [File-based target discovery](#file-based-target-discovery)
- [HTTP-based target discovery](#http-based-target-discovery)
diff --git a/docs/sd_configs.md b/docs/sd_configs.md
index e829ff703..d6aca9f37 100644
--- a/docs/sd_configs.md
+++ b/docs/sd_configs.md
@@ -9,9 +9,6 @@ menu:
aliases:
- /sd_configs.html
---
-
-# Prometheus service discovery
-
# Supported service discovery configs
[vmagent](https://docs.victoriametrics.com/vmagent/) and [single-node VictoriaMetrics](https://docs.victoriametrics.com/#how-to-scrape-prometheus-exporters-such-as-node-exporter)
diff --git a/docs/stream-aggregation.md b/docs/stream-aggregation.md
index a3d3e1029..042e3e52b 100644
--- a/docs/stream-aggregation.md
+++ b/docs/stream-aggregation.md
@@ -9,9 +9,6 @@ menu:
aliases:
- /stream-aggregation.html
---
-
-# Streaming aggregation
-
[vmagent](https://docs.victoriametrics.com/vmagent/) and [single-node VictoriaMetrics](https://docs.victoriametrics.com/single-server-victoriametrics/)
can aggregate incoming [samples](https://docs.victoriametrics.com/keyconcepts/#raw-samples) in streaming mode by time and by labels before data is written to remote storage
(or local storage for single-node VictoriaMetrics).
@@ -589,7 +586,7 @@ sum(sum_over_time(some_metric[interval])) / sum(count_over_time(some_metric[inte
For example, see below time series produced by config with aggregation interval `1m` and `by: ["instance"]` and the regular query:
-
+
See also:
@@ -669,7 +666,7 @@ then take a look at [increase_prometheus](#increase_prometheus).
For example, see below time series produced by config with aggregation interval `1m` and `by: ["instance"]` and the regular query:
-
+
Aggregating irregular and sporadic metrics (received from [Lambdas](https://aws.amazon.com/lambda/)
or [Cloud Functions](https://cloud.google.com/functions)) can be controlled via [staleness_interval](#staleness) option.
@@ -735,7 +732,7 @@ max(max_over_time(some_metric[interval]))
For example, see below time series produced by config with aggregation interval `1m` and the regular query:
-
+
See also:
@@ -756,7 +753,7 @@ min(min_over_time(some_metric[interval]))
For example, see below time series produced by config with aggregation interval `1m` and the regular query:
-
+
See also:
@@ -831,7 +828,7 @@ histogram_stdvar(sum(histogram_over_time(some_metric[interval])) by (vmrange))
For example, see below time series produced by config with aggregation interval `1m` and the regular query:
-
+
See also:
@@ -852,7 +849,7 @@ sum(sum_over_time(some_metric[interval]))
For example, see below time series produced by config with aggregation interval `1m` and the regular query:
-
+
See also:
@@ -876,7 +873,7 @@ then take a look at [total_prometheus](#total_prometheus).
For example, see below time series produced by config with aggregation interval `1m` and `by: ["instance"]` and the regular query:
-
+
`total` is not affected by [counter resets](https://docs.victoriametrics.com/keyconcepts/#counter) -
it continues to increase monotonically with respect to the previous value.
@@ -884,7 +881,7 @@ The counters are most often reset when the application is restarted.
For example:
-
+
The same behavior occurs when creating or deleting new series in an aggregation group -
`total` output increases monotonically considering the values of the series set.
diff --git a/docs/url-examples.md b/docs/url-examples.md
index 9b6895422..8e1d8c516 100644
--- a/docs/url-examples.md
+++ b/docs/url-examples.md
@@ -10,9 +10,6 @@ menu:
aliases:
- /url-examples.html
---
-
-# VictoriaMetrics API examples
-
### /api/v1/admin/tsdb/delete_series
**Deletes time series from VictoriaMetrics**
diff --git a/docs/victoriametrics-datasource.md b/docs/victoriametrics-datasource.md
index dde434b6e..82fb3f9b2 100644
--- a/docs/victoriametrics-datasource.md
+++ b/docs/victoriametrics-datasource.md
@@ -13,9 +13,6 @@ aliases:
- /grafana-datasource/
- /grafana-datasource.html
---
-
-# VictoriaMetrics datasource for Grafana
-
The [VictoriaMetrics datasource plugin](https://github.com/VictoriaMetrics/victoriametrics-datasource)
allows to query and visualize data from VictoriaMetrics in Grafana.
@@ -140,7 +137,8 @@ docker-compose -f docker-compose.yaml up
When Grafana starts successfully datasources should be present on the datasources tab
-
+
+{width="800"}
### Install in Kubernetes
diff --git a/docs/vmagent.md b/docs/vmagent.md
index 20851a128..62461a910 100644
--- a/docs/vmagent.md
+++ b/docs/vmagent.md
@@ -9,8 +9,6 @@ title: vmagent
aliases:
- /vmagent.html
---
-# vmagent
-
`vmagent` is a tiny agent which helps you collect metrics from various sources,
[relabel and filter the collected metrics](#relabeling)
and store them in [VictoriaMetrics](https://github.com/VictoriaMetrics/VictoriaMetrics)
@@ -19,7 +17,7 @@ or via [VictoriaMetrics `remote_write` protocol](#victoriametrics-remote-write-p
See [Quick Start](#quick-start) for details.
-
+
## Motivation
diff --git a/docs/vmalert-tool.md b/docs/vmalert-tool.md
index 529084494..83c9f0656 100644
--- a/docs/vmalert-tool.md
+++ b/docs/vmalert-tool.md
@@ -9,9 +9,6 @@ title: vmalert-tool
aliases:
- /vmalert-tool.html
---
-
-# vmalert-tool
-
VMAlert command-line tool
## Unit testing for rules
diff --git a/docs/vmalert.md b/docs/vmalert.md
index b1f5dce73..34d3aa8df 100644
--- a/docs/vmalert.md
+++ b/docs/vmalert.md
@@ -9,8 +9,6 @@ title: vmalert
aliases:
- /vmalert.html
---
-# vmalert
-
`vmalert` executes a list of the given [alerting](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)
or [recording](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/)
rules against configured `-datasource.url` compatible with Prometheus HTTP API. For sending alerting notifications
@@ -541,7 +539,8 @@ rules execution, storing recording rules results and alerts state.
-notifier.url=http://alertmanager:9093 # AlertManager addr to send alerts when they trigger
```
-
+
+{width="500"}
#### Cluster VictoriaMetrics
@@ -561,7 +560,7 @@ Cluster mode could have multiple `vminsert` and `vmselect` components.
-notifier.url=http://alertmanager:9093 # AlertManager addr to send alerts when they trigger
```
-
+
In case when you want to spread the load on these components - add balancers before them and configure
`vmalert` with balancer addresses. Please, see more about VM's cluster architecture
@@ -585,7 +584,8 @@ Alertmanagers.
-notifier.url=http://alertmanagerN:9093 # The same alert will be sent to all configured notifiers
```
-
+
+{width="800px"}
To avoid recording rules results and alerts state duplication in VictoriaMetrics server
don't forget to configure [deduplication](https://docs.victoriametrics.com/single-server-victoriametrics/#deduplication).
@@ -661,7 +661,7 @@ or reducing resolution) and push results to "cold" cluster.
-remoteWrite.url=http://aggregated-cluster-vminsert:8480/insert/0/prometheus # vminsert addr to persist recording rules results
```
-
+
Please note, [replay](#rules-backfilling) feature may be used for transforming historical data.
@@ -675,7 +675,7 @@ For persisting recording or alerting rule results `vmalert` requires `-remoteWri
But this flag supports only one destination. To persist rule results to multiple destinations
we recommend using [vmagent](https://docs.victoriametrics.com/vmagent/) as fan-out proxy:
-
+
In this topology, `vmalert` is configured to persist rule results to `vmagent`. And `vmagent`
is configured to fan-out received data to two or more destinations.
@@ -848,12 +848,12 @@ Data delay is one of the most common issues with rules execution.
vmalert executes configured rules within certain intervals at specifics timestamps.
It expects that the data is already present in configured `-datasource.url` at the moment of time when rule is executed:
-
+
Usually, troubles start to appear when data in `-datasource.url` is delayed or absent. In such cases, evaluations
may get empty response from the datasource and produce empty recording rules or reset alerts state:
-
+
Try the following recommendations to reduce the chance of hitting the data delay issue:
* Always configure group's `-evaluationInterval` to be bigger or at least equal to
@@ -893,7 +893,7 @@ state updates for each rule starting from [v1.86](https://docs.victoriametrics.c
To check updates, click on `Details` link next to rule's name on `/vmalert/groups` page
and check the `Last updates` section:
-
+
Rows in the section represent ordered rule evaluations and their results. The column `curl` contains an example of
HTTP request sent by vmalert to the `-datasource.url` during evaluation. If specific state shows that there were
@@ -905,7 +905,7 @@ for more details.
vmalert allows configuring more detailed logging for specific alerting rule starting from [v1.82](https://docs.victoriametrics.com/changelog/#v1820).
Just set `debug: true` in rule's configuration and vmalert will start printing additional log messages:
-```terminal
+```shell-session
2022-09-15T13:35:41.155Z DEBUG rule "TestGroup":"Conns" (2601299393013563564) at 2022-09-15T15:35:41+02:00: query returned 0 samples (elapsed: 5.896041ms)
2022-09-15T13:35:56.149Z DEBUG datasource request: executing POST request with params "denyPartialResponse=true&query=sum%28vm_tcplistener_conns%7Binstance%3D%22localhost%3A8429%22%7D%29+by%28instance%29+%3E+0&step=15s&time=1663248945"
2022-09-15T13:35:56.178Z DEBUG rule "TestGroup":"Conns" (2601299393013563564) at 2022-09-15T15:35:56+02:00: query returned 1 samples (elapsed: 28.368208ms)
diff --git a/docs/vmauth.md b/docs/vmauth.md
index 8408eefb3..139a91998 100644
--- a/docs/vmauth.md
+++ b/docs/vmauth.md
@@ -9,8 +9,6 @@ title: vmauth
aliases:
- /vmauth.html
---
-# vmauth
-
`vmauth` is an HTTP proxy, which can [authorize](https://docs.victoriametrics.com/vmauth/#authorization), [route](https://docs.victoriametrics.com/vmauth/#routing)
and [load balance](https://docs.victoriametrics.com/vmauth/#load-balancing) requests across [VictoriaMetrics](https://github.com/VictoriaMetrics/VictoriaMetrics) components
or any other HTTP backends.
diff --git a/docs/vmbackup.md b/docs/vmbackup.md
index f4d2c674c..a3b42f9d9 100644
--- a/docs/vmbackup.md
+++ b/docs/vmbackup.md
@@ -9,8 +9,6 @@ title: vmbackup
aliases:
- /vmbackup.html
---
-# vmbackup
-
`vmbackup` creates VictoriaMetrics data backups from [instant snapshots](https://docs.victoriametrics.com/single-server-victoriametrics/#how-to-work-with-snapshots).
`vmbackup` supports incremental and full backups. Incremental backups are created automatically if the destination path already contains data from the previous backup.
diff --git a/docs/vmbackupmanager.md b/docs/vmbackupmanager.md
index fecbe199b..316ca07ab 100644
--- a/docs/vmbackupmanager.md
+++ b/docs/vmbackupmanager.md
@@ -117,11 +117,11 @@ The result on the GCS bucket
* The root folder
- 
+ 
* The latest folder
- 
+ 
`vmbackupmanager` uses [smart backups](https://docs.victoriametrics.com/vmbackup/#smart-backups) technique in order
to accelerate backups and save both data transfer costs and data copying costs. This includes server-side copy of already existing
@@ -147,7 +147,7 @@ Backup retention policy is controlled by:
Let’s assume we have a backup manager collecting daily backups for the past 10 days.
-
+
We enable backup retention policy for backup manager by using following configuration:
@@ -172,7 +172,7 @@ info app/vmbackupmanager/retention.go:106 daily backups to delete [daily/2
The result on the GCS bucket. We see only 3 daily backups:
-
+[retention policy daily after retention cycle](vmbackupmanager_rp_daily_2.webp "retention policy daily after retention cycle")
### Protection backups against deletion by retention policy
diff --git a/docs/vmctl.md b/docs/vmctl.md
index 51d2057a0..ae3ca8974 100644
--- a/docs/vmctl.md
+++ b/docs/vmctl.md
@@ -9,8 +9,6 @@ title: vmctl
aliases:
- /vmctl.html
---
-# vmctl
-
VictoriaMetrics command-line tool (vmctl) provides the following list of actions:
- migrate data from [Prometheus](#migrating-data-from-prometheus) to VictoriaMetrics using snapshot API
- migrate data from [Thanos](#migrating-data-from-thanos) to VictoriaMetrics
diff --git a/docs/vmgateway.md b/docs/vmgateway.md
index a9f89b867..8fde485ad 100644
--- a/docs/vmgateway.md
+++ b/docs/vmgateway.md
@@ -9,13 +9,11 @@ title: vmgateway
aliases:
- /vmgateway.html
---
-# vmgateway
-
***vmgateway is a part of [enterprise package](https://docs.victoriametrics.com/enterprise/).
It is available for download and evaluation at [releases page](https://github.com/VictoriaMetrics/VictoriaMetrics/releases/latest).
See how to request a free trial license [here](https://victoriametrics.com/products/enterprise/trial/).***
-
+
`vmgateway` is a proxy for the VictoriaMetrics Time Series Database (TSDB). It provides the following features:
@@ -30,7 +28,7 @@ See how to request a free trial license [here](https://victoriametrics.com/produ
## Access Control
-
+
`vmgateway` supports jwt based authentication. With jwt payload can be configured to give access to specific tenants and labels as well as to read/write.
@@ -95,7 +93,7 @@ curl 'http://localhost:8431/api/v1/series/count' -H 'Authorization: Bearer incor
## Rate Limiter
-
+
Limits incoming requests by given, pre-configured limits. It supports read and write limiting by tenant.
diff --git a/docs/vmrestore.md b/docs/vmrestore.md
index 040c313d7..a0f4877fe 100644
--- a/docs/vmrestore.md
+++ b/docs/vmrestore.md
@@ -9,8 +9,6 @@ title: vmrestore
aliases:
- /vmrestore.html
---
-# vmrestore
-
`vmrestore` restores data from backups created by [vmbackup](https://docs.victoriametrics.com/vmbackup/).
Restore process can be interrupted at any time. It is automatically resumed from the interruption point