Silence form fails to parse matchers with double quotes for alert preview

[mst-ableton]

What did you do?

Made a silence with quotes around the label value.

What did you expect to see?

The affected alert would be silenced, as it was listed under "affected alerts" when the silence was previewed and created.

What did you see instead? Under which circumstances?

The alert was not silenced, even though it was listed as affected.

Environment

• System information:

Linux 4.9.125-linuxkit x86_64

• Alertmanager version:

alertmanager, version 0.17.0 (branch: HEAD, revision: c7551cd)
build user: root@932a86a52b76
build date: 20190503-09:10:07
go version: go1.12.4

• Prometheus version:

N/A

• Alertmanager configuration file:

N/A

• Prometheus configuration file:

N/A

• Logs:

N/A

Steps to repro:

amtool alert --alertmanager.url localhost:9093 add node="node with spaces"

---

Create a new silence with quotes around the value. Note that the "affected alerts" shows that the currently firing alert is affected.

---

Go back to the main screen. The alert is still there, because it was not actually silenced:

---

Make a new silence without quotes:

---

Only now is the alert properly silenced:

Thanks for alertmanager, and thanks in advance for taking a look into this!

[stuartnelson3]

The quotes aren't necessary in the matcher value, since what is entered as the matcher value ends up being sent within "".

Looking at the "preview" request, it looks like when a value has double quotes inside of it, the matcher value fails to parse, and the entire filter= query string gets dropped. That part is definitely a bug.

To summarize:

The silence form matchers fail to be parsed correctly when one of the matcher value input fields includes double quotes.

[stuartnelson3]

@w0rm started taking a look at this, and it seems to have something to do with how we're parsing item? https://github.com/prometheus/alertmanager/blob/master/ui/app/src/Utils/Filter.elm#L266-L282

any quick ideas why alertname="\"\"" is failing based on the definition?

EDIT:
seems to actually have been helpfully commented by you :)
https://github.com/prometheus/alertmanager/blob/master/ui/app/src/Utils/Filter.elm#L291-L292

[uepoch]

Did you guys had the time to look at it ? We are also impacted
If you are not looking at it actively, we might check the Filter/stringify_matcher issue

[mickael-carl]

Hitting this as well: adding quotes around a label value makes the match invalid. If that is the only matcher in the silence, then all alerts are listed as silenced in preview, which is weirdly confusing, why would all alerts be matched when having an invalid matcher?

[rosenkrmnv]

Hello, im here because im also hitting this issue. For my case im also trying to silence alerts from node="node with spaces"
and I cannot create this silencer from the UI due to exactly the same behavior described in the issue. I also cannot add such silencer to silences.conf, because amtool cannot parse this silencer correctly.

Steps to reproduce:

1. Add new silencer containing space in silences.conf

node="node with spaces" or node=node with spaces

2. Apply config
3. Check silences using amtool silence
4. Results

for node=node with spaces - after amtool parses silences.conf the silencer is not created (same if I try with single quotes)
for node="node with spaces" - amtool parses silences.conf -> silence is created, but it has double quotes -> so we hit the issue initially described in this bug.

[beorn7]

Yeah, there is an escaping problem.

I mean, generally, you should probably not create a label where the value is quoted. But if you really want to, for some weird reason, then it should still work.

I noticed a few other escaping problems, too, and want to work on it "soon" (TM).

For now, could you try what happens if you escape the quotes in the silence form with a backslash? I.e. enter \"node with spaces\".