docs: vmanomaly - fix 1.9.2 references in pull cmd and docs (#5756)

* fix 1.9.2 references in pull cmd and docs
* better readability of upgrade note
This commit is contained in:
Fred Navruzov 2024-02-02 18:06:07 +01:00 committed by Aliaksandr Valialkin
parent bdbab7bed5
commit be41ffb925
No known key found for this signature in database
GPG key ID: 52C003EE2BCDB9EB
3 changed files with 4 additions and 4 deletions

View file

@ -15,7 +15,7 @@ aliases:
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 later versions for optimal performance and accuracy. This recommendation is crucial for configurations with a low `infer_every` parameter [in your scheduler](https://docs.victoriametrics.com/anomaly-detection/components/scheduler/#parameters-1), and in scenarios where data exhibits significant high-order seasonality patterns (such as hourly or daily cycles). Previous versions from v1.5.1 to v1.8.0 were identified to contain a critical issue impacting model training, where models were inadvertently trained on limited data subsets, leading to suboptimal fits, affecting the accuracy of anomaly detection. Upgrading to v1.9.2 addresses this issue, ensuring proper model training and enhanced reliability. For users utilizing Helm charts, it is recommended to temporarily revert to version [0.4.1](https://github.com/VictoriaMetrics/helm-charts/blob/master/charts/victoria-metrics-anomaly/CHANGELOG.md#041). This action is advised until an updated version, encompassing the necessary bug fixes, becomes available.**
> **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 later versions for optimal performance and accuracy. <br><br> This recommendation is crucial for configurations with a low `infer_every` parameter [in your scheduler](https://docs.victoriametrics.com/anomaly-detection/components/scheduler/#parameters-1), and in scenarios where data exhibits significant high-order seasonality patterns (such as hourly or daily cycles). Previous versions from v1.5.1 to v1.8.0 were identified to contain a critical issue impacting model training, where models were inadvertently trained on limited data subsets, leading to suboptimal fits, affecting the accuracy of anomaly detection. <br><br> Upgrading to v1.9.2 addresses this issue, ensuring proper model training and enhanced reliability. For users utilizing Helm charts, it is recommended to temporarily revert to version [0.4.1](https://github.com/VictoriaMetrics/helm-charts/blob/master/charts/victoria-metrics-anomaly/CHANGELOG.md#041). This action is advised until an updated version, encompassing the necessary bug fixes, becomes available.**
## v1.9.2
Released: 2024-01-29

View file

@ -217,7 +217,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:1.9.2
docker pull victoriametrics/vmanomaly:v1.9.2
```
> Note: please check what is latest release in [CHANGELOG](/anomaly-detection/CHANGELOG.html)
@ -227,7 +227,7 @@ docker pull victoriametrics/vmanomaly:1.9.2
You can put a tag on it for your convinience:
```sh
docker image tag victoriametrics/vmanomaly:1.9.2 vmanomaly
docker image tag victoriametrics/vmanomaly:v1.9.2 vmanomaly
```
Here is an example of how to run *vmanomaly* docker container with [license file](#licensing):

View file

@ -36,7 +36,7 @@ aliases:
All the service parameters are defined in a config file.
> **Note**: As of the time of writing, in the [1.9.2](https://docs.victoriametrics.com/anomaly-detection/changelog/#v191) release and earlier versions, each `vmanomaly` configuration file is limited to supporting only one model type. To utilize *different models* on your data, it is necessary to run multiple instances of the `vmanomaly` process. Each instance should operate with its own configuration file, differing in the `model` section.
> **Note**: As of the time of writing, in the [1.9.2](https://docs.victoriametrics.com/anomaly-detection/changelog/#v192) release and earlier versions, each `vmanomaly` configuration file is limited to supporting only one model type. To utilize *different models* on your data, it is necessary to run multiple instances of the `vmanomaly` process. Each instance should operate with its own configuration file, differing in the `model` section.
**vmanomaly** does the following: