[enterprise-4.12] Issue in file monitoring/configuring-the-monitoring-stack.adoc

[pfeifferj]

Which section(s) is the issue in?

https://docs.openshift.com/container-platform/4.12/monitoring/configuring-the-monitoring-stack.html

What needs fixing?

There is conflicting or unclear information with regard to custom alertmanager configs. In one section it is mentioned, that these should be made in a secret resource and in another section, it's a ConfigMap. This should be clarified.

Example:

To configure core OpenShift Container Platform monitoring components, you must create the cluster-monitoring-config ConfigMap object in the openshift-monitoring project.

The Alertmanager configuration is deployed as a secret resource in the openshift-monitoring namespace. If you have enabled a separate Alertmanager instance for user-defined alert routing, an Alertmanager configuration is also deployed as a secret resource in the openshift-user-workload-monitoring namespace. To configure additional routes for any instance of Alertmanager, you need to decode, modify, and then encode that secret. This procedure is a supported exception to the preceding statement.

[bburt-rh]

@pfeifferj - Thanks for taking the time to write up this issue. I am the technical writer for monitoring, and we will investigate and decide how best to resolve the issue.

@simonpasquier or @jan--f - Can you PTAL at this issue and comment about the best way to address it?

[bburt-rh]

@simonpasquier @jan--f - Can you PTAL?

[simonpasquier]

The first sentence refers to the cluster monitoring operator's configuration which lives in the cluster-monitoring-config ConfigMap. The second sentence refers to the Alertmanager's configuration which lives either in the alertmanager-main secret (openshift-monitoring namespace) or in the alertmanager-user-workload secret (openshift-user-workload-monitoring namespace).

Having said that, we could mention explicitly the names of the Alertmanager secrets in the documentation.

[bburt-rh]

We are now tracking this as a doc issue here: https://issues.redhat.com/browse/RHDEVDOCS-5300

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[bburt-rh]

/remove-lifecycle stale

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[bburt-rh]

/remove-lifecycle stale

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[bburt-rh]

/lifecycle frozen