[prometheus-users] Re: Alertmanager is moving to a new parser for labels and matchers, and this input is incompatible.

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

[prometheus-users] Re: Alertmanager is moving to a new parser for labels and matchers, and this input is incompatible.

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

[prometheus-users] Re: Alertmanager is moving to a new parser for labels and matchers, and this input is incompatible.

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

[prometheus-users] Re: Alertmanager is moving to a new parser for labels and matchers, and this input is incompatible.

I just checked the code, and the reason `"\d"` needs to be escaped is we call 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 doubl

[prometheus-users] Re: Alertmanager is moving to a new parser for labels and matchers, and this input is incompatible.

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 writte

[prometheus-users] Re: Alertmanager is moving to a new parser for labels and matchers, and this input is incompatible.

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{

[prometheus-users] Re: Alertmanager is moving to a new parser for labels and matchers, and this input is incompatible.

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

[prometheus-users] Re: When computing, how to handle null values in PromQL.

"(A + B) or A or B" is correct. Remember that "A + B" is not a scalar arithmetic expression. It's a vector expression: - for every element in vector A and B which have exactly matching label sets (apart from __name__), calculate the sum and put it in the result vector with the same set of label

[prometheus-users] Alertmanager is moving to a new parser for labels and matchers, and this input is incompatible.

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.9

[prometheus-users] Cant delete metricd from pushgateway

I'm raising a pushgateway container through kubernetes with: ``` apiVersion: apps/v1 kind: Deployment metadata: name: pushgateway spec: replicas: 1 selector: matchLabels: app: pushgateway template: metadata: labels: app: pushgateway spec: containers: - name: pushgateway image: prom/pushgateway port

[prometheus-users] When computing, how to handle null values in PromQL.

I have two metrics, A and B. I want the result of A + B to be as follows: for time points where A does not exist, the result should be the value of B at that time point; for time points where B does not exist, the result should be the value of A at that time point; and for time points where both