×

In OpenShift Dedicated, 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 OpenShift Dedicated 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 with cluster-admin or dedicated-admin privileges, all alerts, silences, and alerting rules are accessible.

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 OpenShift Dedicated web console.

  • In the Administrator perspective, select ObserveAlerting. 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 OpenShift Dedicated and user-defined projects that you have access to in the Project: list. However, alerts, silences, and alerting rules relating to core OpenShift Dedicated projects are not displayed if you do not have cluster-admin privileges.

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 OpenShift Dedicated 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 OpenShift Dedicated projects. These projects provide core OpenShift Dedicated functionality.

    • User. User alerts relate to user-defined projects. These alerts are user-created and are customizable. User-defined workload monitoring can be enabled post-installation 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 OpenShift Dedicated 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 OpenShift Dedicated 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 OpenShift Dedicated projects. These projects provide core OpenShift Dedicated 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 post-installation 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:

  1. Open the OpenShift Dedicated web console and navigate to the ObserveAlertingAlerts page.

  2. Optional: Search for alerts by name using the Name field in the search list.

  3. Optional: Filter alerts by state, severity, and source by selecting filters in the Filter list.

  4. Optional: Sort the alerts by clicking one or more of the Name, Severity, State, and Source column headers.

  5. 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:

  1. Navigate to the ObserveAlertingSilences page.

  2. Optional: Filter the silences by name using the Search by name field.

  3. Optional: Filter silences by state by selecting filters in the Filter list. By default, Active and Pending filters are applied.

  4. Optional: Sort the silences by clicking one or more of the Name, Firing Alerts, and State column headers.

  5. 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:

  1. Navigate to the ObserveAlertingAlerting Rules page.

  2. Optional: Filter alerting rules by state, severity, and source by selecting filters in the Filter list.

  3. Optional: Sort the alerting rules by clicking one or more of the Name, Severity, Alert State, and Source column headers.

  4. 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:

  1. Navigate to the Observe<project_name>Alerts page.

  2. 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 kebab 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.

Managing silences

You can create a silence to stop receiving notifications about an alert when it is firing. It might be useful to silence an alert after being first notified, while you resolve the underlying issue.

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.

You can view, edit, and expire existing silences.

Silencing alerts

You can either silence a specific alert or silence alerts that match a specification that you define.

Prerequisites
  • You have access to the cluster as a developer or as a user with edit permissions for the project that you are viewing metrics for.

Procedure

To silence a specific alert:

  • In the Administrator perspective:

    1. Navigate to the ObserveAlertingAlerts page of the OpenShift Dedicated web console.

    2. For the alert that you want to silence, select the kebab in the right-hand column and select Silence Alert. The Silence Alert form will appear with a pre-populated specification for the chosen alert.

    3. Optional: Modify the silence.

    4. You must add a comment before creating the silence.

    5. To create the silence, select Silence.

  • In the Developer perspective:

    1. Navigate to the Observe<project_name>Alerts page in the OpenShift Dedicated web console.

    2. Expand the details for an alert by selecting > to the left of the alert name. Select the name of the alert in the expanded view to open the Alert Details page for the alert.

    3. Select Silence Alert. The Silence Alert form will appear with a prepopulated specification for the chosen alert.

    4. Optional: Modify the silence.

    5. You must add a comment before creating the silence.

    6. To create the silence, select Silence.

To silence a set of alerts by creating an alert specification in the Administrator perspective:

  1. Navigate to the ObserveAlertingSilences page in the OpenShift Dedicated web console.

  2. Select Create Silence.

  3. Set the schedule, duration, and label details for an alert in the Create Silence form. You must also add a comment for the silence.

  4. To create silences for alerts that match the label sectors that you entered in the previous step, select Silence.

Editing silences

You can edit a silence, which will expire the existing silence and create a new one with the changed configuration.

Procedure

To edit a silence in the Administrator perspective:

  1. Navigate to the ObserveAlertingSilences page.

  2. For the silence you want to modify, select the kebab in the last column and choose Edit silence.

    Alternatively, you can select ActionsEdit Silence in the Silence Details page for a silence.

  3. In the Edit Silence page, enter your changes and select Silence. This will expire the existing silence and create one with the chosen configuration.

To edit a silence in the Developer perspective:

  1. Navigate to the Observe<project_name>Alerts page.

  2. Expand the details for an alert by selecting > to the left of the alert name. Select the name of the alert in the expanded view to open the Alert Details page for the alert.

  3. Select the name of a silence in the Silenced By section in that page to navigate to the Silence Details page for the silence.

  4. Select the name of a silence to navigate to its Silence Details page.

  5. Select ActionsEdit Silence in the Silence Details page for a silence.

  6. In the Edit Silence page, enter your changes and select Silence. This will expire the existing silence and create one with the chosen configuration.

Expiring silences

You can expire a silence. Expiring a silence deactivates it forever.

Procedure

To expire a silence in the Administrator perspective:

  1. Navigate to the ObserveAlertingSilences page.

  2. For the silence you want to modify, select the kebab in the last column and choose Expire silence.

    Alternatively, you can select ActionsExpire Silence in the Silence Details page for a silence.

To expire a silence in the Developer perspective:

  1. Navigate to the Observe<project_name>Alerts page.

  2. Expand the details for an alert by selecting > to the left of the alert name. Select the name of the alert in the expanded view to open the Alert Details page for the alert.

  3. Select the name of a silence in the Silenced By section in that page to navigate to the Silence Details page for the silence.

  4. Select the name of a silence to navigate to its Silence Details page.

  5. Select ActionsExpire Silence in the Silence Details page for a silence.

Managing alerting rules for user-defined projects

OpenShift Dedicated monitoring ships with a set of default alerting rules. As a cluster administrator, you can view the default alerting rules.

In OpenShift Dedicated , you can create, 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 up.

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.

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 OpenShift Dedicated metrics. This reduces latency for alerting rules and minimizes the load on monitoring components.

    Default OpenShift Dedicated 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

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 role for the project where you want to create an alerting rule.

  • You have installed the OpenShift CLI (oc).

Procedure
  1. Create a YAML file for alerting rules. In this example, it is called example-app-alerting-rule.yaml.

  2. 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 the version metric exposed by the sample service becomes 0.

    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 from ns1 and cluster metrics, such as the CPU and memory metrics. However, the rule cannot include metrics from ns2.

    Additionally, you cannot create alerting rules for the openshift-* core OpenShift Dedicated projects. OpenShift Dedicated monitoring by default provides a set of alerting rules for these projects.

  3. 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 OpenShift Dedicated 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 openshift-user-workload-monitoring project. The procedure outlined in this section should only be used if you have read the documentation and have a comprehensive understanding of the monitoring architecture.

Prerequisites
  • You have enabled monitoring for user-defined projects.

  • You are logged in as a user that has the monitoring-rules-edit role for the project where you want to create an alerting rule.

  • You have installed the OpenShift CLI (oc).

Procedure
  1. Create a YAML file for alerting rules. In this example, it is called example-app-alerting-rule.yaml.

  2. Add an alerting rule configuration to the YAML file that includes a label with the key openshift.io/prometheus-rule-evaluation-scope and value leaf-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.

  1. Apply the configuration file to the cluster:

    $ oc apply -f example-app-alerting-rule.yaml

    It takes some time to create the alerting rule.

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 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 role for your project.

  • You have installed the OpenShift CLI (oc).

Procedure
  1. You can list alerting rules in <project>:

    $ oc -n <project> get prometheusrule
  2. 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 OpenShift Dedicated and user-defined projects together in a single view.

Prerequisites
  • You have access to the cluster as a user with the cluster-admin or dedicated-admin role.

  • You have installed the OpenShift CLI (oc).

Procedure
  1. In the Administrator perspective, navigate to ObserveAlertingAlerting Rules.

  2. 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 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
Additional resources

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 or dedicated-admin role.

Procedure
  1. 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
  2. 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.
  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=-
Additional resources