alertmanager/inhibit/inhibit.go

252 lines
7.3 KiB
Go
Raw Permalink Normal View History

2015-10-11 15:24:49 +00:00
// Copyright 2015 Prometheus Team
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
package inhibit
2015-09-27 11:20:54 +00:00
import (
"context"
2015-09-27 11:20:54 +00:00
"sync"
"time"
2015-09-27 11:20:54 +00:00
"github.com/go-kit/log"
"github.com/go-kit/log/level"
"github.com/oklog/run"
2015-09-27 11:20:54 +00:00
"github.com/prometheus/common/model"
"github.com/prometheus/alertmanager/config"
"github.com/prometheus/alertmanager/pkg/labels"
2015-09-27 11:20:54 +00:00
"github.com/prometheus/alertmanager/provider"
"github.com/prometheus/alertmanager/store"
2015-09-27 11:20:54 +00:00
"github.com/prometheus/alertmanager/types"
)
// An Inhibitor determines whether a given label set is muted based on the
// currently active alerts and a set of inhibition rules. It implements the
// Muter interface.
2015-09-27 11:20:54 +00:00
type Inhibitor struct {
alerts provider.Alerts
rules []*InhibitRule
marker types.Marker
logger log.Logger
2015-09-27 11:20:54 +00:00
mtx sync.RWMutex
cancel func()
2015-09-27 11:20:54 +00:00
}
2015-11-05 09:49:32 +00:00
// NewInhibitor returns a new Inhibitor.
func NewInhibitor(ap provider.Alerts, rs []config.InhibitRule, mk types.Marker, logger log.Logger) *Inhibitor {
ih := &Inhibitor{
alerts: ap,
marker: mk,
logger: logger,
}
for _, cr := range rs {
r := NewInhibitRule(cr)
ih.rules = append(ih.rules, r)
}
return ih
}
2015-09-27 11:20:54 +00:00
func (ih *Inhibitor) run(ctx context.Context) {
it := ih.alerts.Subscribe()
defer it.Close()
for {
select {
case <-ctx.Done():
return
case a := <-it.Next():
if err := it.Err(); err != nil {
level.Error(ih.logger).Log("msg", "Error iterating alerts", "err", err)
continue
}
Fix resolved alerts still inhibiting (#1331) * inhibit: update inhibition cache when alerts resolve Signed-off-by: Simon Pasquier <spasquie@redhat.com> * inhibit: remove unnecessary fmt.Sprintf Signed-off-by: Simon Pasquier <spasquie@redhat.com> * inhibit: add unit tests Signed-off-by: Simon Pasquier <spasquie@redhat.com> * inhibit: use NopLogger in tests Signed-off-by: Simon Pasquier <spasquie@redhat.com> * Update old alert with result of merge with new On ingest, alerts with matching fingerprints are merged if the new alert's start and end times overlap with the old alert's. The merge creates a new alert, which is then updated in the internal alert store. The original alert is not updated (because merge creates a copy), so it is never marked as resolved in the inhibitor's reference to it. The code within the inhibitor relies on skipping over resolved alerts, but because the old alert is never updated it is never marked as resolved. Thus it continues to inhibit other alerts until it is cleaned up by the internal GC. This commit updates the struct of the old alert with the result of the merge with the new alert. An alternative would be to always update the inhibitor's internal cache of alerts regardless of an alert's resolve status. Signed-off-by: stuart nelson <stuartnelson3@gmail.com> * Update inhibitor cache even if alert is resolved This seems like a better choice than the previous commit. I think it is more sane to have the inhibitor update its own cache, rather than having one of its pointers updated externally. Signed-off-by: stuart nelson <stuartnelson3@gmail.com>
2018-04-18 14:26:04 +00:00
// Update the inhibition rules' cache.
for _, r := range ih.rules {
if r.SourceMatchers.Matches(a.Labels) {
if err := r.scache.Set(a); err != nil {
level.Error(ih.logger).Log("msg", "error on set alert", "err", err)
}
}
2015-09-27 11:20:54 +00:00
}
}
}
}
// Run the Inhibitor's background processing.
func (ih *Inhibitor) Run() {
var (
g run.Group
ctx context.Context
)
ih.mtx.Lock()
ctx, ih.cancel = context.WithCancel(context.Background())
ih.mtx.Unlock()
runCtx, runCancel := context.WithCancel(ctx)
for _, rule := range ih.rules {
go rule.scache.Run(runCtx, 15*time.Minute)
}
g.Add(func() error {
ih.run(runCtx)
return nil
}, func(err error) {
runCancel()
})
if err := g.Run(); err != nil {
level.Warn(ih.logger).Log("msg", "error running inhibitor", "err", err)
}
}
// Stop the Inhibitor's background processing.
func (ih *Inhibitor) Stop() {
if ih == nil {
return
}
ih.mtx.RLock()
defer ih.mtx.RUnlock()
if ih.cancel != nil {
ih.cancel()
}
}
// Mutes returns true iff the given label set is muted. It implements the Muter
// interface.
func (ih *Inhibitor) Mutes(lset model.LabelSet) bool {
fp := lset.Fingerprint()
for _, r := range ih.rules {
if !r.TargetMatchers.Matches(lset) {
Modify the self-inhibition prevention semantics This has been discussed in #666 (issue of hell...). As concluded there, the cleanest semantics is most likely the following: "An alert that matches both target and source side cannot inhibit alerts for which the same is true." The two open questions were: 1. How difficult is the implementation? 2. Is it needed? This relatively simple commit proves that the answer to (1) is: Not very difficult. (This also includes a performance-improving simplification, which would have been possible without a change of semantics.) The answer to (2) is twofold: For one, the original use case in #666 wasn't solved by our interim solution. What we solved is the case where the self-inhibition is triggered by a wide target match, i.e. I have a specific alert that should inhibit a whole group of target alerts without inhibiting itself. What we did _not_ solve is the inverted case: Self-inhibition by a wide source match, i.e. an alert that should only fire if none of a whole group of source alert fires. I mean, we "fixed" it as in, the target alert will never be inhibited, but @lmb in #666 wanted the alert to be inhibited _sometimes_ (just not _always_). The other part is that I think that the asymmetry in our interim solution will at some point haunt us. Thus, I really would like to get this change in before we do a 1.0 release. In practice, I expect this to be only relevant in very rare cases. But those cases will be most difficult to reason with, and I claim that the solution in this commit is matching what humans intuitively expect. Signed-off-by: beorn7 <beorn@soundcloud.com>
2019-02-22 18:57:27 +00:00
// If target side of rule doesn't match, we don't need to look any further.
continue
}
// If we are here, the target side matches. If the source side matches, too, we
// need to exclude inhibiting alerts for which the same is true.
if inhibitedByFP, eq := r.hasEqual(lset, r.SourceMatchers.Matches(lset)); eq {
Fix resolved alerts still inhibiting (#1331) * inhibit: update inhibition cache when alerts resolve Signed-off-by: Simon Pasquier <spasquie@redhat.com> * inhibit: remove unnecessary fmt.Sprintf Signed-off-by: Simon Pasquier <spasquie@redhat.com> * inhibit: add unit tests Signed-off-by: Simon Pasquier <spasquie@redhat.com> * inhibit: use NopLogger in tests Signed-off-by: Simon Pasquier <spasquie@redhat.com> * Update old alert with result of merge with new On ingest, alerts with matching fingerprints are merged if the new alert's start and end times overlap with the old alert's. The merge creates a new alert, which is then updated in the internal alert store. The original alert is not updated (because merge creates a copy), so it is never marked as resolved in the inhibitor's reference to it. The code within the inhibitor relies on skipping over resolved alerts, but because the old alert is never updated it is never marked as resolved. Thus it continues to inhibit other alerts until it is cleaned up by the internal GC. This commit updates the struct of the old alert with the result of the merge with the new alert. An alternative would be to always update the inhibitor's internal cache of alerts regardless of an alert's resolve status. Signed-off-by: stuart nelson <stuartnelson3@gmail.com> * Update inhibitor cache even if alert is resolved This seems like a better choice than the previous commit. I think it is more sane to have the inhibitor update its own cache, rather than having one of its pointers updated externally. Signed-off-by: stuart nelson <stuartnelson3@gmail.com>
2018-04-18 14:26:04 +00:00
ih.marker.SetInhibited(fp, inhibitedByFP.String())
return true
}
}
2017-04-27 12:18:52 +00:00
ih.marker.SetInhibited(fp)
2017-04-27 12:18:52 +00:00
return false
2015-09-27 11:20:54 +00:00
}
// An InhibitRule specifies that a class of (source) alerts should inhibit
// notifications for another class of (target) alerts if all specified matching
// labels are equal between the two alerts. This may be used to inhibit alerts
// from sending notifications if their meaning is logically a subset of a
// higher-level alert.
type InhibitRule struct {
// The set of Filters which define the group of source alerts (which inhibit
// the target alerts).
SourceMatchers labels.Matchers
2015-09-27 11:20:54 +00:00
// The set of Filters which define the group of target alerts (which are
// inhibited by the source alerts).
TargetMatchers labels.Matchers
2015-09-27 11:20:54 +00:00
// A set of label names whose label values need to be identical in source and
// target alerts in order for the inhibition to take effect.
Equal map[model.LabelName]struct{}
// Cache of alerts matching source labels.
scache *store.Alerts
2015-09-27 11:20:54 +00:00
}
// NewInhibitRule returns a new InhibitRule based on a configuration definition.
func NewInhibitRule(cr config.InhibitRule) *InhibitRule {
2015-09-27 11:20:54 +00:00
var (
sourcem labels.Matchers
targetm labels.Matchers
2015-09-27 11:20:54 +00:00
)
// cr.SourceMatch will be deprecated. This for loop appends regex matchers.
2015-09-27 11:20:54 +00:00
for ln, lv := range cr.SourceMatch {
matcher, err := labels.NewMatcher(labels.MatchEqual, ln, lv)
if err != nil {
// This error must not happen because the config already validates the yaml.
panic(err)
}
sourcem = append(sourcem, matcher)
2015-09-27 11:20:54 +00:00
}
// cr.SourceMatchRE will be deprecated. This for loop appends regex matchers.
2015-09-27 11:20:54 +00:00
for ln, lv := range cr.SourceMatchRE {
matcher, err := labels.NewMatcher(labels.MatchRegexp, ln, lv.String())
if err != nil {
// This error must not happen because the config already validates the yaml.
panic(err)
}
sourcem = append(sourcem, matcher)
2015-09-27 11:20:54 +00:00
}
// We append the new-style matchers. This can be simplified once the deprecated matcher syntax is removed.
sourcem = append(sourcem, cr.SourceMatchers...)
2015-09-27 11:20:54 +00:00
// cr.TargetMatch will be deprecated. This for loop appends regex matchers.
2015-09-27 11:20:54 +00:00
for ln, lv := range cr.TargetMatch {
matcher, err := labels.NewMatcher(labels.MatchEqual, ln, lv)
if err != nil {
// This error must not happen because the config already validates the yaml.
panic(err)
}
targetm = append(targetm, matcher)
2015-09-27 11:20:54 +00:00
}
// cr.TargetMatchRE will be deprecated. This for loop appends regex matchers.
2015-09-27 11:20:54 +00:00
for ln, lv := range cr.TargetMatchRE {
matcher, err := labels.NewMatcher(labels.MatchRegexp, ln, lv.String())
if err != nil {
// This error must not happen because the config already validates the yaml.
panic(err)
}
targetm = append(targetm, matcher)
2015-09-27 11:20:54 +00:00
}
// We append the new-style matchers. This can be simplified once the deprecated matcher syntax is removed.
targetm = append(targetm, cr.TargetMatchers...)
2015-09-27 11:20:54 +00:00
2015-10-05 11:23:40 +00:00
equal := map[model.LabelName]struct{}{}
2015-09-27 11:20:54 +00:00
for _, ln := range cr.Equal {
equal[ln] = struct{}{}
}
return &InhibitRule{
SourceMatchers: sourcem,
TargetMatchers: targetm,
Equal: equal,
scache: store.NewAlerts(),
2015-09-27 11:20:54 +00:00
}
}
Modify the self-inhibition prevention semantics This has been discussed in #666 (issue of hell...). As concluded there, the cleanest semantics is most likely the following: "An alert that matches both target and source side cannot inhibit alerts for which the same is true." The two open questions were: 1. How difficult is the implementation? 2. Is it needed? This relatively simple commit proves that the answer to (1) is: Not very difficult. (This also includes a performance-improving simplification, which would have been possible without a change of semantics.) The answer to (2) is twofold: For one, the original use case in #666 wasn't solved by our interim solution. What we solved is the case where the self-inhibition is triggered by a wide target match, i.e. I have a specific alert that should inhibit a whole group of target alerts without inhibiting itself. What we did _not_ solve is the inverted case: Self-inhibition by a wide source match, i.e. an alert that should only fire if none of a whole group of source alert fires. I mean, we "fixed" it as in, the target alert will never be inhibited, but @lmb in #666 wanted the alert to be inhibited _sometimes_ (just not _always_). The other part is that I think that the asymmetry in our interim solution will at some point haunt us. Thus, I really would like to get this change in before we do a 1.0 release. In practice, I expect this to be only relevant in very rare cases. But those cases will be most difficult to reason with, and I claim that the solution in this commit is matching what humans intuitively expect. Signed-off-by: beorn7 <beorn@soundcloud.com>
2019-02-22 18:57:27 +00:00
// hasEqual checks whether the source cache contains alerts matching the equal
// labels for the given label set. If so, the fingerprint of one of those alerts
// is returned. If excludeTwoSidedMatch is true, alerts that match both the
// source and the target side of the rule are disregarded.
Modify the self-inhibition prevention semantics This has been discussed in #666 (issue of hell...). As concluded there, the cleanest semantics is most likely the following: "An alert that matches both target and source side cannot inhibit alerts for which the same is true." The two open questions were: 1. How difficult is the implementation? 2. Is it needed? This relatively simple commit proves that the answer to (1) is: Not very difficult. (This also includes a performance-improving simplification, which would have been possible without a change of semantics.) The answer to (2) is twofold: For one, the original use case in #666 wasn't solved by our interim solution. What we solved is the case where the self-inhibition is triggered by a wide target match, i.e. I have a specific alert that should inhibit a whole group of target alerts without inhibiting itself. What we did _not_ solve is the inverted case: Self-inhibition by a wide source match, i.e. an alert that should only fire if none of a whole group of source alert fires. I mean, we "fixed" it as in, the target alert will never be inhibited, but @lmb in #666 wanted the alert to be inhibited _sometimes_ (just not _always_). The other part is that I think that the asymmetry in our interim solution will at some point haunt us. Thus, I really would like to get this change in before we do a 1.0 release. In practice, I expect this to be only relevant in very rare cases. But those cases will be most difficult to reason with, and I claim that the solution in this commit is matching what humans intuitively expect. Signed-off-by: beorn7 <beorn@soundcloud.com>
2019-02-22 18:57:27 +00:00
func (r *InhibitRule) hasEqual(lset model.LabelSet, excludeTwoSidedMatch bool) (model.Fingerprint, bool) {
Outer:
for _, a := range r.scache.List() {
// The cache might be stale and contain resolved alerts.
if a.Resolved() {
continue
2015-09-28 20:08:47 +00:00
}
for n := range r.Equal {
if a.Labels[n] != lset[n] {
continue Outer
}
}
if excludeTwoSidedMatch && r.TargetMatchers.Matches(a.Labels) {
Modify the self-inhibition prevention semantics This has been discussed in #666 (issue of hell...). As concluded there, the cleanest semantics is most likely the following: "An alert that matches both target and source side cannot inhibit alerts for which the same is true." The two open questions were: 1. How difficult is the implementation? 2. Is it needed? This relatively simple commit proves that the answer to (1) is: Not very difficult. (This also includes a performance-improving simplification, which would have been possible without a change of semantics.) The answer to (2) is twofold: For one, the original use case in #666 wasn't solved by our interim solution. What we solved is the case where the self-inhibition is triggered by a wide target match, i.e. I have a specific alert that should inhibit a whole group of target alerts without inhibiting itself. What we did _not_ solve is the inverted case: Self-inhibition by a wide source match, i.e. an alert that should only fire if none of a whole group of source alert fires. I mean, we "fixed" it as in, the target alert will never be inhibited, but @lmb in #666 wanted the alert to be inhibited _sometimes_ (just not _always_). The other part is that I think that the asymmetry in our interim solution will at some point haunt us. Thus, I really would like to get this change in before we do a 1.0 release. In practice, I expect this to be only relevant in very rare cases. But those cases will be most difficult to reason with, and I claim that the solution in this commit is matching what humans intuitively expect. Signed-off-by: beorn7 <beorn@soundcloud.com>
2019-02-22 18:57:27 +00:00
continue Outer
}
return a.Fingerprint(), true
2015-09-28 20:08:47 +00:00
}
2017-04-27 12:18:52 +00:00
return model.Fingerprint(0), false
}