Questo contenuto non è disponibile nella lingua selezionata.
Chapter 14. Getting information about alerts, silences, and alerting rules from the Developer perspective
The Alerting UI provides detailed information about alerts and their governing alerting rules and silences.
Prerequisites
- You have access to the cluster as a user with view permissions for the project that you are viewing alerts for.
Procedure
To obtain information about alerts, silences, and alerting rules:
-
From the Developer perspective of the OpenShift Dedicated web console, go to the Observe
<project_name> Alerts page. View details for an alert, silence, or an alerting rule:
- Alert details can be viewed by clicking a greater than symbol (>) next to an alert name and then selecting the alert from the list.
Silence details can be viewed by clicking a silence in the Silenced by section of the Alert details page. The Silence details page includes the following information:
- Alert specification
- Start time
- End time
- Silence state
- Number and list of firing alerts
-
Alerting rule details can be viewed by clicking the
menu next to an alert in the Alerts page and then clicking View Alerting Rule.
Only alerts, silences, and alerting rules relating to the selected project are displayed in the Developer perspective.
Additional resources
- See the Cluster Monitoring Operator runbooks to help diagnose and resolve issues that trigger specific OpenShift Dedicated monitoring alerts.
14.1. Managing silences
You can create a silence for an alert in the OpenShift Dedicated web console in both the Administrator and Developer perspectives. After you create a silence, you will not receive notifications about an alert when the alert fires.
Creating silences is useful in scenarios where you have received an initial alert notification, and you do not want to receive further notifications during the time in which you resolve the underlying issue causing the alert to fire.
When creating a silence, you must specify whether it becomes active immediately or at a later time. You must also set a duration period after which the silence expires.
After you create silences, you can view, edit, and expire them.
When you create silences, they are replicated across Alertmanager pods. However, if you do not configure persistent storage for Alertmanager, silences might be lost. This can happen, for example, if all Alertmanager pods restart at the same time.
Additional resources
14.1.1. Silencing alerts from the Administrator perspective
You can silence a specific alert or silence alerts that match a specification that you define.
Prerequisites
-
You have access to the cluster as a user with the
cluster-admin
role.
Procedure
To silence a specific alert:
-
From the Administrator perspective of the OpenShift Dedicated web console, go to Observe
Alerting Alerts. -
For the alert that you want to silence, click
and select Silence alert to open the Silence alert page with a default configuration for the chosen alert.
Optional: Change the default configuration details for the silence.
NoteYou must add a comment before saving a silence.
- To save the silence, click Silence.
To silence a set of alerts:
-
From the Administrator perspective of the OpenShift Dedicated web console, go to Observe
Alerting Silences. - Click Create silence.
On the Create silence page, set the schedule, duration, and label details for an alert.
NoteYou must add a comment before saving a silence.
- To create silences for alerts that match the labels that you entered, click Silence.
14.1.2. Silencing alerts from the Developer perspective
You can silence a specific alert or silence alerts that match a specification that you define.
Prerequisites
-
If you are a cluster administrator, you have access to the cluster as a user with the
dedicated-admin
role. If you are a non-administrator user, you have access to the cluster as a user with the following user roles:
-
The
cluster-monitoring-view
cluster role, which allows you to access Alertmanager. -
The
monitoring-alertmanager-edit
role, which permits you to create and silence alerts in the Administrator perspective in the web console. -
The
monitoring-rules-edit
cluster role, which permits you to create and silence alerts in the Developer perspective in the web console.
-
The
Procedure
To silence a specific alert:
- From the Developer perspective of the OpenShift Dedicated web console, go to Observe and go to the Alerts tab.
- Select the project that you want to silence an alert for from the Project: list.
- If necessary, expand the details for the alert by clicking a greater than symbol (>) next to the alert name.
- Click the alert message in the expanded view to open the Alert details page for the alert.
- Click Silence alert to open the Silence alert page with a default configuration for the alert.
Optional: Change the default configuration details for the silence.
NoteYou must add a comment before saving a silence.
- To save the silence, click Silence.
To silence a set of alerts:
- From the Developer perspective of the OpenShift Dedicated web console, go to Observe and go to the Silences tab.
- Select the project that you want to silence alerts for from the Project: list.
- Click Create silence.
On the Create silence page, set the duration and label details for an alert.
NoteYou must add a comment before saving a silence.
- To create silences for alerts that match the labels that you entered, click Silence.
14.1.3. Editing silences from the Administrator perspective
You can edit a silence, which expires the existing silence and creates a new one with the changed configuration.
Prerequisites
-
If you are a cluster administrator, you have access to the cluster as a user with the
dedicated-admin
role. If you are a non-administrator user, you have access to the cluster as a user with the following user roles:
-
The
cluster-monitoring-view
cluster role, which allows you to access Alertmanager. -
The
monitoring-alertmanager-edit
role, which permits you to create and silence alerts in the Administrator perspective in the web console.
-
The
Procedure
-
From the Administrator perspective of the OpenShift Dedicated web console, go to Observe
Alerting Silences. For the silence you want to modify, click
and select Edit silence.
Alternatively, you can click Actions and select Edit silence on the Silence details page for a silence.
- On the Edit silence page, make changes and click Silence. Doing so expires the existing silence and creates one with the updated configuration.
14.1.4. Editing silences from the Developer perspective
You can edit a silence, which expires the existing silence and creates a new one with the changed configuration.
Prerequisites
-
If you are a cluster administrator, you have access to the cluster as a user with the
dedicated-admin
role. If you are a non-administrator user, you have access to the cluster as a user with the following user roles:
-
The
cluster-monitoring-view
cluster role, which allows you to access Alertmanager. -
The
monitoring-rules-edit
cluster role, which permits you to create and silence alerts in the Developer perspective in the web console.
-
The
Procedure
- From the Developer perspective of the OpenShift Dedicated web console, go to Observe and go to the Silences tab.
- Select the project that you want to edit silences for from the Project: list.
For the silence you want to modify, click
and select Edit silence.
Alternatively, you can click Actions and select Edit silence on the Silence details page for a silence.
- On the Edit silence page, make changes and click Silence. Doing so expires the existing silence and creates one with the updated configuration.
14.1.5. Expiring silences from the Administrator perspective
You can expire a single silence or multiple silences. Expiring a silence deactivates it permanently.
You cannot delete expired, silenced alerts. Expired silences older than 120 hours are garbage collected.
Prerequisites
-
If you are a cluster administrator, you have access to the cluster as a user with the
dedicated-admin
role. If you are a non-administrator user, you have access to the cluster as a user with the following user roles:
-
The
cluster-monitoring-view
cluster role, which allows you to access Alertmanager. -
The
monitoring-alertmanager-edit
role, which permits you to create and silence alerts in the Administrator perspective in the web console.
-
The
Procedure
-
Go to Observe
Alerting Silences. - For the silence or silences you want to expire, select the checkbox in the corresponding row.
Click Expire 1 silence to expire a single selected silence or Expire <n> silences to expire multiple selected silences, where <n> is the number of silences you selected.
Alternatively, to expire a single silence you can click Actions and select Expire silence on the Silence details page for a silence.
14.1.6. Expiring silences from the Developer perspective
You can expire a single silence or multiple silences. Expiring a silence deactivates it permanently.
You cannot delete expired, silenced alerts. Expired silences older than 120 hours are garbage collected.
Prerequisites
-
If you are a cluster administrator, you have access to the cluster as a user with the
dedicated-admin
role. If you are a non-administrator user, you have access to the cluster as a user with the following user roles:
-
The
cluster-monitoring-view
cluster role, which allows you to access Alertmanager. -
The
monitoring-rules-edit
cluster role, which permits you to create and silence alerts in the Developer perspective in the web console.
-
The
Procedure
- From the Developer perspective of the OpenShift Dedicated web console, go to Observe and go to the Silences tab.
- Select the project that you want to expire a silence for from the Project: list.
- For the silence or silences you want to expire, select the checkbox in the corresponding row.
Click Expire 1 silence to expire a single selected silence or Expire <n> silences to expire multiple selected silences, where <n> is the number of silences you selected.
Alternatively, to expire a single silence you can click Actions and select Expire silence on the Silence details page for a silence.
14.2. Managing alerting rules for user-defined projects
In OpenShift Dedicated, you can view, edit, and remove alerting rules in user-defined projects.
Managing alerting rules for user-defined projects is only available in OpenShift Dedicated version 4.11 and later.
Alerting rule considerations
- The default alerting rules are used specifically for the OpenShift Dedicated cluster.
- Some alerting rules intentionally have identical names. They send alerts about the same event with different thresholds, different severity, or both.
- Inhibition rules prevent notifications for lower severity alerts that are firing when a higher severity alert is also firing.
14.2.1. Optimizing alerting for user-defined projects
You can optimize alerting for your own projects by considering the following recommendations when creating alerting rules:
- Minimize the number of alerting rules that you create for your project. Create alerting rules that notify you of conditions that impact you. It is more difficult to notice relevant alerts if you generate many alerts for conditions that do not impact you.
- Create alerting rules for symptoms instead of causes. Create alerting rules that notify you of conditions regardless of the underlying cause. The cause can then be investigated. You will need many more alerting rules if each relates only to a specific cause. Some causes are then likely to be missed.
- Plan before you write your alerting rules. Determine what symptoms are important to you and what actions you want to take if they occur. Then build an alerting rule for each symptom.
- Provide clear alert messaging. State the symptom and recommended actions in the alert message.
- Include severity levels in your alerting rules. The severity of an alert depends on how you need to react if the reported symptom occurs. For example, a critical alert should be triggered if a symptom requires immediate attention by an individual or a critical response team.
Additional resources
- See the Prometheus alerting documentation for further guidelines on optimizing alerts
14.2.2. About creating alerting rules for user-defined projects
If you create alerting rules for a user-defined project, consider the following key behaviors and important limitations when you define the new rules:
A user-defined alerting rule can include metrics exposed by its own project in addition to the default metrics from core platform monitoring. You cannot include metrics from another user-defined project.
For example, an alerting rule for the
ns1
user-defined project can use metrics exposed by thens1
project in addition to core platform metrics, such as CPU and memory metrics. However, the rule cannot include metrics from a differentns2
user-defined project.To reduce latency and to minimize the load on core platform monitoring components, you can add the
openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus
label to a rule. This label forces only the Prometheus instance deployed in theopenshift-user-workload-monitoring
project to evaluate the alerting rule and prevents the Thanos Ruler instance from doing so.ImportantIf an alerting rule has this label, your alerting rule can use only those metrics exposed by your user-defined project. Alerting rules you create based on default platform metrics might not trigger alerts.
14.2.3. Creating alerting rules for user-defined projects
You can create alerting rules for user-defined projects. Those alerting rules will trigger alerts based on the values of the chosen metrics.
- When you create an alerting rule, a project label is enforced on it even if a rule with the same name exists in another project.
- To help users understand the impact and cause of the alert, ensure that your alerting rule contains an alert message and severity value.
Prerequisites
- You have enabled monitoring for user-defined projects.
-
You are logged in as a cluster administrator or as a user that has the
monitoring-rules-edit
cluster role for the project where you want to create an alerting rule. -
You have installed the OpenShift CLI (
oc
).
Procedure
-
Create a YAML file for alerting rules. In this example, it is called
example-app-alerting-rule.yaml
. Add an alerting rule configuration to the YAML file. The following example creates a new alerting rule named
example-alert
. The alerting rule fires an alert when theversion
metric exposed by the sample service becomes0
:apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: example-alert namespace: ns1 spec: groups: - name: example rules: - alert: VersionAlert 1 for: 1m 2 expr: version{job="prometheus-example-app"} == 0 3 labels: severity: warning 4 annotations: message: This is an example alert. 5
Apply the configuration file to the cluster:
$ oc apply -f example-app-alerting-rule.yaml
Additional resources
- See Monitoring overview for details about OpenShift Dedicated 4 monitoring architecture.
14.2.4. Accessing alerting rules for user-defined projects
To list alerting rules for a user-defined project, you must have been assigned the monitoring-rules-view
cluster role for the project.
Prerequisites
- You have enabled monitoring for user-defined projects.
-
You are logged in as a user that has the
monitoring-rules-view
cluster role for your project. -
You have installed the OpenShift CLI (
oc
).
Procedure
To list alerting rules in
<project>
:$ oc -n <project> get prometheusrule
To list the configuration of an alerting rule, run the following:
$ oc -n <project> get prometheusrule <rule> -o yaml
14.2.5. Listing alerting rules for all projects in a single view
As a dedicated-admin
, you can list alerting rules for core OpenShift Dedicated and user-defined projects together in a single view.
Prerequisites
-
You have access to the cluster as a user with the
dedicated-admin
role. -
You have installed the OpenShift CLI (
oc
).
Procedure
-
From the Administrator perspective of the OpenShift Dedicated web console, go to Observe
Alerting Alerting rules. Select the Platform and User sources in the Filter drop-down menu.
NoteThe Platform source is selected by default.
14.2.6. Removing alerting rules for user-defined projects
You can remove alerting rules for user-defined projects.
Prerequisites
- You have enabled monitoring for user-defined projects.
-
You are logged in as a cluster administrator or as a user that has the
monitoring-rules-edit
cluster role for the project where you want to create an alerting rule. -
You have installed the OpenShift CLI (
oc
).
Procedure
To remove rule
<foo>
in<namespace>
, run the following:$ oc -n <namespace> delete prometheusrule <foo>
Additional resources
- See the Alertmanager documentation
14.3. Sending notifications to external systems
In OpenShift Dedicated 4, firing alerts can be viewed in the Alerting UI. Alerts are not configured by default to be sent to any notification systems. You can configure OpenShift Dedicated to send alerts to the following receiver types:
- PagerDuty
- Webhook
- Slack
- Microsoft Teams
Routing alerts to receivers enables you to send timely notifications to the appropriate teams when failures occur. For example, critical alerts require immediate attention and are typically paged to an individual or a critical response team. Alerts that provide non-critical warning notifications might instead be routed to a ticketing system for non-immediate review.
Checking that alerting is operational by using the watchdog alert
OpenShift Dedicated monitoring includes a watchdog alert that fires continuously. Alertmanager repeatedly sends watchdog alert notifications to configured notification providers. The provider is usually configured to notify an administrator when it stops receiving the watchdog alert. This mechanism helps you quickly identify any communication issues between Alertmanager and the notification provider.
14.3.1. Configuring different alert receivers for default platform alerts and user-defined alerts
You can configure different alert receivers for default platform alerts and user-defined alerts to ensure the following results:
- All default platform alerts are sent to a receiver owned by the team in charge of these alerts.
- All user-defined alerts are sent to another receiver so that the team can focus only on platform alerts.
You can achieve this by using the openshift_io_alert_source="platform"
label that is added by the Cluster Monitoring Operator to all platform alerts:
-
Use the
openshift_io_alert_source="platform"
matcher to match default platform alerts. -
Use the
openshift_io_alert_source!="platform"
or'openshift_io_alert_source=""'
matcher to match user-defined alerts.
This configuration does not apply if you have enabled a separate instance of Alertmanager dedicated to user-defined alerts.
14.3.2. Configuring alert routing for user-defined projects
If you are a non-administrator user who has been given the alert-routing-edit
cluster role, you can create or edit alert routing for user-defined projects.
Prerequisites
- Alert routing has been enabled for user-defined projects.
-
You are logged in as a user that has the
alert-routing-edit
cluster role for the project for which you want to create alert routing. -
You have installed the OpenShift CLI (
oc
).
Procedure
-
Create a YAML file for alert routing. The example in this procedure uses a file called
example-app-alert-routing.yaml
. Add an
AlertmanagerConfig
YAML definition to the file. For example:apiVersion: monitoring.coreos.com/v1beta1 kind: AlertmanagerConfig metadata: name: example-routing namespace: ns1 spec: route: receiver: default groupBy: [job] receivers: - name: default webhookConfigs: - url: https://example.org/post
- Save the file.
Apply the resource to the cluster:
$ oc apply -f example-app-alert-routing.yaml
The configuration is automatically applied to the Alertmanager pods.
14.4. Configuring Alertmanager to send notifications
You can configure Alertmanager to send notifications by editing the alertmanager-user-workload
secret for user-defined alerts.
All features of a supported version of upstream Alertmanager are also supported in an OpenShift Alertmanager configuration. To check all the configuration options of a supported version of upstream Alertmanager, see Alertmanager configuration.
14.4.1. Configuring alert routing for user-defined projects with the Alertmanager secret
If you have enabled a separate instance of Alertmanager that is dedicated to user-defined alert routing, you can customize where and how the instance sends notifications by editing the alertmanager-user-workload
secret in the openshift-user-workload-monitoring
namespace.
All features of a supported version of upstream Alertmanager are also supported in an OpenShift Dedicated Alertmanager configuration. To check all the configuration options of a supported version of upstream Alertmanager, see Alertmanager configuration (Prometheus documentation).
Prerequisites
-
You have access to the cluster as a user with the
dedicated-admin
role. -
You have installed the OpenShift CLI (
oc
).
Procedure
Print the currently active Alertmanager configuration into the file
alertmanager.yaml
:$ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
Edit the configuration in
alertmanager.yaml
:route: receiver: Default group_by: - name: Default routes: - matchers: - "service = prometheus-example-monitor" 1 receiver: <receiver> 2 receivers: - name: Default - name: <receiver> <receiver_configuration> 3
Apply the new configuration in the file:
$ oc -n openshift-user-workload-monitoring create secret generic alertmanager-user-workload --from-file=alertmanager.yaml --dry-run=client -o=yaml | oc -n openshift-user-workload-monitoring replace secret --filename=-