Alertmanager: continue:true not matching after the first match

[mindprince]

I have the following route configuration:

route:
  continue: true

  # default
  receiver: hipchat-test

  routes:
    - match:
        notify: hipchat-test
      receiver: hipchat-test
      continue: true

    - match:
        notify: hipchat
      receiver: hipchat
      continue: true

    - match:
        notify: hipchat-net
      receiver: hipchat-net
      continue: true

    - match:
        notify: hipchat-data
      receiver: hipchat-data
      continue: true

    - match:
        notify_team: hipchat-data
      receiver: hipchat-data
      continue: true

My alert has these labels: {notify_team="hipchat-data", notify="hipchat"}
But it is only getting routed to hipchat and not to hipchat-data. I want to route to both of these.
Not sure if I am doing something wrong or if continue is broken.

[mindprince]

I tested using: https://prometheus.io/webtools/alerting/routing-tree-editor/

[dqminh]

i took a brief look and I think there should be a bug in https://github.com/prometheus/alertmanager/blob/master/ui/lib/routing-tree.js#L59-L62. In the cases of multiple matches, we only take the first match.

Also specified in the doc:

A route block defines a node in a routing tree and its children.
Its optional configuration parameters are inherited from its parent node if not set.

However continue is not inherited https://github.com/prometheus/alertmanager/blob/master/route.go#L97. I'm not sure if this is a bug in documentation or code.

[brian-brazil]

Continue should not be inherited.

[raypettersen]

Stumbled across the same problem today. Is this a bug or what? How can I send an alert to multiple receivers??

[rohit01]

Same problem. It's not working for me as well.

[rohit01]

Gocha..
Continue works if specified for child routes. This attribute does not look like an inherited one.

[ngu04]

@rohit01 if you don't mind can you please share route configuration . As it doesn't work for me .

[mkrakowitzer]

Hopefully this helps:

route:
  group_by: ['cluster','alertname','host']
  group_wait: 30s
  group_interval: 2m
  repeat_interval: 10m
  receiver: slack_general
  routes:
  - match:
      severity: warning
    receiver: slack_general
    continue: true
  - match:
        severity: critical
    receiver: slack_general
    continue: true
  - match:
        severity: warning
    receiver: pagerduty
    continue: true
  - match:
        severity: critical
    receiver: pagerduty
    continue: true

[ngu04]

continue true doesn't work for me . Can someone tell what is wrong here ?

global:
  smtp_smarthost: {{ getv "/alert/smtp/host" }}
  smtp_from: {{ getv "/alert/smtp/from" }}
route:
  receiver: slack_recs_alerts
  group_by: [alertname, cluster]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  routes:
  - match:
      severity: ^([a-bA-Z]*)$
    receiver: slack_recs_alerts
    continue: true
  - match:
      severity: ^([a-bA-Z]*)$
    receiver: team-recs-mails
    continue: true
inhibit_rules:
- source_match:
    severity: critical
  target_match:
    severity: warning
  # Apply inhibition if the alertname is the same.
  equal: [alertname]
receivers:
- name: team-recs-mails
  email_configs:
  - to: {{ getv "/alert/smtp/to" }}
    require_tls: false

- name: slack_recs_alerts
  slack_configs:
  - api_url: {{ getv "/slack/api/url" }}
    channel: #{{ getv "/slack/channel" }}

[rohit01]

@ngu04 Configuration logic looks good.

Please use match_re instead of match.
^([a-bA-Z]*)$ => This is a regular expression. You need to use match_re. Otherwise, it will go to the default receiver: slack_recs_alerts.

It should work after this change.

[conr]

I've tested this using the latest release of Alertmanager using continue correctly as pointed out by @rohit01 and the issue appears to have been resolved.

However, this issue is still present on the routing tree editor on prometheus.io.

[mxinden]

Closing here as @Conorbro reported this to be fixed and routing tree editor fixes have been merged. Please feel free to reopen in case I am wrong.