Thanks for this, really appreciate it. Was a bit thrown by the warning message focusing on the double quotes even though the value had them. This clarifies thing nicely. Thanks again!
On Saturday, December 7, 2024 at 2:44:13 AM UTC+13 George Robinson wrote: > 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 prometheus-users+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/prometheus-users/815b97a8-7e93-43b7-ae36-f8f6f058901cn%40googlegroups.com.
