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/bdfd3dc4-8021-45c7-b58e-d13fab244521n%40googlegroups.com.
