vmalert: update troubleshooting docs (#3228)

The default value of `-datasource.queryStep` has changed, so we update
the troubleshooting docs accordingly.

Signed-off-by: hagen1778 <roman@victoriametrics.com>
This commit is contained in:
Roman Khavronenko 2022-10-12 12:12:37 +02:00 committed by Aliaksandr Valialkin
parent 7a6e5f9224
commit 895cb3e7c6
No known key found for this signature in database
GPG key ID: A72BEC6CD3D0DED1
2 changed files with 8 additions and 6 deletions

View file

@ -665,9 +665,10 @@ Try the following recommendations in such cases:
are delivered to the datasource; are delivered to the datasource;
* If you know in advance, that data in datasource is delayed - try changing vmalert's `-datasource.lookback` * If you know in advance, that data in datasource is delayed - try changing vmalert's `-datasource.lookback`
command-line flag to add a time shift for evaluations; command-line flag to add a time shift for evaluations;
* If time intervals between datapoints in datasource are irregular - try changing vmalert's `-datasource.queryStep` * If time intervals between datapoints in datasource are irregular or `>=5min` - try changing vmalert's
command-line flag to specify how far search query can lookback for the recent datapoint. By default, this value `-datasource.queryStep` command-line flag to specify how far search query can lookback for the recent datapoint.
is equal to group's evaluation interval. The recommendation is to have the step at least two times bigger than `scrape_interval`, since
there are no guarantees that scrape will not fail.
Sometimes, it is not clear why some specific alert fired or didn't fire. It is very important to remember, that Sometimes, it is not clear why some specific alert fired or didn't fire. It is very important to remember, that
alerts with `for: 0` fire immediately when their expression becomes true. And alerts with `for > 0` will fire only alerts with `for: 0` fire immediately when their expression becomes true. And alerts with `for > 0` will fire only

View file

@ -669,9 +669,10 @@ Try the following recommendations in such cases:
are delivered to the datasource; are delivered to the datasource;
* If you know in advance, that data in datasource is delayed - try changing vmalert's `-datasource.lookback` * If you know in advance, that data in datasource is delayed - try changing vmalert's `-datasource.lookback`
command-line flag to add a time shift for evaluations; command-line flag to add a time shift for evaluations;
* If time intervals between datapoints in datasource are irregular - try changing vmalert's `-datasource.queryStep` * If time intervals between datapoints in datasource are irregular or `>=5min` - try changing vmalert's
command-line flag to specify how far search query can lookback for the recent datapoint. By default, this value `-datasource.queryStep` command-line flag to specify how far search query can lookback for the recent datapoint.
is equal to group's evaluation interval. The recommendation is to have the step at least two times bigger than `scrape_interval`, since
there are no guarantees that scrape will not fail.
Sometimes, it is not clear why some specific alert fired or didn't fire. It is very important to remember, that Sometimes, it is not clear why some specific alert fired or didn't fire. It is very important to remember, that
alerts with `for: 0` fire immediately when their expression becomes true. And alerts with `for > 0` will fire only alerts with `for: 0` fire immediately when their expression becomes true. And alerts with `for > 0` will fire only