VictoriaMetrics/app/vmalert/datasource
Roman Khavronenko 3adf8c5a6f
vmalert: explicitly set extra labels to alert entities (#886)
The previous implementation treated extra labels (global and rule labels) as
separate label set to returned time series labels. Hence, time series always contained
only original labels and alert ID was generated from sorted labels key-values.
Extra labels didn't affect the generated ID and were applied on the following actions:
- templating for Summary and Annotations;
- persisting state via remote write;
- restoring state via remote read.

Such behaviour caused difficulties on restore procedure because extra labels had to be dropped
before checking the alert ID, but that not always worked. Consider the case when expression
returns the following time series `up{job="foo"}` and rule has extra label `job=bar`.
This would mean that restored alert ID will be always different to the real time series because
of collision.

To solve the situation extra labels are now always applied beforehand and `vmalert` doesn't
store original labels anymore. However, this could result into a new error situation.
Consider the case when expression returns two time series `up{job="foo"}` and `up{job="baz"}`,
while rule has extra label `job=bar`. In such case, applying extra labels will result into
two identical time series and `vmalert` will return error:
 `result contains metrics with the same labelset after applying rule labels`

https://github.com/VictoriaMetrics/VictoriaMetrics/issues/870
2020-11-10 00:27:32 +02:00
..
datasource.go vmalert: explicitly set extra labels to alert entities (#886) 2020-11-10 00:27:32 +02:00
init.go app/vmalert: do not pring description for all the flags on config errors 2020-10-08 13:35:57 +03:00
vm_test.go Fix typos in the vmalert datasource (#814) 2020-10-07 17:59:50 +03:00
vm.go vmalert: explicitly set extra labels to alert entities (#886) 2020-11-10 00:27:32 +02:00