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:
Fred Navruzov 2024-12-02 19:32:17 +01:00 committed by GitHub
parent c89926bdf7
commit cdf384eb4d
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
10 changed files with 94 additions and 11 deletions

View File

@ -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:

View File

@ -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.

View File

@ -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:
Heres 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

View File

@ -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):

View File

@ -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

View File

@ -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
```

View File

@ -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"

View File

@ -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>

View File

@ -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>

View File

@ -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: