For a broader overview please visit the navigation page.
How to install and run vmanomaly #
To run vmanomaly
, you need to have VictoriaMetrics Enterprise license. You can get a trial license key here.
The following options are available:
Note: There is a mode
Available from v1.13.0
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. Similar optimization
Available from v1.16.0
can be set for data read from VictoriaMetrics TSDB. See instructions here.
Command-line arguments #
The vmanomaly
service supports several command-line arguments to configure its behavior, including options for licensing, logging levels, and more. These arguments can be passed when starting the service via Docker or any other setup. Below is the list of available options:
Note: vmanomaly
support
Available from v1.18.5
running on config directories, see the config
positional arg description in help message below.
|
|
You can specify these options when running vmanomaly
to fine-tune logging levels or handle licensing configurations, as per your requirements.
Licensing #
The license key can be passed via the following command-line flags: --license
, --licenseFile
, --license.forceOffline
In order to make it easier to monitor the license expiration date, the following metrics are exposed(see Monitoring section for details on how to scrape them):
|
|
Example alerts for vmalert:
|
|
Docker #
To run vmanomaly
, you need to have VictoriaMetrics Enterprise license. You can get a trial license key here.
Due to the upcoming DockerHub pull limits, an additional image registry, Quay.io, has been introduced for VictoriaMetrics images, including vmanomaly
. If you encounter pull rate limits, switch from:
|
|
to:
|
|
Below are the steps to get vmanomaly
up and running inside a Docker container:
- Pull Docker image:
|
|
- (Optional step) tag the
vmanomaly
Docker image:
|
|
- Start the
vmanomaly
Docker container with a license file, use the command below. Make sure to replaceYOUR_LICENSE_FILE_PATH
, andYOUR_CONFIG_FILE_PATH
with your specific details:
|
|
In case you found PermissionError: [Errno 13] Permission denied:
in vmanomaly
logs, set user/user group to 1000 in the run command above / in a docker-compose file:
|
|
|
|
For a complete docker-compose example please refer to our alerting guide, chapter docker-compose
See also:
- Verify the license online OR offline. See the details here.
- How to configure
vmanomaly
Kubernetes with Helm charts #
To run vmanomaly
, you need to have VictoriaMetrics Enterprise license. You can get a trial license key here.
With the forthcoming DockerHub pull limits additional image registry was introduced (quay.io) for VictoriaMetric images, vmanomaly images in particular.
If hitting pull limits, try switching your docker pull quay.io/victoriametrics/vmanomaly:vX.Y.Z
to docker pull quay.io/victoriametrics/vmanomaly:vX.Y.Z
You can run vmanomaly
in Kubernetes environment
with these Helm charts.
How to configure vmanomaly #
To run vmanomaly
you need to set up configuration file in yaml
format.
Here is an example of config file that will run Facebook Prophet model, that will be retrained every 2 hours on 14 days of previous data. It will generate inference metrics (including anomaly_score
) every 1 minute.
|
|
Recommended steps #
Schedulers:
- Configure the inference frequency in the scheduler section of the configuration file.
- Ensure that
infer_every
aligns with your minimum required alerting frequency.- For example, if receiving alerts every 15 minutes is sufficient (when
anomaly_score > 1
), setinfer_every
to matchreader.sampling_period
or override it per query viareader.queries.query_xxx.step
for an optimal setup.
- For example, if receiving alerts every 15 minutes is sufficient (when
Reader:
- Setup the datasource to read data from in the reader section. Include tenant ID if using a cluster version of VictoriaMetrics (
multitenant
value Available from v1.16.2 can be also used here). - Define queries for input data using MetricsQL under
reader.queries
section. Note, it’s possible to override reader-level arguments at query level for increased flexibility, e.g. specifying per-query timezone, data frequency, data range, etc.
Writer:
- Specify where and how to store anomaly detection metrics in the writer section.
- Include tenant ID if using a cluster version of VictoriaMetrics for writing the results.
- Adding
for
label tometric_format
argument is recommended for smoother visual experience in the anomaly score dashboard. Please refer tometric_format
argument description here.
Models:
- Configure built-in models parameters according to your needs in the models section. Where possible, incorporate domain knowledge for optimal results.
- (Optional) Develop or integrate your custom models with
vmanomaly
. - Adding
y
toprovide_series
arg values is recommended for smoother visual experience in the anomaly score dashboard. Also, othervmanomaly
output can be used inprovide_series
.
Note: Only univariate models support the generation of such output.
Check also #
Here are the links for further deep dive into Anomaly Detection in general and vmanomaly
in particular: