diff --git a/modules/monitoring-configuring-notifications-for-default-platform-alerts.adoc b/modules/monitoring-configuring-notifications-for-default-platform-alerts.adoc index 10cce56f1dc4..d029f9f22b1d 100644 --- a/modules/monitoring-configuring-notifications-for-default-platform-alerts.adoc +++ b/modules/monitoring-configuring-notifications-for-default-platform-alerts.adoc @@ -42,10 +42,12 @@ $ 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: @@ -53,26 +55,27 @@ route: repeat_interval: 2m receiver: watchdog - matchers: - - "service=" #<4> + - "service=" # <5> routes: - matchers: - - #<5> - receiver: #<6> + - # <6> + receiver: # <7> receivers: - name: default - name: watchdog - name: - #<7> + # <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: "" + 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: diff --git a/modules/monitoring-configuring-notifications-for-user-defined-alerts.adoc b/modules/monitoring-configuring-notifications-for-user-defined-alerts.adoc index 8f8c5a26477e..d8852a26d3bd 100644 --- a/modules/monitoring-configuring-notifications-for-user-defined-alerts.adoc +++ b/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: #<2> + - "service = prometheus-example-monitor" # <2> + receiver: # <3> receivers: - name: Default - name: - #<3> + # <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: +