With MON-2225, a cluster admin will be able to deploy a standalone Alertmanager for user-defined alerts. Since the OCP user interface leverages the Alertmanager API to display and manage alert silences, it needs to support this new deployment model.

When a silence is associated to an active alert, the console already knows
whether it comes from a "platform" or "user" alerting rule (platform rules have
the `prometheus="openshift-monitoring/k8s"` label). Provided that CMO tells the
console operator the name of the Alertmanager API service managing user alerts
(e.g. `alertmanager.openshift-user-workload-monitoring.svc` if UWM
Alertmanager is enabled), the console backend can infer which API service it
needs to request:

Admin console

• "Observe > Alerting > Silences"
  • When listing the silences, the console backend queries both Alertmanager services, merges the results and adds a field identifying the "origin" of the silence (platform vs. user).
  • When creating a silence, the user defines whether the silence is for platform or user alerts. The console backend uses the information to request the right Alertmanager API.
  • When editing/expiring a silence, the console frontend knows the origin and can pass the information to the console backend.
• "Observe > Alerting > Alerts" and "Observe > Alerting > Alert details"
  • The frontend knows the origin of the rule and can pass the information to the console backend.

Developer console

• "Observe > Alerts" page
  • When editing/expiring a silence, the console frontend knows the origin of the rule and can pass the information to the console backend.

Implementation-wise, CMO reuses the `monitoring-shared-config` ConfigMap in the
`openshift-config-managed` namespace to communicate to the console operator the
location of platform and user Alertmanager APIs. The operator passes down the
configuration to the console backend.