From 83a4865a45bf8e227b97c8c30499a37a38814965 Mon Sep 17 00:00:00 2001 From: Roman Khavronenko Date: Fri, 16 Sep 2022 16:19:10 +0200 Subject: [PATCH] vmalert: always re-evaluate Annotations (#3119) * vmalert: always re-evaluate Annotations Previously, Annotations were evaluated only: 1. On alert creating. 2. On alert's value change. This is premature optimization. It was assumed that since annotations could contain only text with alert's labels or value - there is no need in spending resources to re-compile Annotations. Later, template function `query` was added, which can execute arbitrary queries and return different results on every evaluation. So if it was used in annotations, it would be executed only on init or value change. Another case when optimization caused an issue - annotations hot reload. In this case, annotations of the active alert won't change even if Rule's annotations were changed. This fix enables Annotations re-evaluation on each iteration to resolve issues above. It would have some impact on performance, but it is unlikely it will be noticeable. Signed-off-by: hagen1778 * vmalert: add tp Changelog Signed-off-by: hagen1778 Signed-off-by: hagen1778 --- app/vmalert/alerting.go | 14 +++++--------- docs/CHANGELOG.md | 2 ++ 2 files changed, 7 insertions(+), 9 deletions(-) diff --git a/app/vmalert/alerting.go b/app/vmalert/alerting.go index 7cfe1076a..78af61aad 100644 --- a/app/vmalert/alerting.go +++ b/app/vmalert/alerting.go @@ -285,15 +285,11 @@ func (ar *AlertingRule) Exec(ctx context.Context, ts time.Time, limit int) ([]pr a.State = notifier.StatePending a.ActiveAt = ts } - if a.Value != m.Values[0] { - // update Value field with latest value - a.Value = m.Values[0] - // and re-exec template since Value can be used - // in annotations - a.Annotations, err = a.ExecTemplate(qFn, ls.origin, ar.Annotations) - if err != nil { - return nil, err - } + a.Value = m.Values[0] + // re-exec template since Value or query can be used in annotations + a.Annotations, err = a.ExecTemplate(qFn, ls.origin, ar.Annotations) + if err != nil { + return nil, err } continue } diff --git a/docs/CHANGELOG.md b/docs/CHANGELOG.md index addc99a51..a7517370b 100644 --- a/docs/CHANGELOG.md +++ b/docs/CHANGELOG.md @@ -24,6 +24,8 @@ The following tip changes can be tested by building VictoriaMetrics components f * BUGFIX: [MetricsQL](https://docs.victoriametrics.com/MetricsQL.html): properly calculate `increase(m[d])` over slow-changing counters with values smaller than 100. Previously [increase](https://docs.victoriametrics.com/MetricsQL.html#increase) could return unexpectedly big results in this case. See [the related issue](https://github.com/VictoriaMetrics/VictoriaMetrics/issues/962) and [this pull request](https://github.com/VictoriaMetrics/VictoriaMetrics/pull/3163). * BUGFIX: [MetricsQL](https://docs.victoriametrics.com/MetricsQL.html): ignore empty series when applying [limit_offset](https://docs.victoriametrics.com/MetricsQL.html#limit_offset). It should improve queries with additional filters by value in expressions like `limit_offset(1,1, foo > 1)`. * BUGFIX: [vmui](https://docs.victoriametrics.com/#vmui): fix `RangeError: Maximum call stack size exceeded` error when the query returns too many data points at `Table` view. See [this pull request](https://github.com/VictoriaMetrics/VictoriaMetrics/pull/3092/files). +* BUGFIX: [vmalert](https://docs.victoriametrics.com/vmalert.html): re-evaluate annotations per each alert evaluation. Previously, annotations were evaluated only on alert's value ch +ange. This could result in stale annotations in some cases described in [this pull request](https://github.com/VictoriaMetrics/VictoriaMetrics/pull/3119). ## [v1.79.3](https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v1.79.3)