Here is the PR that updates the
docs https://github.com/prometheus/alertmanager/pull/4157
On Friday, December 6, 2024 at 1:22:08 PM UTC George Robinson wrote:
> Just to wrap this up, one of the reasons for this is to be consistent.
>
> If you have a matcher like applicationid=~"^SNSVC\d{7}$" and you ask
> Alertmanager to write it back to a file, it will do it as
> applicationid=~"^SNSVC\\d{7}$" (note the double escape). This is because
> again it follows the Go escaping rules for strings when encoding it.
>
> By enforcing double quotes in the new parser, we now have consistency
> between what you the user can write and what you see output from
> Alertmanager. The behavior though is unchanged.
>
> I hope this makes sense
>
> George
>
> On Friday, December 6, 2024 at 12:58:54 PM UTC George Robinson wrote:
>
>> I just checked the code, and the reason `"\d"` needs to be escaped is we
>> call strconv.Unquote <https://pkg.go.dev/strconv#Unquote> to unquote the
>> right hand side of the expression. In other words, to turn `"\d"` into
>> just `\d`.
>>
>> That means while the lexer accepts `"\d"`, it is not a valid double
>> quoted string that follows the Go escaping rules, and so it is rejected.
>> However `"\\d"` is because when it is unquoted the second backslash is
>> treated as an escape character and we end up with `\d`.
>>
>> The tl;dr here is that when using double quotes you need to follow Go's
>> rules in double quoted strings.
>>
>> As Brian mentioned, this is separate from YAML escape rules.
>>
>> We can update the docs to make this clear.
>> On Friday, December 6, 2024 at 11:56:11 AM UTC George Robinson wrote:
>>
>>> I believe Brian is correct. In the new parser, backslash is an escape
>>> character, so to write a literal backslash (for \d) it would need to be
>>> escaped as \\. You'll find the same behavior in languages like Go where
>>> "^SNSVC\d{7}$" is not a valid string (unknown escape sequence) and must
>>> be written as "^SNSVC\\d{7}$".
>>>
>>> The suggestion in the log line gave you the correct matcher, but the
>>> wrong explanation.
>>>
>>> We can add this to the documentation to make it clear.
>>>
>>> George
>>>
>>> On Friday, December 6, 2024 at 10:56:46 AM UTC Brian Candler wrote:
>>>
>>>> I checked at
>>>> https://prometheus.io/docs/alerting/latest/configuration/#matcher
>>>>
>>>> AFAICS, it doesn't explicitly mention the behaviour of backslashes in
>>>> UTF-8 matches. There is a specific note about the fallback behaviour of
>>>> classic
>>>> matchers
>>>> <https://prometheus.io/docs/alerting/latest/configuration/#classic-matchers>
>>>> though:
>>>>
>>>> "However, literal line feed characters are tolerated, as are single \
>>>> characters
>>>> not followed by \, n, or ". They act as a literal backslash in that
>>>> case."
>>>>
>>>> Assuming that UTF-8 matchers strictly require literal backslashes to be
>>>> doubled (\\), this would explain why your expression was accepted by
>>>> classic matchers but not UTF-8 matchers. The warning message "To make this
>>>> input compatible with the UTF-8 matchers parser please make sure all
>>>> regular expressions and values are double-quoted" could perhaps be
>>>> improved
>>>> to mention this possibility.
>>>>
>>>> On Friday, 6 December 2024 at 10:45:32 UTC Brian Candler wrote:
>>>>
>>>>> A bit more context would be helpful. Did you write:
>>>>>
>>>>> matchers:
>>>>> - applicationid=~"^SNSVC\d{7}$"
>>>>>
>>>>> or something else?
>>>>>
>>>>> Testing with alertmanager 0.27, I think the problem is around handling
>>>>> of the backslash. The following is accepted by amtool check-config:
>>>>>
>>>>> matchers:
>>>>> - applicationid=~"^SNSVC\\d{7}$"
>>>>>
>>>>> but I've not checked if it matches as expected - you don't want to
>>>>> match a literal backslash and d!
>>>>>
>>>>> This is also what the "suggestion" was telling you from the error
>>>>> message, but then it's also having to escape things for logfmt logging,
>>>>> which means double-quotes are preceded by backslash, and backslashes are
>>>>> doubled. When it says:
>>>>> suggestion="applicationid=~\"^SNSVC\\\\d{7}$\""
>>>>> I think what it's actually suggesting is:
>>>>> applicationid=~"^SNSVC\\d{7}$"
>>>>>
>>>>> Unfortunately, YAML also has its own rules for backslashes. Because of
>>>>> this complexity, I avoid backslashes in regexps where possible, for
>>>>> example
>>>>> using [.] instead of \. to match a literal dot. In your case, you could
>>>>> write:
>>>>>
>>>>> matchers:
>>>>> - applicationid=~"^SNSVC[0-9]{7}$"
>>>>>
>>>>> and there would be no ambiguity.
>>>>>
>>>>> On Friday, 6 December 2024 at 09:58:28 UTC Chris Burke wrote:
>>>>>
>>>>>> Can someone please help explain the following Alertmanager warning.
>>>>>> I know it's trying to tell me that my value needs to be
>>>>>> double-quoted, but it already is, so I do not understand what it is
>>>>>> complaining about.
>>>>>> My config: applicationid=~"^SNSVC\d{7}$"
>>>>>>
>>>>>> Thanks for any help
>>>>>>
>>>>>> ts=2024-12-06T00:44:13.964Z caller=parse.go:176 level=warn
>>>>>> msg="Alertmanager is moving to a new parser for labels and matchers, and
>>>>>> this input is incompatible. Alertmanager has instead parsed the input
>>>>>> using
>>>>>> the classic matchers parser as a fallback. To make this input compatible
>>>>>> with the UTF-8 matchers parser please make sure all regular expressions
>>>>>> and
>>>>>> values are double-quoted. If you are still seeing this message please
>>>>>> open
>>>>>> an issue." input="applicationid=~\"^SNSVC\\d{7}$\"" origin=config
>>>>>> err="15:29: \"^SNSVC\\d{7}$\": invalid input"
>>>>>> suggestion="applicationid=~\"^SNSVC\\\\d{7}$\""
>>>>>>
>>>>>>
--
You received this message because you are subscribed to the Google Groups
"Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/prometheus-users/d5826655-5e9f-4158-9585-9f7af0378df0n%40googlegroups.com.
