1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/monitoring-configuring-external-alertmanagers.adoc

170 lines
6.2 KiB
Plaintext

// Module included in the following assemblies:
//
// * observability/monitoring/configuring-the-monitoring-stack.adoc
:_mod-docs-content-type: PROCEDURE
[id="monitoring-configuring-external-alertmanagers_{context}"]
= Configuring external Alertmanager instances
The {product-title} monitoring stack includes a local Alertmanager instance that routes alerts from Prometheus.
ifndef::openshift-dedicated,openshift-rosa[]
You can add external Alertmanager instances to route alerts for core {product-title} projects or user-defined projects.
endif::openshift-dedicated,openshift-rosa[]
ifdef::openshift-dedicated,openshift-rosa[]
You can add external Alertmanager instances to route alerts for user-defined projects.
endif::openshift-dedicated,openshift-rosa[]
If you add the same external Alertmanager configuration for multiple clusters and disable the local instance for each cluster, you can then manage alert routing for multiple clusters by using a single external Alertmanager instance.
.Prerequisites
ifndef::openshift-dedicated,openshift-rosa[]
* *If you are configuring core {product-title} monitoring components in the `openshift-monitoring` project*:
** You have access to the cluster as a user with the `cluster-admin` cluster role.
** You have created the `cluster-monitoring-config` config map.
* *If you are configuring components that monitor user-defined projects*:
** You have access to the cluster as a user with the `cluster-admin` cluster role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
** A cluster administrator has enabled monitoring for user-defined projects.
endif::openshift-dedicated,openshift-rosa[]
ifdef::openshift-dedicated,openshift-rosa[]
* You have access to the cluster as a user with the `dedicated-admin` role.
* The `user-workload-monitoring-config` `ConfigMap` object exists. This object is created by default when the cluster is created.
endif::openshift-dedicated,openshift-rosa[]
* You have installed the OpenShift CLI (`oc`).
.Procedure
. Edit the `ConfigMap` object.
ifndef::openshift-dedicated,openshift-rosa[]
** *To configure additional Alertmanagers for routing alerts from core {product-title} projects*:
.. Edit the `cluster-monitoring-config` config map in the `openshift-monitoring` project:
+
[source,terminal]
----
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
----
.. Add an `additionalAlertmanagerConfigs:` section under `data/config.yaml/prometheusK8s`.
.. Add the configuration details for additional Alertmanagers in this section:
+
[source,yaml]
----
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-monitoring-config
namespace: openshift-monitoring
data:
config.yaml: |
prometheusK8s:
additionalAlertmanagerConfigs:
- <alertmanager_specification>
----
+
For `<alertmanager_specification>`, substitute authentication and other configuration details for additional Alertmanager instances.
Currently supported authentication methods are bearer token (`bearerToken`) and client TLS (`tlsConfig`).
The following sample config map configures an additional Alertmanager using a bearer token with client TLS authentication:
+
[source,yaml]
----
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-monitoring-config
namespace: openshift-monitoring
data:
config.yaml: |
prometheusK8s:
additionalAlertmanagerConfigs:
- scheme: https
pathPrefix: /
timeout: "30s"
apiVersion: v1
bearerToken:
name: alertmanager-bearer-token
key: token
tlsConfig:
key:
name: alertmanager-tls
key: tls.key
cert:
name: alertmanager-tls
key: tls.crt
ca:
name: alertmanager-tls
key: tls.ca
staticConfigs:
- external-alertmanager1-remote.com
- external-alertmanager1-remote2.com
----
** *To configure additional Alertmanager instances for routing alerts from user-defined projects*:
endif::openshift-dedicated,openshift-rosa[]
.. Edit the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` project:
+
[source,terminal]
----
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
----
.. Add a `<component>/additionalAlertmanagerConfigs:` section under `data/config.yaml/`.
.. Add the configuration details for additional Alertmanagers in this section:
+
[source,yaml]
----
apiVersion: v1
kind: ConfigMap
metadata:
name: user-workload-monitoring-config
namespace: openshift-user-workload-monitoring
data:
config.yaml: |
<component>:
additionalAlertmanagerConfigs:
- <alertmanager_specification>
----
+
For `<component>`, substitute one of two supported external Alertmanager components: `prometheus` or `thanosRuler`.
+
For `<alertmanager_specification>`, substitute authentication and other configuration details for additional Alertmanager instances. Currently supported authentication methods are bearer token (`bearerToken`) and client TLS (`tlsConfig`). The following sample config map configures an additional Alertmanager using Thanos Ruler with a bearer token and client TLS authentication:
+
[source,yaml]
----
apiVersion: v1
kind: ConfigMap
metadata:
name: user-workload-monitoring-config
namespace: openshift-user-workload-monitoring
data:
config.yaml: |
thanosRuler:
additionalAlertmanagerConfigs:
- scheme: https
pathPrefix: /
timeout: "30s"
apiVersion: v1
bearerToken:
name: alertmanager-bearer-token
key: token
tlsConfig:
key:
name: alertmanager-tls
key: tls.key
cert:
name: alertmanager-tls
key: tls.crt
ca:
name: alertmanager-tls
key: tls.ca
staticConfigs:
- external-alertmanager1-remote.com
- external-alertmanager1-remote2.com
----
. Save the file to apply the changes to the `ConfigMap` object. The new component placement configuration is applied automatically.
. Save the file to apply the changes to the `ConfigMap` object. The new component placement configuration is applied automatically.