[enterprise-4.18] OBSDOCS-181: Alertmanager should use the proxy environment variables

modules/monitoring-configuring-notifications-for-default-platform-alerts.adoc

@@ -42,37 +42,40 @@ $ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .
 ----
 global:
   resolve_timeout: 5m
+  http_config:
+    proxy_from_environment: true # <1>
 route:
-  group_wait: 30s #<1>
-  group_interval: 5m #<2>
-  repeat_interval: 12h #<3>
+  group_wait: 30s # <2>
+  group_interval: 5m # <3>
+  repeat_interval: 12h # <4>
   receiver: default
   routes:
   - matchers:
     - "alertname=Watchdog"
     repeat_interval: 2m
     receiver: watchdog
   - matchers:
-    - "service=<your_service>" #<4>
+    - "service=<your_service>" # <5>
     routes:
     - matchers:
-      - <your_matching_rules> #<5>
-      receiver: <receiver> #<6>
+      - <your_matching_rules> # <6>
+      receiver: <receiver> # <7>
 receivers:
 - name: default
 - name: watchdog
 - name: <receiver>
-  <receiver_configuration> #<7>
+  <receiver_configuration> # <8>
 ----
-<1> Specify how long Alertmanager waits while collecting initial alerts for a group of alerts before sending a notification.
-<2> Specify how much time must elapse before Alertmanager sends a notification about new alerts added to a group of alerts for which an initial notification was already sent.
-<3> Specify the minimum amount of time that must pass before an alert notification is repeated.
+<1> If you configured an HTTP cluster-wide proxy, set the `proxy_from_environment` parameter to `true` to enable proxying for all alert receivers.
+<2> Specify how long Alertmanager waits while collecting initial alerts for a group of alerts before sending a notification.
+<3> Specify how much time must elapse before Alertmanager sends a notification about new alerts added to a group of alerts for which an initial notification was already sent.
+<4> Specify the minimum amount of time that must pass before an alert notification is repeated.
 If you want a notification to repeat at each group interval, set the `repeat_interval` value to less than the `group_interval` value.
 The repeated notification can still be delayed, for example, when certain Alertmanager pods are restarted or rescheduled.
-<4> Specify the name of the service that fires the alerts.
-<5> Specify labels to match your alerts.
-<6> Specify the name of the receiver to use for the alerts.
-<7> Specify the receiver configuration.
+<5> Specify the name of the service that fires the alerts.
+<6> Specify labels to match your alerts.
+<7> Specify the name of the receiver to use for the alerts.
+<8> Specify the receiver configuration.
 +
 [IMPORTANT]
 ====
@@ -89,12 +92,13 @@ Do not use the `match` or `match_re` key names, which are both deprecated and pl
 Do not use the `target_match`, `target_match_re`, `source_match`, or `source_match_re` key names, which are deprecated and planned for removal in a future release.
 ====
 +
-The following Alertmanager configuration example configures PagerDuty as an alert receiver:
-+
+.Example of Alertmanager configuration with PagerDuty as an alert receiver
 [source,yaml]
 ----
 global:
   resolve_timeout: 5m
+  http_config:
+    proxy_from_environment: true
 route:
   group_wait: 30s
   group_interval: 5m
@@ -105,7 +109,7 @@ route:
     - "alertname=Watchdog"
     repeat_interval: 2m
     receiver: watchdog
-  - matchers:
+  - matchers: # <1>
     - "service=example-app"
     routes:
     - matchers:
@@ -117,9 +121,13 @@ receivers:
 - name: team-frontend-page
   pagerduty_configs:
   - service_key: "<your_key>"
+    http_config: # <2> 
+      proxy_from_environment: true
+      authorization:
+        credentials: xxxxxxxxxx
 ----
-+
-With this configuration, alerts of `critical` severity that are fired by the `example-app` service are sent through the `team-frontend-page` receiver. Typically, these types of alerts would be paged to an individual or a critical response team.
+<1> Alerts of `critical` severity that are fired by the `example-app` service are sent through the `team-frontend-page` receiver. Typically, these types of alerts would be paged to an individual or a critical response team.
+<2> Custom HTTP configuration for a specific receiver. If you configure the custom HTTP configuration for a specific alert receiver, that receiver does not inherit the global HTTP config settings.
 
 . Apply the new configuration in the file:
 

modules/monitoring-configuring-notifications-for-user-defined-alerts.adoc

@@ -31,22 +31,26 @@ $ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload
 +
 [source,yaml]
 ----
+global:
+  http_config:
+    proxy_from_environment: true # <1>
 route:
   receiver: Default
   group_by:
   - name: Default
   routes:
   - matchers:
-    - "service = prometheus-example-monitor" #<1>
-    receiver: <receiver> #<2>
+    - "service = prometheus-example-monitor" # <2>
+    receiver: <receiver> # <3>
 receivers:
 - name: Default
 - name: <receiver>
-  <receiver_configuration> #<3>
+  <receiver_configuration> # <4>
 ----
-<1> Specify labels to match your alerts. This example targets all alerts that have the `service="prometheus-example-monitor"` label.
-<2> Specify the name of the receiver to use for the alerts group.
-<3> Specify the receiver configuration.
+<1> If you configured an HTTP cluster-wide proxy, set the `proxy_from_environment` parameter to `true` to enable proxying for all alert receivers.
+<2> Specify labels to match your alerts. This example targets all alerts that have the `service="prometheus-example-monitor"` label.
+<3> Specify the name of the receiver to use for the alerts group.
+<4> Specify the receiver configuration.
 +
 . Apply the new configuration in the file:
 +