This topic describes how to import Alertmanager routing rules to Application Real-Time Monitoring Service (ARMS) Alert Management as notification policies.

Background information

Alertmanager is an open source alert notification component that is indispensable to Prometheus-based monitoring solutions. The flexible routing, silence, and grouping capabilities of Alertmanager enable alert notifications to be sent more reasonably. However, Alertmanager has some flaws. For example, Alertmanager cannot send alert notifications by using text messages or phone calls. Alertmanager does not provide the capabilities to process alerts within a closed loop and integrate alert management with cloud services. Therefore, Alertmanager can be used only as an alert transfer station.

In addition to various capabilities of Alertmanager, ARMS Alert Management provides a unified platform to process and manage alerts. ARMS Alert Management is ideal for building a unified alert center because it is deployed on the cloud and is integrated with various systems on the cloud. This topic describes how to import the routing rules, grouping rules, and silencing rules that are configured in Alertmanager to ARMS Alert Management.

Entity mappings

  • The route field is mapped to a notification policy.
  • The match field is mapped to the Equal To condition.
  • The match_re field is mapped to the Match Regular Expression condition.
  • The group_by field is mapped to a grouping condition. If a child route does not have a grouping condition, it inherits the grouping condition of the parent route.

Limits

  • The receivers field cannot be imported to ARMS Alert Management. The field can contain contact settings such as email_configs, webhook_configs, dingtalk_configs, and pagerduty_configs.
  • The routing rules of Alertmanager are tree-structured. ARMS Alert Management supports only level-1 routes.
  • Alertmanager supports the continue field. In ARMS Alert Management, the continue field is set to true by default and cannot be modified.
    # Configuration example:
    # The root node of the routing tree.
    route:
    # Whether an alert should continue matching subsequent sibling nodes.
    [ continue: <boolean> | default = false ]
  • ARMS Alert Management supports the match and match_re fields but does not support the matchers field.
    # A set of equality matchers an alert has to fulfill to match the node.
    match:
      [ <labelname>: <labelvalue>, ... ]
    
    # A set of regex-matchers an alert has to fulfill to match the node.
    match_re:
      [ <labelname>: <regex>, ... ]
    # The matchers field is not supported.
    # A list of matchers that an alert has to fulfill to match the node.
    matchers:
      [ - <matcher> ... ]
  • The root route cannot be imported as a notification policy.
  • Routing rules do not have names. After a routing rule is imported to ARMS Alert Management, a random name is generated for the notification policy.
  • The inhibit_rules field cannot be imported.
  • The dispatch conditions of a notification policy that is generated by importing a routing rule cannot be modified.
  • Import operations are not idempotent. If you import a routing rule multiple times, multiple notification policies will be generated.

Procedure

  1. Obtain the configurations of Alertmanager.
    Example:
    global:
      smtp_smarthost: 'localhost:25'
      smtp_from: 'alertmanager@example.org'
      smtp_auth_username: 'alertmanager'
      smtp_auth_password: 'password'
    
    templates:
    - '/etc/alertmanager/template/*.tmpl'
    
    # The root route on which each incoming alert enters.
    route:
      group_by: ['alertname', 'cluster', 'service']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 3h
      receiver: team-X-mails
      routes:
      - match_re:
          service: "foo1|foo2|baz"
        receiver: team-X-mails
        routes:
        - match:
            severity: "critical"
          receiver: team-X-pager
      - match:
          service: "files"
        receiver: team-Y-mails
        routes:
        - match:
            severity: "critical"
          receiver: team-Y-pager
      - match:
          service: "database"
        receiver: team-DB-pager
        group_by: [alertname, cluster, database]
        routes:
        - match:
            owner: "team-X"
          receiver: team-X-pager
          continue: true
        - match:
            owner: "team-Y"
          receiver: team-Y-pager
    
    inhibit_rules:
    - source_matchers: [ severity="critical" ]
      target_matchers: [ severity="warning" ]
      equal: [ alertname, cluster, service ]
    
    
    receivers:
    - name: 'team-X-mails'
      email_configs:
      - to: 'team-X+alerts@example.org'
    
    - name: 'team-X-pager'
      email_configs:
      - to: 'team-X+alerts-critical@example.org'
      pagerduty_configs:
      - service_key: <team-X-key>
    
    - name: 'team-Y-mails'
      email_configs:
      - to: 'team-Y+alerts@example.org'
    
    - name: 'team-Y-pager'
      pagerduty_configs:
      - service_key: <team-Y-key>
    
    - name: 'team-DB-pager'
      pagerduty_configs:
      - service_key: <team-DB-key>
  2. Log on to the ARMS console. In the left-side navigation pane, choose Alert Management > Notification Policies. In the Notification Policies section, click Import.
  3. In the Import Notification Policies dialog box, paste the routing rules that is obtained in Step 1 and click Save.
    After a few moments, you can view the imported notification policies.