Alertmanager inhibition rules

[Jack Neely]

I'm having a bit of trouble configuring inhibition rules correctly.  The idea was to inhibit alerts with severity!="page" when the same alert with severity="page" exists.  Perhaps I've mucked up my regexes and I figured someone here as done this before.

What I currently have:

  "inhibit_rules": [

    {

      "target_match_re": {

        "severity": "[^pP]|[pP][^aA]|[pP][aA][^gG]|[pP][aA][gG][^eE]"

      },

      "source_match_re": {

        "severity": "[pP][aA][gG][eE]"

      },

      "equal": [

        "alertname",

        "monitor"

      ]

    }

  ],

Jack Neely

--

Jack Neely
Operations Engineer
42 Lines, Inc.

[Jack Neely]

Another question:

If I have child routes setup like this:

      {

        "receiver": "graphite-mail",

        "match": {

          "monitor": "graphite"

        },

        "routes": [

          {

            "receiver": "graphite-page",

            "match": {

              "severity": "page"

            }

          }

        ]

      },

Shouldn't both the "graphite-mail" and "graphite-page" receivers notify with continue = true?  I get the latter page when severity="page" but not the matching email alert from "graphite-mail"

Thanks for your help!

Jack 

[Fabian Reinartz]

First of all, if you standardize for "page" within your entire company, I highly recommend just standardizing to lowercase as well.

Allowing mixed case is just highly error prone.

For that reason the target regexp is off. It also matches "page", which is the opposite of what you want.

The sensible thing to do is to clearly standardize what values "severity" may have, and define the regexp based on that.

For example, if you have three levels (info, ticket, page) the target regexp could simply be "(info|ticket)".

If you really want to allow unbound values for "severity", the target regexp could be "[^(page)]".

This still assumes "page" to always be lowercase.

To your second question:

Your config doesn't show any "continue" set to true.

The "graphite-page" is a sub-route of the previous one. "continue" (if set) only affects following routes on the same level.

If you always want those to go together, just specify a single "graphite" receiver and configure it with email and your paging service combined.

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jack Neely]

Thanks for the suggestions.  I had missed that detail about "continue" completely.  I had it defined in the root route thinking it would be inherited. 

[cofyc....@gmail.com]

On Saturday, March 19, 2016 at 3:55:37 AM UTC+8, Fabian Reinartz wrote:
> First of all, if you standardize for "page" within your entire company, I highly recommend just standardizing to lowercase as well.
> Allowing mixed case is just highly error prone.
>
>
> For that reason the target regexp is off. It also matches "page", which is the opposite of what you want.
>
>
> The sensible thing to do is to clearly standardize what values "severity" may have, and define the regexp based on that.
> For example, if you have three levels (info, ticket, page) the target regexp could simply be "(info|ticket)".
>
>
> If you really want to allow unbound values for "severity", the target regexp could be "[^(page)]".

`[^(page)]` cannot match non "page" strings. Golang regexp package does not support this syntax.