mirror of
https://github.com/VictoriaMetrics/VictoriaMetrics.git
synced 2024-12-04 16:51:11 +01:00
docs/vmanomaly - release v1.18.7 (#7719)
### Describe Your Changes - docs/vmanomaly - release v1.18.7 - modified table markdown for proper rendering on vmanomaly component pages ### Checklist The following checks are **mandatory**: - [x] My change adheres [VictoriaMetrics contributing guidelines](https://docs.victoriametrics.com/contributing/).
This commit is contained in:
parent
c89926bdf7
commit
cdf384eb4d
@ -72,7 +72,7 @@ services:
|
||||
restart: always
|
||||
vmanomaly:
|
||||
container_name: vmanomaly
|
||||
image: victoriametrics/vmanomaly:v1.18.6
|
||||
image: victoriametrics/vmanomaly:v1.18.7
|
||||
depends_on:
|
||||
- "victoriametrics"
|
||||
ports:
|
||||
|
@ -11,15 +11,26 @@ aliases:
|
||||
---
|
||||
Please find the changelog for VictoriaMetrics Anomaly Detection below.
|
||||
|
||||
## v1.18.7
|
||||
Released: 2024-12-02
|
||||
|
||||
- IMPROVEMENT: Introduced a new `push_frequency` parameter for the [monitoring.push component](https://docs.victoriametrics.com/anomaly-detection/components/monitoring/#push-config-parameters), with a default value of 15m. This enhancement ensures better alignment with pull-based monitoring behavior and improves [self-monitoring experience](https://docs.victoriametrics.com/anomaly-detection/self-monitoring) of `vmanomaly` in setups with infrequent schedules (e.g., rare `fit_every` or `infer_every` intervals) to deal with data staleness.
|
||||
|
||||
- FIX: Fixed a bug, introduced in [v1.18.5](#v1185), that prevented the [monitoring.push component](https://docs.victoriametrics.com/anomaly-detection/components/monitoring/#push-config-parameters) from properly instantiating and pushing [self-monitoring metrics](https://docs.victoriametrics.com/anomaly-detection/components/monitoring/#metrics-generated-by-vmanomaly).
|
||||
|
||||
## v1.18.6
|
||||
Released: 2024-12-01
|
||||
|
||||
> **Note**: Release [v1.18.5](#v1185) contained an issue that prevented the [monitoring.push component](https://docs.victoriametrics.com/anomaly-detection/components/monitoring/#push-config-parameters) from properly instantiating and pushing [self-monitoring metrics](https://docs.victoriametrics.com/anomaly-detection/components/monitoring/#metrics-generated-by-vmanomaly). This issue has been resolved in patch [v1.18.7](#v1187), please update to apply the fix.
|
||||
|
||||
- FIX: Assure proper validation of [BacktestingScheduler](https://docs.victoriametrics.com/anomaly-detection/components/scheduler/#backtesting-scheduler) arguments, if specified in ISO-8601 format, preventing service crashes due to validation errors.
|
||||
|
||||
|
||||
## v1.18.5
|
||||
Released: 2024-11-27
|
||||
|
||||
> **Note**: This release contained an issue that prevented the [monitoring.push component](https://docs.victoriametrics.com/anomaly-detection/components/monitoring/#push-config-parameters) from properly instantiating and pushing [self-monitoring metrics](https://docs.victoriametrics.com/anomaly-detection/components/monitoring/#metrics-generated-by-vmanomaly). This issue has been resolved in patch [v1.18.7](#v1187), please update to apply the fix.
|
||||
|
||||
- IMPROVEMENT: Introduced the ability to run `vmanomaly` using a configuration directory. This enhancement allows users to recursively merge multiple full configuration files (previously limited to merging specific sections, such as `reader`) and execute a single instance of the service with the combined configuration.
|
||||
- IMPROVEMENT: Added a new utility, `config_splitter.py`, to streamline the process of splitting a single configuration file into multiple standalone configurations. The configurations are split by specified entities like `schedulers`, `models`, `queries` or `extra_filters`. The split configurations can be saved to a designated directory. It simplifies scaling `vmanomaly` and enhances user experience by automating the process of separating config files so they can be run on separate instances of vmanomaly. For more details, refer to [this section](https://docs.victoriametrics.com/anomaly-detection/faq/#splitting-the-config).
|
||||
- IMPROVEMENT: Introduced the ability to configure the [`PeriodicScheduler`](https://docs.victoriametrics.com/anomaly-detection/components/scheduler/?highlight=start_from#periodic-scheduler) to start at a specific time using the `start_from` and `tz` parameters. The `start_from` parameter accepts either `HH:MM` or [ISO 8601 formats](https://en.wikipedia.org/wiki/ISO_8601), with `tz` defaulting to `UTC`. If `start_from` is in the past, the next valid start time is automatically calculated based on the `fit_every` interval.
|
||||
|
@ -159,7 +159,7 @@ services:
|
||||
# ...
|
||||
vmanomaly:
|
||||
container_name: vmanomaly
|
||||
image: victoriametrics/vmanomaly:v1.18.6
|
||||
image: victoriametrics/vmanomaly:v1.18.7
|
||||
# ...
|
||||
ports:
|
||||
- "8490:8490"
|
||||
@ -365,7 +365,7 @@ options:
|
||||
Here’s an example of using the config splitter to divide configurations based on the `extra_filters` argument from the reader section:
|
||||
|
||||
```sh
|
||||
docker pull victoriametrics/vmanomaly:v1.18.6 && docker image tag victoriametrics/vmanomaly:v1.18.6 vmanomaly
|
||||
docker pull victoriametrics/vmanomaly:v1.18.7 && docker image tag victoriametrics/vmanomaly:v1.18.7 vmanomaly
|
||||
```
|
||||
|
||||
```sh
|
||||
|
@ -229,7 +229,7 @@ This will expose metrics at `http://0.0.0.0:8080/metrics` page.
|
||||
To use *vmanomaly* you need to pull docker image:
|
||||
|
||||
```sh
|
||||
docker pull victoriametrics/vmanomaly:v1.18.6
|
||||
docker pull victoriametrics/vmanomaly:v1.18.7
|
||||
```
|
||||
|
||||
> Note: please check what is latest release in [CHANGELOG](https://docs.victoriametrics.com/anomaly-detection/changelog/)
|
||||
@ -239,7 +239,7 @@ docker pull victoriametrics/vmanomaly:v1.18.6
|
||||
You can put a tag on it for your convenience:
|
||||
|
||||
```sh
|
||||
docker image tag victoriametrics/vmanomaly:v1.18.6 vmanomaly
|
||||
docker image tag victoriametrics/vmanomaly:v1.18.7 vmanomaly
|
||||
```
|
||||
Here is an example of how to run *vmanomaly* docker container with [license file](#licensing):
|
||||
|
||||
|
@ -63,13 +63,13 @@ Below are the steps to get `vmanomaly` up and running inside a Docker container:
|
||||
1. Pull Docker image:
|
||||
|
||||
```sh
|
||||
docker pull victoriametrics/vmanomaly:v1.18.6
|
||||
docker pull victoriametrics/vmanomaly:v1.18.7
|
||||
```
|
||||
|
||||
2. (Optional step) tag the `vmanomaly` Docker image:
|
||||
|
||||
```sh
|
||||
docker image tag victoriametrics/vmanomaly:v1.18.6 vmanomaly
|
||||
docker image tag victoriametrics/vmanomaly:v1.18.7 vmanomaly
|
||||
```
|
||||
|
||||
3. Start the `vmanomaly` Docker container with a *license file*, use the command below.
|
||||
@ -103,7 +103,7 @@ docker run -it --user 1000:1000 \
|
||||
services:
|
||||
# ...
|
||||
vmanomaly:
|
||||
image: victoriametrics/vmanomaly:v1.18.6
|
||||
image: victoriametrics/vmanomaly:v1.18.7
|
||||
volumes:
|
||||
$YOUR_LICENSE_FILE_PATH:/license
|
||||
$YOUR_CONFIG_FILE_PATH:/config.yml
|
||||
|
@ -993,7 +993,7 @@ monitoring:
|
||||
Let's pull the docker image for `vmanomaly`:
|
||||
|
||||
```sh
|
||||
docker pull victoriametrics/vmanomaly:v1.18.6
|
||||
docker pull victoriametrics/vmanomaly:v1.18.7
|
||||
```
|
||||
|
||||
Now we can run the docker container putting as volumes both config and model file:
|
||||
@ -1007,7 +1007,7 @@ docker run -it \
|
||||
-v $(PWD)/license:/license \
|
||||
-v $(PWD)/custom_model.py:/vmanomaly/model/custom.py \
|
||||
-v $(PWD)/custom.yaml:/config.yaml \
|
||||
victoriametrics/vmanomaly:v1.18.6 /config.yaml \
|
||||
victoriametrics/vmanomaly:v1.18.7 /config.yaml \
|
||||
--licenseFile=/license
|
||||
```
|
||||
|
||||
|
@ -59,6 +59,10 @@ There are 2 models to monitor VictoriaMetrics Anomaly Detection behavior - [push
|
||||
|
||||
## Push Config parameters
|
||||
|
||||
By default, metrics are pushed only after the completion of specific stages, e.g., `fit`, `infer`, or `fit_infer` (for each [scheduler](https://docs.victoriametrics.com/anomaly-detection/components/scheduler/) if using a multi-scheduler configuration).
|
||||
|
||||
Starting with [v1.18.7](https://docs.victoriametrics.com/anomaly-detection/changelog/#v1187), the `push_frequency` parameter (default value: `15m`) can be configured to initiate *additional* periodic metric pushes at consistent intervals. This enhances the self-monitoring capabilities of `vmanomaly` by aligning more closely with pull-based monitoring behavior, especially in setups with infrequent schedules (e.g., long `fit_every` or `infer_every` intervals in [PeriodicScheduler](https://docs.victoriametrics.com/anomaly-detection/components/scheduler/#periodic-scheduler)), mitigating data staleness. To disable scheduled metric pushes, set the `push_frequency` parameter to an empty string in the configuration file, as demonstrated in the examples below.
|
||||
|
||||
<table class="params">
|
||||
<thead>
|
||||
<tr>
|
||||
@ -122,9 +126,11 @@ Deprecated since [v1.8.0](https://docs.victoriametrics.com/anomaly-detection/cha
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`bearer_token`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`token`
|
||||
</td>
|
||||
<td>
|
||||
@ -133,9 +139,11 @@ Token is passed in the standard format with header: `Authorization: bearer {toke
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`bearer_token_file`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`path_to_file`
|
||||
</td>
|
||||
<td>
|
||||
@ -144,9 +152,11 @@ Path to a file, which contains token, that is passed in the standard format with
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`verify_tls`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`false`
|
||||
</td>
|
||||
<td>
|
||||
@ -157,9 +167,11 @@ If a path to a CA bundle file (like `ca.crt`), it will verify the certificate us
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`tls_cert_file`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`path/to/cert.crt`
|
||||
</td>
|
||||
<td>
|
||||
@ -168,9 +180,11 @@ Path to a file with the client certificate, i.e. `client.crt`. Available since [
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`tls_key_file`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`path/to/key.crt`
|
||||
</td>
|
||||
<td>
|
||||
@ -191,6 +205,17 @@ Path to a file with the client certificate key, i.e. `client.key`. Available sin
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`push_frequency`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`"15m"`
|
||||
</td>
|
||||
<td>Frequency for scheduled pushing of metrics, e.g., '30m'. Suggested to be less than the staleness interval `-search.maxStalenessInterval` Set to empty string to disable *scheduled* pushing. Available since [v1.18.7](https://docs.victoriametrics.com/anomaly-detection/changelog/#v1187)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`extra_labels`
|
||||
</td>
|
||||
<td></td>
|
||||
@ -213,6 +238,7 @@ monitoring:
|
||||
password: "PASSWORD"
|
||||
verify_tls: False
|
||||
timeout: "5s"
|
||||
push_frequency: "15m" # set to "" to disable scheduled pushes and leave only fit/infer based
|
||||
extra_labels:
|
||||
job: "vmanomaly-push"
|
||||
test: "test-1"
|
||||
|
@ -116,6 +116,7 @@ Name of the class needed to enable reading from VictoriaMetrics or Prometheus. V
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`queries`
|
||||
</td>
|
||||
<td>
|
||||
@ -127,6 +128,7 @@ See [per-query config section](#per-query-parameters) above
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`datasource_url`
|
||||
</td>
|
||||
<td>
|
||||
@ -138,9 +140,11 @@ Datasource URL address
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`tenant_id`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`0:0`, `multitenant`
|
||||
</td>
|
||||
<td>
|
||||
@ -149,6 +153,7 @@ For VictoriaMetrics Cluster version only, tenants are identified by `accountID`
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`sampling_period`
|
||||
</td>
|
||||
<td>
|
||||
@ -160,6 +165,7 @@ Frequency of the points returned. Will be converted to `/query_range?step=%s` pa
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`query_range_path`
|
||||
</td>
|
||||
<td>
|
||||
@ -171,9 +177,11 @@ Performs PromQL/MetricsQL range query
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`health_path`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`health`
|
||||
</td>
|
||||
<td>
|
||||
@ -182,9 +190,11 @@ Absolute or relative URL address where to check availability of the datasource.
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`user`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`USERNAME`
|
||||
</td>
|
||||
<td>
|
||||
@ -193,9 +203,11 @@ BasicAuth username
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`password`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`PASSWORD`
|
||||
</td>
|
||||
<td>
|
||||
@ -204,9 +216,11 @@ BasicAuth password
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`timeout`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`30s`
|
||||
</td>
|
||||
<td>
|
||||
@ -215,9 +229,11 @@ Timeout for the requests, passed as a string
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`verify_tls`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`false`
|
||||
</td>
|
||||
<td>
|
||||
@ -228,9 +244,11 @@ If a path to a CA bundle file (like `ca.crt`), it will verify the certificate us
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`tls_cert_file`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`path/to/cert.crt`
|
||||
</td>
|
||||
<td>
|
||||
@ -239,9 +257,11 @@ Path to a file with the client certificate, i.e. `client.crt`. Available since [
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`tls_key_file`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`path/to/key.crt`
|
||||
</td>
|
||||
<td>
|
||||
@ -250,9 +270,11 @@ Path to a file with the client certificate key, i.e. `client.key`. Available sin
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`bearer_token`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`token`
|
||||
</td>
|
||||
<td>
|
||||
@ -261,9 +283,11 @@ Token is passed in the standard format with header: `Authorization: bearer {toke
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`bearer_token_file`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`path_to_file`
|
||||
</td>
|
||||
<td>
|
||||
@ -272,9 +296,11 @@ Path to a file, which contains token, that is passed in the standard format with
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`extra_filters`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`[]`
|
||||
</td>
|
||||
<td>
|
||||
@ -283,9 +309,11 @@ List of strings with series selector. See: [Prometheus querying API enhancements
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`query_from_last_seen_timestamp`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`False`
|
||||
</td>
|
||||
<td>
|
||||
@ -294,9 +322,11 @@ If True, then query will be performed from the last seen timestamp for a given s
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`latency_offset`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`1ms`
|
||||
</td>
|
||||
<td>
|
||||
@ -305,9 +335,11 @@ Introduced in [v1.15.1](https://docs.victoriametrics.com/anomaly-detection/chang
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`max_points_per_query`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`10000`
|
||||
</td>
|
||||
<td>
|
||||
@ -316,9 +348,11 @@ Introduced in [v1.17.0](https://docs.victoriametrics.com/anomaly-detection/chang
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`tz`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`UTC`
|
||||
</td>
|
||||
<td>
|
||||
@ -327,9 +361,11 @@ Introduced in [v1.18.0](https://docs.victoriametrics.com/anomaly-detection/chang
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`data_range`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`["-inf", "inf"]`
|
||||
</td>
|
||||
<td>
|
||||
|
@ -185,9 +185,11 @@ Timeout for the requests, passed as a string
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`verify_tls`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`false`
|
||||
</td>
|
||||
<td>
|
||||
@ -198,9 +200,11 @@ If a path to a CA bundle file (like `ca.crt`), it will verify the certificate us
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`tls_cert_file`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`path/to/cert.crt`
|
||||
</td>
|
||||
<td>
|
||||
@ -209,9 +213,11 @@ Path to a file with the client certificate, i.e. `client.crt`. Available since [
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`tls_key_file`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`path/to/key.crt`
|
||||
</td>
|
||||
<td>
|
||||
@ -220,9 +226,11 @@ Path to a file with the client certificate key, i.e. `client.key`. Available sin
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`bearer_token`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`token`
|
||||
</td>
|
||||
<td>
|
||||
@ -231,9 +239,11 @@ Token is passed in the standard format with header: `Authorization: bearer {toke
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`bearer_token_file`
|
||||
</td>
|
||||
<td>
|
||||
|
||||
`path_to_file`
|
||||
</td>
|
||||
<td>
|
||||
|
@ -385,7 +385,7 @@ services:
|
||||
restart: always
|
||||
vmanomaly:
|
||||
container_name: vmanomaly
|
||||
image: victoriametrics/vmanomaly:v1.18.6
|
||||
image: victoriametrics/vmanomaly:v1.18.7
|
||||
depends_on:
|
||||
- "victoriametrics"
|
||||
ports:
|
||||
|
Loading…
Reference in New Issue
Block a user