- Managing alerts
- Accessing the Alerting UI in the Administrator and Developer perspectives
- Searching and filtering alerts, silences, and alerting rules
- Getting information about alerts, silences, and alerting rules
- Managing silences
- Managing alerting rules for core platform monitoring
- Managing alerting rules for user-defined projects
- Optimizing alerting for user-defined projects
- Creating alerting rules for user-defined projects
- Reducing latency for alerting rules that do not query platform metrics
- Accessing alerting rules for user-defined projects
- Listing alerting rules for all projects in a single view
- Removing alerting rules for user-defined projects
- Sending notifications to external systems
- Applying a custom Alertmanager configuration
- Applying a custom configuration to Alertmanager for user-defined alert routing
- Next steps
Managing alerts
In OKD 4.14, the Alerting UI enables you to manage alerts, silences, and alerting rules.
Alerting rules. Alerting rules contain a set of conditions that outline a particular state within a cluster. Alerts are triggered when those conditions are true. An alerting rule can be assigned a severity that defines how the alerts are routed.
Alerts. An alert is fired when the conditions defined in an alerting rule are true. Alerts provide a notification that a set of circumstances are apparent within an OKD cluster.
Silences. A silence can be applied to an alert to prevent notifications from being sent when the conditions for an alert are true. You can mute an alert after the initial notification, while you work on resolving the underlying issue.
The alerts, silences, and alerting rules that are available in the Alerting UI relate to the projects that you have access to. For example, if you are logged in as a user with the If you are a non-administrator user, you can create and silence alerts if you are assigned the following user roles:
|
Accessing the Alerting UI in the Administrator and Developer perspectives
The Alerting UI is accessible through the Administrator perspective and the Developer perspective in the OKD web console.
In the Administrator perspective, select Observe → Alerting. The three main pages in the Alerting UI in this perspective are the Alerts, Silences, and Alerting Rules pages.
In the Developer perspective, select Observe → <project_name> → Alerts. In this perspective, alerts, silences, and alerting rules are all managed from the Alerts page. The results shown in the Alerts page are specific to the selected project.
In the Developer perspective, you can select from core OKD and user-defined projects that you have access to in the Project: list. However, alerts, silences, and alerting rules relating to core OKD projects are not displayed if you are not logged in as a cluster administrator. |
Searching and filtering alerts, silences, and alerting rules
You can filter the alerts, silences, and alerting rules that are displayed in the Alerting UI. This section provides a description of each of the available filtering options.
Understanding alert filters
In the Administrator perspective, the Alerts page in the Alerting UI provides details about alerts relating to default OKD and user-defined projects. The page includes a summary of severity, state, and source for each alert. The time at which an alert went into its current state is also shown.
You can filter by alert state, severity, and source. By default, only Platform alerts that are Firing are displayed. The following describes each alert filtering option:
Alert State filters:
Firing. The alert is firing because the alert condition is true and the optional
for
duration has passed. The alert will continue to fire as long as the condition remains true.Pending. The alert is active but is waiting for the duration that is specified in the alerting rule before it fires.
Silenced. The alert is now silenced for a defined time period. Silences temporarily mute alerts based on a set of label selectors that you define. Notifications will not be sent for alerts that match all the listed values or regular expressions.
Severity filters:
Critical. The condition that triggered the alert could have a critical impact. The alert requires immediate attention when fired and is typically paged to an individual or to a critical response team.
Warning. The alert provides a warning notification about something that might require attention to prevent a problem from occurring. Warnings are typically routed to a ticketing system for non-immediate review.
Info. The alert is provided for informational purposes only.
None. The alert has no defined severity.
You can also create custom severity definitions for alerts relating to user-defined projects.
Source filters:
Platform. Platform-level alerts relate only to default OKD projects. These projects provide core OKD functionality.
User. User alerts relate to user-defined projects. These alerts are user-created and are customizable. User-defined workload monitoring can be enabled postinstallation to provide observability into your own workloads.
Understanding silence filters
In the Administrator perspective, the Silences page in the Alerting UI provides details about silences applied to alerts in default OKD and user-defined projects. The page includes a summary of the state of each silence and the time at which a silence ends.
You can filter by silence state. By default, only Active and Pending silences are displayed. The following describes each silence state filter option:
Silence State filters:
Active. The silence is active and the alert will be muted until the silence is expired.
Pending. The silence has been scheduled and it is not yet active.
Expired. The silence has expired and notifications will be sent if the conditions for an alert are true.
Understanding alerting rule filters
In the Administrator perspective, the Alerting Rules page in the Alerting UI provides details about alerting rules relating to default OKD and user-defined projects. The page includes a summary of the state, severity, and source for each alerting rule.
You can filter alerting rules by alert state, severity, and source. By default, only Platform alerting rules are displayed. The following describes each alerting rule filtering option:
Alert State filters:
Firing. The alert is firing because the alert condition is true and the optional
for
duration has passed. The alert will continue to fire as long as the condition remains true.Pending. The alert is active but is waiting for the duration that is specified in the alerting rule before it fires.
Silenced. The alert is now silenced for a defined time period. Silences temporarily mute alerts based on a set of label selectors that you define. Notifications will not be sent for alerts that match all the listed values or regular expressions.
Not Firing. The alert is not firing.
Severity filters:
Critical. The conditions defined in the alerting rule could have a critical impact. When true, these conditions require immediate attention. Alerts relating to the rule are typically paged to an individual or to a critical response team.
Warning. The conditions defined in the alerting rule might require attention to prevent a problem from occurring. Alerts relating to the rule are typically routed to a ticketing system for non-immediate review.
Info. The alerting rule provides informational alerts only.
None. The alerting rule has no defined severity.
You can also create custom severity definitions for alerting rules relating to user-defined projects.
Source filters:
Platform. Platform-level alerting rules relate only to default OKD projects. These projects provide core OKD functionality.
User. User-defined workload alerting rules relate to user-defined projects. These alerting rules are user-created and are customizable. User-defined workload monitoring can be enabled postinstallation to provide observability into your own workloads.
Searching and filtering alerts, silences, and alerting rules in the Developer perspective
In the Developer perspective, the Alerts page in the Alerting UI provides a combined view of alerts and silences relating to the selected project. A link to the governing alerting rule is provided for each displayed alert.
In this view, you can filter by alert state and severity. By default, all alerts in the selected project are displayed if you have permission to access the project. These filters are the same as those described for the Administrator perspective.
Getting information about alerts, silences, and alerting rules
The Alerting UI provides detailed information about alerts and their governing alerting rules and silences.
Prerequisites
- You have access to the cluster as a developer or as a user with view permissions for the project that you are viewing metrics for.
Procedure
To obtain information about alerts in the Administrator perspective:
Open the OKD web console and navigate to the Observe → Alerting → Alerts page.
Optional: Search for alerts by name using the Name field in the search list.
Optional: Filter alerts by state, severity, and source by selecting filters in the Filter list.
Optional: Sort the alerts by clicking one or more of the Name, Severity, State, and Source column headers.
Select the name of an alert to navigate to its Alert Details page. The page includes a graph that illustrates alert time series data. It also provides information about the alert, including:
A description of the alert
Messages associated with the alerts
Labels attached to the alert
A link to its governing alerting rule
Silences for the alert, if any exist
To obtain information about silences in the Administrator perspective:
Navigate to the Observe → Alerting → Silences page.
Optional: Filter the silences by name using the Search by name field.
Optional: Filter silences by state by selecting filters in the Filter list. By default, Active and Pending filters are applied.
Optional: Sort the silences by clicking one or more of the Name, Firing Alerts, and State column headers.
Select the name of a silence to navigate to its Silence Details page. The page includes the following details:
Alert specification
Start time
End time
Silence state
Number and list of firing alerts
To obtain information about alerting rules in the Administrator perspective:
Navigate to the Observe → Alerting → Alerting Rules page.
Optional: Filter alerting rules by state, severity, and source by selecting filters in the Filter list.
Optional: Sort the alerting rules by clicking one or more of the Name, Severity, Alert State, and Source column headers.
Select the name of an alerting rule to navigate to its Alerting Rule Details page. The page provides the following details about the alerting rule:
Alerting rule name, severity, and description
The expression that defines the condition for firing the alert
The time for which the condition should be true for an alert to fire
A graph for each alert governed by the alerting rule, showing the value with which the alert is firing
A table of all alerts governed by the alerting rule
To obtain information about alerts, silences, and alerting rules in the Developer perspective:
Navigate to the Observe → <project_name> → Alerts page.
View details for an alert, silence, or an alerting rule:
Alert Details can be viewed by selecting > to the left of an alert name and then selecting the alert in the list.
Silence Details can be viewed by selecting 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 selecting View Alerting Rule in the menu on the right of an alert in the Alerts page.
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 OKD monitoring alerts.
Managing silences
You can create a silence for an alert in the OKD 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.
Silencing alerts
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
cluster-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.
Procedure
To silence a specific alert in the Administrator perspective:
Go to Observe → Alerting → Alerts in the OKD web console.
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.
You must add a comment before saving a silence.
To save the silence, click Silence.
To silence a specific alert in the Developer perspective:
Go to Observe → <project_name> → Alerts in the OKD web console.
If necessary, expand the details for the alert by selecting > 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.
You must add a comment before saving a silence.
To save the silence, click Silence.
To silence a set of alerts by creating a silence configuration in the Administrator perspective:
Go to Observe → Alerting → Silences in the OKD web console.
Click Create silence.
On the Create silence page, set the schedule, duration, and label details for an alert.
You must add a comment before saving a silence.
To create silences for alerts that match the labels that you entered, click Silence.
To silence a set of alerts by creating a silence configuration in the Developer perspective:
Go to Observe → <project_name> → Silences in the OKD web console.
Click Create silence.
On the Create silence page, set the duration and label details for an alert.
You must add a comment before saving a silence.
To create silences for alerts that match the labels that you entered, click Silence.
Editing silences
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
cluster-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.
Procedure
To edit a silence in the Administrator perspective:
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.
To edit a silence in the Developer perspective:
Go to Observe → <project_name> → 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.
Expiring silences
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
cluster-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.
Procedure
To expire a silence or silences in the Administrator perspective:
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.
To expire a silence in the Developer perspective:
Go to Observe → <project_name> → 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.
Managing alerting rules for core platform monitoring
OKD 4.14 monitoring ships with a large set of default alerting rules for platform metrics. As a cluster administrator, you can customize this set of rules in two ways:
Modify the settings for existing platform alerting rules by adjusting thresholds or by adding and modifying labels. For example, you can change the
severity
label for an alert fromwarning
tocritical
to help you route and triage issues flagged by an alert.Define and add new custom alerting rules by constructing a query expression based on core platform metrics in the
openshift-monitoring
namespace.
Core platform alerting rule considerations
New alerting rules must be based on the default OKD monitoring metrics.
You can only add and modify alerting rules. You cannot create new recording rules or modify existing recording rules.
If you modify existing platform alerting rules by using an
AlertRelabelConfig
object, your modifications are not reflected in the Prometheus alerts API. Therefore, any dropped alerts still appear in the OKD web console even though they are no longer forwarded to Alertmanager. Additionally, any modifications to alerts, such as a changedseverity
label, do not appear in the web console.
Tips for optimizing alerting rules for core platform monitoring
If you customize core platform alerting rules to meet your organization’s specific needs, follow these guidelines to help ensure that the customized rules are efficient and effective.
Minimize the number of new rules. Create only rules that are essential to your specific requirements. By minimizing the number of rules, you create a more manageable and focused alerting system in your monitoring environment.
Focus on symptoms rather than causes. Create rules that notify users of symptoms instead of underlying causes. This approach ensures that users are promptly notified of a relevant symptom so that they can investigate the root cause after an alert has triggered. This tactic also significantly reduces the overall number of rules you need to create.
Plan and assess your needs before implementing changes. First, decide what symptoms are important and what actions you want users to take if these symptoms occur. Then, assess existing rules and decide if you can modify any of them to meet your needs instead of creating entirely new rules for each symptom. By modifying existing rules and creating new ones judiciously, you help to streamline your alerting system.
Provide clear alert messaging. When you create alert messages, describe the symptom, possible causes, and recommended actions. Include unambiguous, concise explanations along with troubleshooting steps or links to more information. Doing so helps users quickly assess the situation and respond appropriately.
Include severity levels. Assign severity levels to your rules to indicate how a user needs to react when a symptom occurs and triggers an alert. For example, classifying an alert as Critical signals that an individual or a critical response team needs to respond immediately. By defining severity levels, you help users know how to respond to an alert and help ensure that the most urgent issues receive prompt attention.
Creating new alerting rules
As a cluster administrator, you can create new alerting rules based on platform metrics. These alerting rules trigger alerts based on the values of chosen metrics.
If you create a customized |
Prerequisites
You have access to the cluster as a user that has the
cluster-admin
cluster role.You have installed the OpenShift CLI (
oc
).
Procedure
Create a new YAML configuration file named
example-alerting-rule.yaml
in theopenshift-monitoring
namespace.Add an
AlertingRule
resource to the YAML file. The following example creates a new alerting rule namedexample
, similar to the defaultwatchdog
alert:apiVersion: monitoring.openshift.io/v1
kind: AlertingRule
metadata:
name: example
namespace: openshift-monitoring
spec:
groups:
- name: example-rules
rules:
- alert: ExampleAlert (1)
expr: vector(1) (2)
1 The name of the alerting rule you want to create. 2 The PromQL query expression that defines the new rule. Apply the configuration file to the cluster:
$ oc apply -f example-alerting-rule.yaml
Modifying core platform alerting rules
As a cluster administrator, you can modify core platform alerts before Alertmanager routes them to a receiver. For example, you can change the severity label of an alert, add a custom label, or exclude an alert from being sent to Alertmanager.
Prerequisites
You have access to the cluster as a user with the
cluster-admin
cluster role.You have installed the OpenShift CLI (
oc
).
Procedure
Create a new YAML configuration file named
example-modified-alerting-rule.yaml
in theopenshift-monitoring
namespace.Add an
AlertRelabelConfig
resource to the YAML file. The following example modifies theseverity
setting tocritical
for the default platformwatchdog
alerting rule:apiVersion: monitoring.openshift.io/v1
kind: AlertRelabelConfig
metadata:
name: watchdog
namespace: openshift-monitoring
spec:
configs:
- sourceLabels: [alertname,severity] (1)
regex: "Watchdog;none" (2)
targetLabel: severity (3)
replacement: critical (4)
action: Replace (5)
1 The source labels for the values you want to modify. 2 The regular expression against which the value of sourceLabels
is matched.3 The target label of the value you want to modify. 4 The new value to replace the target label. 5 The relabel action that replaces the old value based on regex matching. The default action is Replace
. Other possible values areKeep
,Drop
,HashMod
,LabelMap
,LabelDrop
, andLabelKeep
.Apply the configuration file to the cluster:
$ oc apply -f example-modified-alerting-rule.yaml
Additional resources
See Monitoring overview for details about OKD 4.14 monitoring architecture.
See the Alertmanager documentation for information about alerting rules.
See the Prometheus relabeling documentation for information about how relabeling works.
See the Prometheus alerting documentation for further guidelines on optimizing alerts.
Managing alerting rules for user-defined projects
OKD monitoring ships with a set of default alerting rules. As a cluster administrator, you can view the default alerting rules.
In OKD 4.14, you can create, view, edit, and remove alerting rules in user-defined projects.
Alerting rule considerations
The default alerting rules are used specifically for the OKD 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.
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.
Optimize alert routing. Deploy an alerting rule directly on the Prometheus instance in the
openshift-user-workload-monitoring
project if the rule does not query default OKD metrics. This reduces latency for alerting rules and minimizes the load on monitoring components.Default OKD metrics for user-defined projects provide information about CPU and memory usage, bandwidth statistics, and packet rate information. Those metrics cannot be included in an alerting rule if you route the rule directly to the Prometheus instance in the
openshift-user-workload-monitoring
project. Alerting rule optimization should be used only if you have read the documentation and have a comprehensive understanding of the monitoring architecture.
Additional resources
See the Prometheus alerting documentation for further guidelines on optimizing alerts
See Monitoring overview for details about OKD 4.14 monitoring architecture
Creating alerting rules for user-defined projects
You can create alerting rules for user-defined projects. Those alerting rules will fire alerts based on the values of chosen metrics.
Prerequisites
You have enabled monitoring for user-defined projects.
You are logged in 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. For example:
When you create an alerting rule, a project label is enforced on it if a rule with the same name exists in another project.
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: example-alert
namespace: ns1
spec:
groups:
- name: example
rules:
- alert: VersionAlert
expr: version{job="prometheus-example-app"} == 0
This configuration creates an alerting rule named
example-alert
. The alerting rule fires an alert when theversion
metric exposed by the sample service becomes0
.A user-defined alerting rule can include metrics for its own project and cluster metrics. You cannot include metrics for another user-defined project.
For example, an alerting rule for the user-defined project
ns1
can have metrics fromns1
and cluster metrics, such as the CPU and memory metrics. However, the rule cannot include metrics fromns2
.Additionally, you cannot create alerting rules for the
openshift-*
core OKD projects. OKD monitoring by default provides a set of alerting rules for these projects.Apply the configuration file to the cluster:
$ oc apply -f example-app-alerting-rule.yaml
It takes some time to create the alerting rule.
Reducing latency for alerting rules that do not query platform metrics
If an alerting rule for a user-defined project does not query default cluster metrics, you can deploy the rule directly on the Prometheus instance in the openshift-user-workload-monitoring
project. This reduces latency for alerting rules by bypassing Thanos Ruler when it is not required. This also helps to minimize the overall load on monitoring components.
Default OKD metrics for user-defined projects provide information about CPU and memory usage, bandwidth statistics, and packet rate information. Those metrics cannot be included in an alerting rule if you deploy the rule directly to the Prometheus instance in the |
Prerequisites
You have enabled monitoring for user-defined projects.
You are logged in 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 that includes a label with the key
openshift.io/prometheus-rule-evaluation-scope
and valueleaf-prometheus
. For example:apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: example-alert
namespace: ns1
labels:
openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus
spec:
groups:
- name: example
rules:
- alert: VersionAlert
expr: version{job="prometheus-example-app"} == 0
If that label is present, the alerting rule is deployed on the Prometheus instance in the
openshift-user-workload-monitoring
project. If the label is not present, the alerting rule is deployed to Thanos Ruler.Apply the configuration file to the cluster:
$ oc apply -f example-app-alerting-rule.yaml
It takes some time to create the alerting rule.
Additional resources
- See Monitoring overview for details about OKD 4.14 monitoring architecture.
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
Listing alerting rules for all projects in a single view
As a cluster administrator, you can list alerting rules for core OKD and user-defined projects together in a single view.
Prerequisites
You have access to the cluster as a user with the
cluster-admin
role.You have installed the OpenShift CLI (
oc
).
Procedure
In the Administrator perspective, navigate to Observe → Alerting → Alerting rules.
Select the Platform and User sources in the Filter drop-down menu.
The Platform source is selected by default.
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 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
Sending notifications to external systems
In OKD 4.14, 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 OKD to send alerts to the following receiver types:
PagerDuty
Webhook
Email
Slack
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
OKD 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.
Configuring alert receivers
You can configure alert receivers to ensure that you learn about important issues with your cluster.
Prerequisites
- You have access to the cluster as a user with the
cluster-admin
cluster role.
Procedure
In the Administrator perspective, navigate to Administration → Cluster Settings → Configuration → Alertmanager.
Alternatively, you can navigate to the same page through the notification drawer. Select the bell icon at the top right of the OKD web console and choose Configure in the AlertmanagerReceiverNotConfigured alert.
Select Create Receiver in the Receivers section of the page.
In the Create Receiver form, add a Receiver Name and choose a Receiver Type from the list.
Edit the receiver configuration:
For PagerDuty receivers:
Choose an integration type and add a PagerDuty integration key.
Add the URL of your PagerDuty installation.
Select Show advanced configuration if you want to edit the client and incident details or the severity specification.
For webhook receivers:
Add the endpoint to send HTTP POST requests to.
Select Show advanced configuration if you want to edit the default option to send resolved alerts to the receiver.
For email receivers:
Add the email address to send notifications to.
Add SMTP configuration details, including the address to send notifications from, the smarthost and port number used for sending emails, the hostname of the SMTP server, and authentication details.
Choose whether TLS is required.
Select Show advanced configuration if you want to edit the default option not to send resolved alerts to the receiver or edit the body of email notifications configuration.
For Slack receivers:
Add the URL of the Slack webhook.
Add the Slack channel or user name to send notifications to.
Select Show advanced configuration if you want to edit the default option not to send resolved alerts to the receiver or edit the icon and username configuration. You can also choose whether to find and link channel names and usernames.
By default, firing alerts with labels that match all of the selectors will be sent to the receiver. If you want label values for firing alerts to be matched exactly before they are sent to the receiver:
Add routing label names and values in the Routing Labels section of the form.
Select Regular Expression if want to use a regular expression.
Select Add Label to add further routing labels.
Select Create to create the receiver.
Creating 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
A cluster administrator has enabled monitoring for user-defined projects.
A cluster administrator has enabled alert routing 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
For user-defined alerting rules, user-defined routing is scoped to the namespace in which the resource is defined. For example, a routing configuration defined in the
AlertmanagerConfig
object for namespacens1
only applies toPrometheusRules
resources in the same namespace.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.
Applying a custom Alertmanager configuration
You can overwrite the default Alertmanager configuration by editing the alertmanager-main
secret in the openshift-monitoring
namespace for the platform instance of Alertmanager.
Prerequisites
- You have access to the cluster as a user with the
cluster-admin
cluster role.
Procedure
To change the Alertmanager configuration from the CLI:
Print the currently active Alertmanager configuration into file
alertmanager.yaml
:$ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
Edit the configuration in
alertmanager.yaml
:global:
resolve_timeout: 5m
route:
group_wait: 30s (1)
group_interval: 5m (2)
repeat_interval: 12h (3)
receiver: default
routes:
- matchers:
- "alertname=Watchdog"
repeat_interval: 2m
receiver: watchdog
- matchers:
- "service=<your_service>" (4)
routes:
- matchers:
- <your_matching_rules> (5)
receiver: <receiver> (6)
receivers:
- name: default
- name: watchdog
- name: <receiver>
# <receiver_configuration>
1 The group_wait
value specifies how long Alertmanager waits before sending an initial notification for a group of alerts. This value controls how long Alertmanager waits while collecting initial alerts for the same group before sending a notification.2 The group_interval
value specifies 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 The repeat_interval
value specifies 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 therepeat_interval
value to less than thegroup_interval
value. However, the repeated notification can still be delayed, for example, when certain Alertmanager pods are restarted or rescheduled.4 The service
value specifies the service that fires the alerts.5 The <your_matching_rules>
value specifies the target alerts.6 The receiver
value specifies the receiver to use for the alert.Use the
matchers
key name to indicate the matchers that an alert has to fulfill to match the node. Do not use thematch
ormatch_re
key names, which are both deprecated and planned for removal in a future release.In addition, if you define inhibition rules, use the
target_matchers
key name to indicate the target matchers and thesource_matchers
key name to indicate the source matchers. Do not use thetarget_match
,target_match_re
,source_match
, orsource_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:
global:
resolve_timeout: 5m
route:
group_wait: 30s
group_interval: 5m
repeat_interval: 12h
receiver: default
routes:
- matchers:
- "alertname=Watchdog"
repeat_interval: 2m
receiver: watchdog
- matchers:
- "service=example-app"
routes:
- matchers:
- "severity=critical"
receiver: team-frontend-page*
receivers:
- name: default
- name: watchdog
- name: team-frontend-page
pagerduty_configs:
- service_key: "_your-key_"
With this configuration, alerts of
critical
severity that are fired by theexample-app
service are sent using theteam-frontend-page
receiver. Typically these types of alerts would be paged to an individual or a critical response team.Apply the new configuration in the file:
$ oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run=client -o=yaml | oc -n openshift-monitoring replace secret --filename=-
To change the Alertmanager configuration from the OKD web console:
Navigate to the Administration → Cluster Settings → Configuration → Alertmanager → YAML page of the web console.
Modify the YAML configuration file.
Select Save.
Applying a custom configuration to Alertmanager for user-defined alert routing
If you have enabled a separate instance of Alertmanager dedicated to user-defined alert routing, you can overwrite the configuration for this instance of Alertmanager by editing the alertmanager-user-workload
secret in the openshift-user-workload-monitoring
namespace.
Prerequisites
You have access to the cluster as a user with the
cluster-admin
cluster 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>
1 Specifies which alerts match the route. This example shows all alerts that have the service=”prometheus-example-monitor”
label.2 Specifies the receiver to use for the alerts group. 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=-
Additional resources
See the PagerDuty official site for more information on PagerDuty.
See the PagerDuty Prometheus Integration Guide to learn how to retrieve the
service_key
.See Alertmanager configuration for configuring alerting through different alert receivers.
See Enabling alert routing for user-defined projects to learn how to enable a dedicated instance of Alertmanager for user-defined alert routing.