alertmanager/matcher/compat/parse_test.go

202 lines
5.6 KiB
Go
Raw Permalink Normal View History

// Copyright 2023 The Prometheus Authors
// 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 compat
import (
"testing"
"github.com/prometheus/common/model"
"github.com/prometheus/common/promslog"
"github.com/stretchr/testify/require"
"github.com/prometheus/alertmanager/pkg/labels"
)
func TestFallbackMatcherParser(t *testing.T) {
tests := []struct {
Remove metrics from compat package (#3714) This commit removes the metrics from the compat package in favour of the existing logging and the additional tools at hand, such as amtool, to validate Alertmanager configurations. Due to the global nature of the compat package, a consequence of config.Load, these metrics have proven to be less useful in practice than expected, both in Alertmanager and other projects such as Mimir. There are a number of reasons for this: 1. Because the compat package is global, these metrics cannot be reset each time config.Load is called, as in multi-tenant projects like Mimir loading a config for one tenant would reset the metrics for all tenants. This is also the reason the metrics are counters and not gauges. 2. Since the metrics are counters, it is difficult to create meaningful dashboards for Alertmanager as, unlike in Mimir, configurations are not reloaded at fixed intervals, and as such, operators cannot use rate to track configuration changes over time. In Alertmanager, there are much better tools available to validate that an Alertmanager configuration is compatible with the UTF-8 parser, including both the existing logging from Alertmanager server and amtool check-config. In other projects like Mimir, we can track configurations for individual tenants using log aggregation and storage systems such as Loki. This gives operators far more information than what is possible with the metrics, including the timestamp, input and ID of tenant configurations that are incompatible or have disagreement. Signed-off-by: George Robinson <george.robinson@grafana.com>
2024-02-08 09:59:03 +00:00
name string
input string
expected *labels.Matcher
err string
}{{
name: "input is accepted",
input: "foo=bar",
expected: mustNewMatcher(t, labels.MatchEqual, "foo", "bar"),
}, {
Remove metrics from compat package (#3714) This commit removes the metrics from the compat package in favour of the existing logging and the additional tools at hand, such as amtool, to validate Alertmanager configurations. Due to the global nature of the compat package, a consequence of config.Load, these metrics have proven to be less useful in practice than expected, both in Alertmanager and other projects such as Mimir. There are a number of reasons for this: 1. Because the compat package is global, these metrics cannot be reset each time config.Load is called, as in multi-tenant projects like Mimir loading a config for one tenant would reset the metrics for all tenants. This is also the reason the metrics are counters and not gauges. 2. Since the metrics are counters, it is difficult to create meaningful dashboards for Alertmanager as, unlike in Mimir, configurations are not reloaded at fixed intervals, and as such, operators cannot use rate to track configuration changes over time. In Alertmanager, there are much better tools available to validate that an Alertmanager configuration is compatible with the UTF-8 parser, including both the existing logging from Alertmanager server and amtool check-config. In other projects like Mimir, we can track configurations for individual tenants using log aggregation and storage systems such as Loki. This gives operators far more information than what is possible with the metrics, including the timestamp, input and ID of tenant configurations that are incompatible or have disagreement. Signed-off-by: George Robinson <george.robinson@grafana.com>
2024-02-08 09:59:03 +00:00
name: "input is accepted in neither",
input: "foo!bar",
err: "bad matcher format: foo!bar",
}, {
name: "input is accepted in matchers/parse but not pkg/labels",
input: "foo🙂=bar",
expected: mustNewMatcher(t, labels.MatchEqual, "foo🙂", "bar"),
}, {
Remove metrics from compat package (#3714) This commit removes the metrics from the compat package in favour of the existing logging and the additional tools at hand, such as amtool, to validate Alertmanager configurations. Due to the global nature of the compat package, a consequence of config.Load, these metrics have proven to be less useful in practice than expected, both in Alertmanager and other projects such as Mimir. There are a number of reasons for this: 1. Because the compat package is global, these metrics cannot be reset each time config.Load is called, as in multi-tenant projects like Mimir loading a config for one tenant would reset the metrics for all tenants. This is also the reason the metrics are counters and not gauges. 2. Since the metrics are counters, it is difficult to create meaningful dashboards for Alertmanager as, unlike in Mimir, configurations are not reloaded at fixed intervals, and as such, operators cannot use rate to track configuration changes over time. In Alertmanager, there are much better tools available to validate that an Alertmanager configuration is compatible with the UTF-8 parser, including both the existing logging from Alertmanager server and amtool check-config. In other projects like Mimir, we can track configurations for individual tenants using log aggregation and storage systems such as Loki. This gives operators far more information than what is possible with the metrics, including the timestamp, input and ID of tenant configurations that are incompatible or have disagreement. Signed-off-by: George Robinson <george.robinson@grafana.com>
2024-02-08 09:59:03 +00:00
name: "input is accepted in pkg/labels but not matchers/parse",
input: "foo=!bar\\n",
expected: mustNewMatcher(t, labels.MatchEqual, "foo", "!bar\n"),
}, {
// This input causes disagreement because \xf0\x9f\x99\x82 is the byte sequence for 🙂,
// which is not understood by pkg/labels but is understood by matchers/parse. In such cases,
// the fallback parser returns the result from pkg/labels.
Remove metrics from compat package (#3714) This commit removes the metrics from the compat package in favour of the existing logging and the additional tools at hand, such as amtool, to validate Alertmanager configurations. Due to the global nature of the compat package, a consequence of config.Load, these metrics have proven to be less useful in practice than expected, both in Alertmanager and other projects such as Mimir. There are a number of reasons for this: 1. Because the compat package is global, these metrics cannot be reset each time config.Load is called, as in multi-tenant projects like Mimir loading a config for one tenant would reset the metrics for all tenants. This is also the reason the metrics are counters and not gauges. 2. Since the metrics are counters, it is difficult to create meaningful dashboards for Alertmanager as, unlike in Mimir, configurations are not reloaded at fixed intervals, and as such, operators cannot use rate to track configuration changes over time. In Alertmanager, there are much better tools available to validate that an Alertmanager configuration is compatible with the UTF-8 parser, including both the existing logging from Alertmanager server and amtool check-config. In other projects like Mimir, we can track configurations for individual tenants using log aggregation and storage systems such as Loki. This gives operators far more information than what is possible with the metrics, including the timestamp, input and ID of tenant configurations that are incompatible or have disagreement. Signed-off-by: George Robinson <george.robinson@grafana.com>
2024-02-08 09:59:03 +00:00
name: "input causes disagreement",
input: "foo=\"\\xf0\\x9f\\x99\\x82\"",
expected: mustNewMatcher(t, labels.MatchEqual, "foo", "\\xf0\\x9f\\x99\\x82"),
}}
for _, test := range tests {
t.Run(test.name, func(t *testing.T) {
f := FallbackMatcherParser(promslog.NewNopLogger())
matcher, err := f(test.input, "test")
if test.err != "" {
require.EqualError(t, err, test.err)
} else {
require.NoError(t, err)
require.EqualValues(t, test.expected, matcher)
}
})
}
}
func TestFallbackMatchersParser(t *testing.T) {
tests := []struct {
Remove metrics from compat package (#3714) This commit removes the metrics from the compat package in favour of the existing logging and the additional tools at hand, such as amtool, to validate Alertmanager configurations. Due to the global nature of the compat package, a consequence of config.Load, these metrics have proven to be less useful in practice than expected, both in Alertmanager and other projects such as Mimir. There are a number of reasons for this: 1. Because the compat package is global, these metrics cannot be reset each time config.Load is called, as in multi-tenant projects like Mimir loading a config for one tenant would reset the metrics for all tenants. This is also the reason the metrics are counters and not gauges. 2. Since the metrics are counters, it is difficult to create meaningful dashboards for Alertmanager as, unlike in Mimir, configurations are not reloaded at fixed intervals, and as such, operators cannot use rate to track configuration changes over time. In Alertmanager, there are much better tools available to validate that an Alertmanager configuration is compatible with the UTF-8 parser, including both the existing logging from Alertmanager server and amtool check-config. In other projects like Mimir, we can track configurations for individual tenants using log aggregation and storage systems such as Loki. This gives operators far more information than what is possible with the metrics, including the timestamp, input and ID of tenant configurations that are incompatible or have disagreement. Signed-off-by: George Robinson <george.robinson@grafana.com>
2024-02-08 09:59:03 +00:00
name string
input string
expected labels.Matchers
err string
}{{
name: "input is accepted",
input: "{foo=bar,bar=baz}",
expected: labels.Matchers{
mustNewMatcher(t, labels.MatchEqual, "foo", "bar"),
mustNewMatcher(t, labels.MatchEqual, "bar", "baz"),
},
}, {
Remove metrics from compat package (#3714) This commit removes the metrics from the compat package in favour of the existing logging and the additional tools at hand, such as amtool, to validate Alertmanager configurations. Due to the global nature of the compat package, a consequence of config.Load, these metrics have proven to be less useful in practice than expected, both in Alertmanager and other projects such as Mimir. There are a number of reasons for this: 1. Because the compat package is global, these metrics cannot be reset each time config.Load is called, as in multi-tenant projects like Mimir loading a config for one tenant would reset the metrics for all tenants. This is also the reason the metrics are counters and not gauges. 2. Since the metrics are counters, it is difficult to create meaningful dashboards for Alertmanager as, unlike in Mimir, configurations are not reloaded at fixed intervals, and as such, operators cannot use rate to track configuration changes over time. In Alertmanager, there are much better tools available to validate that an Alertmanager configuration is compatible with the UTF-8 parser, including both the existing logging from Alertmanager server and amtool check-config. In other projects like Mimir, we can track configurations for individual tenants using log aggregation and storage systems such as Loki. This gives operators far more information than what is possible with the metrics, including the timestamp, input and ID of tenant configurations that are incompatible or have disagreement. Signed-off-by: George Robinson <george.robinson@grafana.com>
2024-02-08 09:59:03 +00:00
name: "input is accepted in neither",
input: "{foo!bar}",
err: "bad matcher format: foo!bar",
}, {
name: "input is accepted in matchers/parse but not pkg/labels",
input: "{foo🙂=bar,bar=baz🙂}",
expected: labels.Matchers{
mustNewMatcher(t, labels.MatchEqual, "foo🙂", "bar"),
mustNewMatcher(t, labels.MatchEqual, "bar", "baz🙂"),
},
}, {
name: "is accepted in pkg/labels but not matchers/parse",
input: "{foo=!bar,bar=$baz\\n}",
expected: labels.Matchers{
mustNewMatcher(t, labels.MatchEqual, "foo", "!bar"),
mustNewMatcher(t, labels.MatchEqual, "bar", "$baz\n"),
},
}, {
// This input causes disagreement because \xf0\x9f\x99\x82 is the byte sequence for 🙂,
// which is not understood by pkg/labels but is understood by matchers/parse. In such cases,
// the fallback parser returns the result from pkg/labels.
name: "input causes disagreement",
input: "{foo=\"\\xf0\\x9f\\x99\\x82\"}",
expected: labels.Matchers{
mustNewMatcher(t, labels.MatchEqual, "foo", "\\xf0\\x9f\\x99\\x82"),
},
}}
for _, test := range tests {
t.Run(test.name, func(t *testing.T) {
f := FallbackMatchersParser(promslog.NewNopLogger())
matchers, err := f(test.input, "test")
if test.err != "" {
require.EqualError(t, err, test.err)
} else {
require.NoError(t, err)
require.EqualValues(t, test.expected, matchers)
}
})
}
}
func mustNewMatcher(t *testing.T, op labels.MatchType, name, value string) *labels.Matcher {
m, err := labels.NewMatcher(op, name, value)
require.NoError(t, err)
return m
}
func TestIsValidClassicLabelName(t *testing.T) {
tests := []struct {
name string
input model.LabelName
expected bool
}{{
name: "foo is accepted",
input: "foo",
expected: true,
}, {
name: "starts with underscore and ends with number is accepted",
input: "_foo1",
expected: true,
}, {
name: "empty is not accepted",
input: "",
expected: false,
}, {
name: "starts with number is not accepted",
input: "0foo",
expected: false,
}, {
name: "contains emoji is not accepted",
input: "foo🙂",
expected: false,
}}
for _, test := range tests {
fn := isValidClassicLabelName(promslog.NewNopLogger())
t.Run(test.name, func(t *testing.T) {
require.Equal(t, test.expected, fn(test.input))
})
}
}
func TestIsValidUTF8LabelName(t *testing.T) {
tests := []struct {
name string
input model.LabelName
expected bool
}{{
name: "foo is accepted",
input: "foo",
expected: true,
}, {
name: "starts with underscore and ends with number is accepted",
input: "_foo1",
expected: true,
}, {
name: "starts with number is accepted",
input: "0foo",
expected: true,
}, {
name: "contains emoji is accepted",
input: "foo🙂",
expected: true,
}, {
name: "empty is not accepted",
input: "",
expected: false,
}}
for _, test := range tests {
fn := isValidUTF8LabelName(promslog.NewNopLogger())
t.Run(test.name, func(t *testing.T) {
require.Equal(t, test.expected, fn(test.input))
})
}
}