Case insensitive regex for Alertmanager

[Shubham Choudhary]

Can we write Case insensitive regex for Alertmanager?

For example, label is {team="analytics"} but sometimes it can be {team="Analytics"} or {team="ANALYTICS"}

- receiver: opsgenie-ANALYTICS_Prometheus

  match_re:

    chef_env: .*analytics.*

    severity: ^(critical)$

I have used (?i:(Match)) as mentioned in https://groups.google.com/g/prometheus-users/c/xOeIocdR_hI/m/bK1lDYF5AQAJ but didn't work.

[Christian Hoffmann]

Hi,

Hrm, I would have expected it to work. Could it be some quoting issue?
I'd use single quotes as soon as some non-word characters are included.
What was the behavior you were seeing? What version of alertmanager are
you using?

A quick test with alertmanager 0.21's amtool looks like it would be
working as expected, see below.

Kind regards,
Christian


$ cat test.yml
route:
receiver: 'default'
routes:
- match_re:
severity: '(?i:critical)'
receiver: critical

receivers:
- name: 'default'
- name: 'critical'

$ ./amtool config routes --config.file test.yml test severity=CrItIcAl
critical

[Brian Candler]

Your rule is matching a label called "chef_env" not "team".

[Shubham Choudhary]

'(?i:critical)' regex is working fine for case insensitivity.  Similarly, I used '(?analytics)'. 

Actually, I was doing testing on https://www.prometheus.io/webtools/alerting/routing-tree-editor/ not on amtool. On amtool, I can see regex working perfectly fine.

Some error in routing-tree-editor

 

>> Your rule is matching a label called "chef_env" not "team".

Sorry, for the typo. I meant team only.

Thanks,

Shubham

[Brian Candler]

So are you saying that it's only the routing-tree-editor that doesn't work as expected?

Also remember that in prometheus regexps are anchored at start and end, so

  match_re:

    chef_env: .*analytics.*

    severity: ^(critical)$

can be simplified to

  match_re:

    chef_env: .*analytics.*

    severity: critical

[Shubham Choudhary]

This online tool https://www.prometheus.io/webtools/alerting/routing-tree-editor/  didn't take '(?i:critical)' but in amtool it worked fine.

 ^(critical)$ -->  critical, Thanks for this.

[Brian Candler]

I see what you mean.  With match_re, it accepts

        alertname: '(?:OnBattery)'

but not

        alertname: '(?i:OnBattery)'

I think I can see why it's broken.  If I open the Javascript console, then use the second regexp, it barfs with:

routing-tree.js:163 Uncaught SyntaxError: Invalid regular expression: /^(?:(?i:OnBattery))$/: Invalid group

    at new RegExp (<anonymous>)

    at massage (routing-tree.js:163)

    at routing-tree.js:177

That is, the implementation already decided to wrap the regexp in ^(?:...)$, presumably to anchor it, and the (?i:...) syntax can't be nested inside.  I think it would be better not to wrap it, but instead to check that the match has a start point of 0 and a length equal to the original string length.

I don't know who maintains routing-tree-editor, but it looks a bit broken in other ways too.  I gave it this simple config, and it couldn't draw it:

----

route:

  receiver: r1

  routes:

    - receiver: r2

      match:

        alertname: OnBattery

----

But it works if I add an explicit fallback route for r1:

route:

  receiver: r1

  routes:

    - receiver: r2

      match:

        alertname: OnBattery

    - receiver: r1