From 0ed31c3311c66eda25677b6f81aa123809b4109a Mon Sep 17 00:00:00 2001
From: beorn7 <beorn@grafana.com>
Date: Thu, 6 May 2021 19:17:25 +0200
Subject: [PATCH] Update matcher examples

While the documentation for the matchers themselves was updated, we
missed the examples.

I propose to merge this into the release-0.22 branch so that it gets
included in the ongoing release.

Signed-off-by: beorn7 <beorn@grafana.com>
---
 doc/examples/simple.yml | 36 +++++++++++++++++-------------------
 docs/configuration.md   | 16 ++++++++--------
 2 files changed, 25 insertions(+), 27 deletions(-)

diff --git a/doc/examples/simple.yml b/doc/examples/simple.yml
index 02063546..1cd24b9c 100644
--- a/doc/examples/simple.yml
+++ b/doc/examples/simple.yml
@@ -47,39 +47,39 @@ route:
   routes:
   # This routes performs a regular expression match on alert labels to
   # catch alerts that are related to a list of services.
-  - match_re:
-      service: ^(foo1|foo2|baz)$
+  - matchers:
+    - service=~"foo1|foo2|baz"
     receiver: team-X-mails
     # The service has a sub-route for critical alerts, any alerts
     # that do not match, i.e. severity != critical, fall-back to the
     # parent node and are sent to 'team-X-mails'
     routes:
-    - match:
-        severity: critical
+    - matchers:
+      - severity="critical"
       receiver: team-X-pager
-  - match:
-      service: files
+  - matchers:
+    - service="files"
     receiver: team-Y-mails
 
     routes:
-    - match:
-        severity: critical
+    - matchers:
+      - severity="critical"
       receiver: team-Y-pager
 
   # This route handles all alerts coming from a database service. If there's
   # no team to handle it, it defaults to the DB team.
-  - match:
-      service: database
+  - matchers:
+    - service="database"
     receiver: team-DB-pager
     # Also group alerts by affected database.
     group_by: [alertname, cluster, database]
     routes:
-    - match:
-        owner: team-X
+    - matchers:
+      - owner="team-X"
       receiver: team-X-pager
       continue: true
-    - match:
-        owner: team-Y
+    - matchers:
+      - owner="team-Y"
       receiver: team-Y-pager
 
 
@@ -88,16 +88,14 @@ route:
 # We use this to mute any warning-level notifications if the same alert is
 # already critical.
 inhibit_rules:
-- source_match:
-    severity: 'critical'
-  target_match:
-    severity: 'warning'
+- source_matchers: [ severity="critical" ]
+  target_matchers: [ severity="warning" ]
   # Apply inhibition if the alertname is the same.
   # CAUTION:
   #   If all label names listed in `equal` are missing
   #   from both the source and target alerts,
   #   the inhibition rule will apply!
-  equal: ['alertname', 'cluster', 'service']
+  equal: [ alertname, cluster, service ]
 
 
 receivers:
diff --git a/docs/configuration.md b/docs/configuration.md
index a2902285..07133ca0 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -211,15 +211,15 @@ route:
   # are dispatched to the database pager.
   - receiver: 'database-pager'
     group_wait: 10s
-    match_re:
-      service: mysql|cassandra
+    matchers:
+    - service=~"mysql|cassandra"
   # All alerts with the team=frontend label match this sub-route.
   # They are grouped by product and environment rather than cluster
   # and alertname.
   - receiver: 'frontend-pager'
     group_by: [product, environment]
-    match:
-      team: frontend
+    matchers:
+    - team="frontend"
 ```
 
 ## `<mute_time_interval>`
@@ -326,7 +326,7 @@ source_match_re:
 # A list of matchers for which one or more alerts have 
 # to exist for the inhibition to take effect.
 source_matchers:
-   [ - <matcher> ... ]
+  [ - <matcher> ... ]
 
 # Labels that must have an equal value in the source and target
 # alert for the inhibition to take effect.
@@ -705,12 +705,12 @@ The 3rd token may be the empty string. Within the 3rd token, OpenMetrics escapin
 
 In the configuration, multiple matchers are combined in a YAML list. However, it is also possible to combine multiple matchers within a single YAML string, again using syntax inspired by PromQL. In such a string, a leading `{` and/or a trailing `}` is optional and will be trimmed before further parsing. Individual matchers are separated by commas outside of quoted parts of the string. Those commas may be surrounded by whitespace. Parts of the string inside unescaped double quotes `"…"` are considered quoted (and commas don't act as separators there). If double quotes are escaped with a single backslash `\`, they are ignored for the purpose of identifying quoted parts of the input string. If the input string, after trimming the optional trailing `}`, ends with a comma, followed by optional whitespace, this comma and whitespace will be trimmed.
 
-Here are some examples of valid string matchers :
+Here are some examples of valid string matchers:
 
 1. Shown below are two equality matchers combined in a long form YAML list.
 
 ```yaml
-  matchers :
+  matchers:
    - foo = bar
    - dings !=bums 
 ```
@@ -912,4 +912,4 @@ API](http://admin.wechat.com/wiki/index.php?title=Customer_Service_Messages).
 [ to_user: <string> | default = '{{ template "wechat.default.to_user" . }}' ]
 [ to_party: <string> | default = '{{ template "wechat.default.to_party" . }}' ]
 [ to_tag: <string> | default = '{{ template "wechat.default.to_tag" . }}' ]
-```
\ No newline at end of file
+```