×

在 OpenShift Container Platform 4.17 中,告警 UI 允许您管理告警、静默和告警规则。

  • 告警规则。告警规则包含一组条件,这些条件概述了集群中的特定状态。当这些条件为真时,将触发告警。可以为告警规则分配一个严重性级别,该级别定义了告警的路由方式。

  • 告警。当告警规则中定义的条件为真时,将触发告警。告警提供通知,表明 OpenShift Container Platform 集群中出现了一组情况。

  • 静默。可以将静默应用于告警,以防止在告警条件为真时发送通知。在您处理问题时,可以在初始通知后静默告警。

告警 UI 中可用的告警、静默和告警规则与您有权访问的项目相关。例如,如果您以具有 `cluster-admin` 角色的用户身份登录,则可以访问所有告警、静默和告警规则。

在管理员和开发者视角下访问告警UI

告警UI可以通过OpenShift Container Platform Web控制台的**管理员**视角和**开发者**视角访问。

  • 在**管理员**视角中,转到**监控** → **告警**。此视角下告警UI中的三个主要页面是**告警**、**静默**和**告警规则**页面。

  • 在**开发者**视角中,转到**监控** → **<项目名称>** → **告警**。在此视角下,告警、静默和告警规则都可在**告警**页面进行管理。**告警**页面中显示的结果特定于所选项目。

在**开发者**视角中,您可以从**项目:<项目名称>**列表中选择您有权访问的核心OpenShift Container Platform项目和用户定义的项目。但是,如果您未以集群管理员身份登录,则不会显示与核心OpenShift Container Platform项目相关的告警、静默和告警规则。

搜索和过滤告警、静默和告警规则

您可以过滤告警UI中显示的告警、静默和告警规则。本节提供了每个可用过滤选项的描述。

了解告警过滤器

在**管理员**视角中,告警UI的**告警**页面提供有关与默认OpenShift Container Platform项目和用户定义的项目相关的告警的详细信息。页面包含每个告警的严重性、状态和来源的摘要。还显示了告警进入当前状态的时间。

您可以按告警状态、严重性和来源进行过滤。默认情况下,只显示处于**触发中**状态的**平台**告警。以下是每个告警过滤选项的说明

  • **状态**过滤器

    • **触发中**。由于告警条件为真且可选的for持续时间已过去,因此告警正在触发。只要条件仍然为真,告警就会继续触发。

    • **待处理**。告警处于活动状态,但正在等待告警规则中指定的持续时间后才触发。

    • **静默**。告警现在已静默一段时间。静默根据您定义的一组标签选择器临时静默告警。不会向与所有列出的值或正则表达式匹配的告警发送通知。

  • **严重性**过滤器

    • **严重**。触发告警的条件可能会造成严重影响。触发时,告警需要立即关注,通常会分页到个人或关键响应团队。

    • **警告**。告警提供有关可能需要关注以防止问题发生的警告通知。警告通常会路由到票务系统以进行非立即审查。

    • **信息**。告警仅用于信息目的。

    • **无**。告警没有定义的严重性。

    • 您还可以为与用户定义的项目相关的告警创建自定义严重性定义。

  • **来源**过滤器

    • **平台**。平台级告警仅与默认OpenShift Container Platform项目相关。这些项目提供核心OpenShift Container Platform功能。

    • **用户**。用户告警与用户定义的项目相关。这些告警是用户创建的,并且是可自定义的。可以在安装后启用用户定义的工作负载监控,以便对您自己的工作负载进行可观察性。

了解静默过滤器

在**管理员**视角中,告警UI的**静默**页面提供有关应用于默认OpenShift Container Platform项目和用户定义的项目中的告警的静默的详细信息。页面包含每个静默的状态和静默结束时间的摘要。

您可以按静默状态进行过滤。默认情况下,只显示**活动**和**待处理**的静默。以下是每个静默状态过滤选项的说明

  • **状态**过滤器

    • **活动**。静默处于活动状态,并且告警将被静默,直到静默过期。

    • **待处理**。静默已计划,但尚未激活。

    • **已过期**。静默已过期,如果告警的条件为真,则将发送通知。

了解告警规则过滤器

在**管理员**视角中,告警UI的**告警规则**页面提供有关与默认OpenShift Container Platform项目和用户定义的项目相关的告警规则的详细信息。页面包含每个告警规则的状态、严重性和来源的摘要。

您可以按告警状态、严重性和来源过滤告警规则。默认情况下,只显示**平台**告警规则。以下是每个告警规则过滤选项的说明

  • **告警状态**过滤器

    • **触发中**。由于告警条件为真且可选的for持续时间已过去,因此告警正在触发。只要条件仍然为真,告警就会继续触发。

    • **待处理**。告警处于活动状态,但正在等待告警规则中指定的持续时间后才触发。

    • **静默**。告警现在已静默一段时间。静默根据您定义的一组标签选择器临时静默告警。不会向与所有列出的值或正则表达式匹配的告警发送通知。

    • **未触发**。告警未触发。

  • **严重性**过滤器

    • **严重**。告警规则中定义的条件可能会造成严重影响。为真时,这些条件需要立即关注。与该规则相关的告警通常会分页到个人或关键响应团队。

    • **警告**。告警规则中定义的条件可能需要关注以防止问题发生。与该规则相关的告警通常会路由到票务系统以进行非立即审查。

    • **信息**。告警规则仅提供信息性告警。

    • **无**。告警规则没有定义的严重性。

    • 您还可以为与用户定义的项目相关的告警规则创建自定义严重性定义。

  • **来源**过滤器

    • **平台**。平台级告警规则仅与默认OpenShift Container Platform项目相关。这些项目提供核心OpenShift Container Platform功能。

    • **用户**。用户定义的工作负载告警规则与用户定义的项目相关。这些告警规则是用户创建的,并且是可自定义的。可以在安装后启用用户定义的工作负载监控,以便对您自己的工作负载进行可观察性。

在开发者视角中搜索和过滤告警、静默和告警规则

在**开发者**视角中,告警UI的**告警**页面提供与所选项目相关的告警和静默的组合视图。为每个显示的告警提供了指向管理告警规则的链接。

在此视图中,您可以按告警状态和严重性进行过滤。如果您有权访问该项目,则默认情况下将显示所选项目中的所有告警。这些过滤器与**管理员**视角中描述的过滤器相同。

获取有关告警、静默和告警规则的信息

告警UI提供有关告警及其管理告警规则和静默的详细信息。

先决条件
  • 您可以作为开发者或具有您正在查看其告警的项目的查看权限的用户访问集群。

步骤

要在管理员视角中获取有关告警的信息:

  1. 打开 OpenShift Container Platform Web 控制台,然后转到**监控** → **告警** → **告警**页面。

  2. 可选:使用搜索列表中的**名称**字段按名称搜索告警。

  3. 可选:在**筛选器**列表中选择筛选器,按状态、严重性和来源筛选告警。

  4. 可选:单击**名称**、**严重性**、**状态**和**来源**列标题中的一列或多列对告警进行排序。

  5. 单击告警的名称以查看其**告警详情**页面。此页面包含一个图表,用于说明告警时间序列数据。它还提供以下有关告警的信息:

    • 告警说明

    • 与告警关联的消息

    • 附加到告警的标签

    • 指向其管理告警规则的链接

    • 告警的静默,如果存在的话

要在管理员视角中获取有关静默的信息::

  1. 转到**监控** → **告警** → **静默**页面。

  2. 可选:使用**按名称搜索**字段按名称筛选静默。

  3. 可选:在**筛选器**列表中选择筛选器,按状态筛选静默。默认情况下,将应用**活动**和**待定**筛选器。

  4. 可选:单击**名称**、**触发告警**、**状态**和**创建者**列标题中的一列或多列对静默进行排序。

  5. 选择静默的名称以查看其**静默详情**页面。此页面包含以下详细信息:

    • 告警规范

    • 开始时间

    • 结束时间

    • 静默状态

    • 触发告警的数量和列表

要在管理员视角中获取有关告警规则的信息::

  1. 转到**监控** → **告警** → **告警规则**页面。

  2. 可选:在**筛选器**列表中选择筛选器,按状态、严重性和来源筛选告警规则。

  3. 可选:单击**名称**、**严重性**、**告警状态**和**来源**列标题中的一列或多列对告警规则进行排序。

  4. 选择告警规则的名称以查看其**告警规则详情**页面。此页面提供以下有关告警规则的详细信息:

    • 告警规则名称、严重性和说明。

    • 定义触发告警条件的表达式。

    • 应满足条件的时间,以便触发告警。

    • 受告警规则管理的每个告警的图表,显示触发告警的值。

    • 受告警规则管理的所有告警的表格。

要在开发者视角中获取有关告警、静默和告警规则的信息::

  1. 转到**监控** → **<项目名称>** → **告警**页面。

  2. 查看告警、静默或告警规则的详细信息

    • 可以通过单击告警名称旁边的大于符号 (**>**) ,然后从列表中选择告警来查看**告警详情**。

    • 可以通过单击**告警详情**页面**被静默**部分中的静默来查看**静默详情**。**静默详情**页面包含以下信息:

      • 告警规范

      • 开始时间

      • 结束时间

      • 静默状态

      • 触发告警的数量和列表

    • 可以通过单击**告警**页面中告警旁边的kebab菜单,然后单击**查看告警规则**来查看**告警规则详情**。

在**开发者**视角中,只显示与所选项目相关的告警、静默和告警规则。

其他资源

管理静默

您可以在 OpenShift Container Platform Web 控制台的**管理员**和**开发者**视角中为告警创建静默。创建静默后,当告警触发时,您将不会收到有关告警的通知。

在您收到初始告警通知并且您不希望在解决导致告警触发的根本问题期间收到进一步通知的情况下,创建静默非常有用。

创建静默时,必须指定它是立即生效还是稍后生效。还必须设置静默过期后的持续时间。

创建静默后,您可以查看、编辑和使其过期。

创建静默后,它们会在 Alertmanager Pod 之间复制。但是,如果您没有为 Alertmanager 配置持久性存储,则静默可能会丢失。例如,如果所有 Alertmanager Pod 同时重启,就会发生这种情况。

其他资源

静默告警

您可以静默特定告警或静默与您定义的规范匹配的告警。

先决条件
  • 如果您是集群管理员,则您可以作为具有`cluster-admin`角色的用户访问集群。

  • 如果您是非管理员用户,则您可以作为具有以下用户角色的用户访问集群:

    • `cluster-monitoring-view`集群角色,允许您访问 Alertmanager。

    • `monitoring-alertmanager-edit`角色,允许您在 Web 控制台的**管理员**视角中创建和静默告警。

    • `monitoring-rules-edit`集群角色,允许您在 Web 控制台的**开发者**视角中创建和静默告警。

步骤

要在**管理员**视角中静默特定告警:

  1. 在 OpenShift Container Platform Web 控制台中,转到**监控** → **告警** → **告警**。

  2. 对于要静默的告警,单击kebab并选择**静默告警**以打开具有所选告警的默认配置的**静默告警**页面。

  3. 可选:更改静默的默认配置详细信息。

    保存静默前必须添加注释。

  4. 要保存静默,请单击**静默**。

要在**开发者**视角中静默特定告警:

  1. 在 OpenShift Container Platform Web 控制台中,转到**监控** → **<项目名称>** → **告警**。

  2. 如有必要,通过选择告警名称旁边的大于符号 (**>**) 来展开告警的详细信息。

  3. 单击展开视图中的告警消息以打开该告警的**告警详情**页面。

  4. 单击**静默告警**以打开具有告警默认配置的**静默告警**页面。

  5. 可选:更改静默的默认配置详细信息。

    保存静默前必须添加注释。

  6. 要保存静默,请单击**静默**。

要在**管理员**视角中通过创建静默配置来静默一组告警:

  1. 在 OpenShift Container Platform Web 控制台中,转到**监控** → **告警** → **静默**。

  2. 点击**创建静默**。

  3. 在**创建静默**页面上,设置告警的计划、持续时间和标签详细信息。

    保存静默前必须添加注释。

  4. 要为与您输入的标签匹配的告警创建静默,请点击**静默**。

要通过在**开发者**视角创建静默配置来静默一组告警

  1. 在 OpenShift Container Platform Web 控制台中,转到**监控** → **** → **静默**。

  2. 点击**创建静默**。

  3. 在**创建静默**页面上,设置告警的持续时间和标签详细信息。

    保存静默前必须添加注释。

  4. 要为与您输入的标签匹配的告警创建静默,请点击**静默**。

编辑静默

您可以编辑静默,这将使现有静默失效并创建一个具有更改配置的新静默。

先决条件
  • 如果您是集群管理员,则您可以作为具有`cluster-admin`角色的用户访问集群。

  • 如果您是非管理员用户,则您可以作为具有以下用户角色的用户访问集群:

    • `cluster-monitoring-view`集群角色,允许您访问 Alertmanager。

    • `monitoring-alertmanager-edit`角色,允许您在 Web 控制台的**管理员**视角中创建和静默告警。

    • `monitoring-rules-edit`集群角色,允许您在 Web 控制台的**开发者**视角中创建和静默告警。

步骤

要在**管理员**视角编辑静默

  1. 转到**监控** → **告警** → **静默**。

  2. 对于要修改的静默,点击kebab并选择**编辑静默**。

    或者,您可以在静默的**静默详情**页面点击**操作**并选择**编辑静默**。

  3. 在**编辑静默**页面上,进行更改并点击**静默**。这样做会使现有静默失效,并创建一个具有更新配置的新静默。

要在**开发者**视角编辑静默

  1. 转到**监控** → **** → **静默**。

  2. 对于要修改的静默,点击kebab并选择**编辑静默**。

    或者,您可以在静默的**静默详情**页面点击**操作**并选择**编辑静默**。

  3. 在**编辑静默**页面上,进行更改并点击**静默**。这样做会使现有静默失效,并创建一个具有更新配置的新静默。

使静默失效

您可以使单个静默或多个静默失效。使静默失效会永久停用它。

您无法删除已失效的静默告警。超过 120 小时的失效静默将被垃圾回收。

先决条件
  • 如果您是集群管理员,则您可以作为具有`cluster-admin`角色的用户访问集群。

  • 如果您是非管理员用户,则您可以作为具有以下用户角色的用户访问集群:

    • `cluster-monitoring-view`集群角色,允许您访问 Alertmanager。

    • `monitoring-alertmanager-edit`角色,允许您在 Web 控制台的**管理员**视角中创建和静默告警。

    • `monitoring-rules-edit`集群角色,允许您在 Web 控制台的**开发者**视角中创建和静默告警。

步骤

要在**管理员**视角使静默失效

  1. 转到**监控** → **告警** → **静默**。

  2. 对于要使失效的静默,选择相应行中的复选框。

  3. 点击**使 1 个静默失效**以使单个选定的静默失效,或点击**使 个静默失效**以使多个选定的静默失效,其中 是您选择的静默数量。

    或者,要使单个静默失效,您可以在静默的**静默详情**页面点击**操作**并选择**使静默失效**。

要在**开发者**视角使静默失效

  1. 转到**监控** → **** → **静默**。

  2. 对于要使失效的静默,选择相应行中的复选框。

  3. 点击**使 1 个静默失效**以使单个选定的静默失效,或点击**使 个静默失效**以使多个选定的静默失效,其中 是您选择的静默数量。

    或者,要使单个静默失效,您可以在静默的**静默详情**页面点击**操作**并选择**使静默失效**。

管理核心平台监控的告警规则

OpenShift Container Platform 4.17 监控附带大量针对平台指标的默认告警规则。作为集群管理员,您可以通过两种方式自定义此规则集

  • 通过调整阈值或添加和修改标签来修改现有平台告警规则的设置。例如,您可以将告警的severity标签从warning更改为critical,以帮助您路由和分类告警标记的问题。

  • 通过基于openshift-monitoring命名空间中的核心平台指标构建查询表达式来定义和添加新的自定义告警规则。

核心平台告警规则注意事项
  • 新的告警规则必须基于默认的 OpenShift Container Platform 监控指标。

  • 您必须在openshift-monitoring命名空间中创建AlertingRuleAlertRelabelConfig对象。

  • 您只能添加和修改告警规则。您不能创建新的记录规则或修改现有的记录规则。

  • 如果您使用AlertRelabelConfig对象修改现有的平台告警规则,则您的修改不会反映在 Prometheus 告警 API 中。因此,即使不再将任何丢弃的告警转发到 Alertmanager,它们仍然会显示在 OpenShift Container Platform Web 控制台中。此外,对告警的任何修改(例如更改的severity标签)都不会显示在 Web 控制台中。

优化核心平台监控告警规则的技巧

如果您自定义核心平台告警规则以满足您组织的特定需求,请遵循以下准则,以帮助确保自定义规则高效有效。

  • **最大限度地减少新规则的数量**。仅创建对您的特定需求至关重要的规则。通过最大限度地减少规则数量,您可以在监控环境中创建一个更易于管理和更集中的告警系统。

  • **关注症状而不是原因**。创建通知用户症状而不是根本原因的规则。这种方法确保用户能够及时收到相关症状的通知,以便他们可以在告警触发后调查根本原因。此策略还可以显著减少您需要创建的规则总数。

  • **在实施更改之前规划和评估您的需求**。首先,确定哪些症状很重要,以及如果出现这些症状,您希望用户采取哪些措施。然后,评估现有规则,并确定是否可以修改任何规则以满足您的需求,而不是为每个症状创建全新的规则。通过谨慎地修改现有规则和创建新规则,您可以帮助简化您的告警系统。

  • **提供清晰的告警消息**。创建告警消息时,请描述症状、可能原因和建议的操作。包含明确、简洁的解释以及故障排除步骤或指向更多信息的链接。这样做可以帮助用户快速评估情况并做出适当的响应。

  • **包含严重性级别**。为您的规则分配严重性级别,以指示用户在出现症状并触发告警时需要如何反应。例如,将告警分类为**严重**表示个人或关键响应团队需要立即做出响应。通过定义严重性级别,您可以帮助用户了解如何响应告警,并帮助确保最紧急的问题得到及时的关注。

创建新的告警规则

作为集群管理员,您可以基于平台指标创建新的告警规则。这些告警规则根据所选指标的值触发告警。

  • 如果您基于现有的平台告警规则创建自定义的AlertingRule资源,请使原始告警静默以避免接收冲突的告警。

  • 为了帮助用户了解告警的影响和原因,请确保您的告警规则包含告警消息和严重性值。

先决条件
  • 您可以作为具有cluster-admin集群角色的用户访问集群。

  • 您已安装 OpenShift CLI(oc)。

步骤
  1. 创建一个名为example-alerting-rule.yaml的新 YAML 配置文件。

  2. 向 YAML 文件添加AlertingRule资源。以下示例创建一个名为example的新告警规则,类似于默认的Watchdog告警

    apiVersion: monitoring.openshift.io/v1
    kind: AlertingRule
    metadata:
      name: example
      namespace: openshift-monitoring (1)
    spec:
      groups:
      - name: example-rules
        rules:
        - alert: ExampleAlert (2)
          for: 1m (3)
          expr: vector(1) (4)
          labels:
            severity: warning (5)
          annotations:
            message: This is an example alert. (6)
    1 确保命名空间为openshift-monitoring
    2 您要创建的告警规则的名称。
    3 条件在触发告警之前应为真的持续时间。
    4 定义新规则的 PromQL 查询表达式。
    5 告警规则分配给告警的严重性。
    6 与告警关联的消息。

    您必须在openshift-monitoring命名空间中创建AlertingRule对象。否则,告警规则将不被接受。

  3. 将配置文件应用于集群

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

修改核心平台告警规则

作为集群管理员,您可以在 Alertmanager 将核心平台告警路由到接收器之前修改它们。例如,您可以更改告警的严重性标签,添加自定义标签,或排除将告警发送到 Alertmanager。

先决条件
  • 您可以作为具有cluster-admin集群角色的用户访问集群。

  • 您已安装 OpenShift CLI(oc)。

步骤
  1. 创建一个名为example-modified-alerting-rule.yaml的新 YAML 配置文件。

  2. 在 YAML 文件中添加一个 `AlertRelabelConfig` 资源。以下示例将默认平台 `watchdog` 报警规则的 `severity` 设置修改为 `critical`

    apiVersion: monitoring.openshift.io/v1
    kind: AlertRelabelConfig
    metadata:
      name: watchdog
      namespace: openshift-monitoring (1)
    spec:
      configs:
      - sourceLabels: [alertname,severity] (2)
        regex: "Watchdog;none" (3)
        targetLabel: severity (4)
        replacement: critical (5)
        action: Replace (6)
    1 确保命名空间为openshift-monitoring
    2 您想要修改的值的源标签。
    3 与 `sourceLabels` 值匹配的正则表达式。
    4 您想要修改的值的目标标签。
    5 用于替换目标标签的新值。
    6 基于正则表达式匹配替换旧值的重命名操作。默认操作为 `Replace`。其他可能的值为 `Keep`、`Drop`、`HashMod`、`LabelMap`、`LabelDrop` 和 `LabelKeep`。

    必须在 `openshift-monitoring` 命名空间中创建 `AlertRelabelConfig` 对象。否则,报警标签将不会更改。

  3. 将配置文件应用于集群

    $ oc apply -f example-modified-alerting-rule.yaml
其他资源

管理用户定义项目的报警规则

OpenShift Container Platform 监控自带一组默认报警规则。作为集群管理员,您可以查看默认报警规则。

在 OpenShift Container Platform 4.17 中,您可以在用户定义的项目中创建、查看、编辑和删除报警规则。

报警规则注意事项
  • 默认报警规则专门用于 OpenShift Container Platform 集群。

  • 一些报警规则有意使用相同的名称。它们使用不同的阈值、不同的严重性或两者都不同来发送有关同一事件的警报。

  • 抑制规则可以防止在同时触发更高严重性警报时触发较低严重性警报的通知。

优化用户定义项目的报警

您可以通过在创建报警规则时考虑以下建议来优化您自己项目的报警。

  • **尽量减少为您的项目创建的报警规则数量**。创建可以通知您影响您的状况的报警规则。如果您为不影响您的状况生成许多警报,则很难注意到相关的警报。

  • **为症状而不是原因创建报警规则**。创建可以通知您状况的报警规则,而不管根本原因是什么。然后可以调查原因。如果每个规则只与特定原因相关,则您将需要更多报警规则。然后,某些原因很可能会被忽略。

  • **在编写报警规则之前进行规划**。确定哪些症状对您很重要,以及如果出现这些症状,您想要采取什么措施。然后为每个症状构建一个报警规则。

  • **提供清晰的警报消息**。在警报消息中说明症状和建议的操作。

  • **在您的报警规则中包含严重级别**。警报的严重性取决于如果出现报告的症状,您需要如何反应。例如,如果症状需要个人或关键响应团队立即关注,则应触发严重警报。

其他资源

关于为用户定义的项目创建报警规则

如果您为用户定义的项目创建报警规则,请在定义新规则时考虑以下关键行为和重要限制

  • 用户定义的报警规则除了来自核心平台监控的默认指标外,还可以包含其自身项目公开的指标。您不能包含来自另一个用户定义项目的指标。

    例如,`ns1` 用户定义项目的报警规则可以使用 `ns1` 项目公开的指标以及核心平台指标(例如 CPU 和内存指标)。但是,该规则不能包含来自不同的 `ns2` 用户定义项目的指标。

  • 为了减少延迟并最大限度地减少核心平台监控组件的负载,您可以向规则添加 `openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus` 标签。此标签强制仅部署在 `openshift-user-workload-monitoring` 项目中的 Prometheus 实例来评估报警规则,并阻止 Thanos Ruler 实例这样做。

    如果报警规则具有此标签,则您的报警规则只能使用用户定义的项目公开的那些指标。您根据默认平台指标创建的报警规则可能不会触发警报。

为用户定义的项目创建报警规则

您可以为用户定义的项目创建报警规则。这些报警规则将根据所选指标的值触发警报。

  • 创建报警规则时,即使另一个项目中存在具有相同名称的规则,也会在其上强制执行项目标签。

  • 为了帮助用户了解告警的影响和原因,请确保您的告警规则包含告警消息和严重性值。

先决条件
  • 您已为用户定义的项目启用监控。

  • 您已登录为具有您想要创建报警规则的项目的 `monitoring-rules-edit` 集群角色的用户。

  • 您已安装 OpenShift CLI(oc)。

步骤
  1. 为报警规则创建一个 YAML 文件。在此示例中,它被称为 `example-app-alerting-rule.yaml`。

  2. 向 YAML 文件添加报警规则配置。以下示例创建一个名为 `example-alert` 的新报警规则。当示例服务公开的 `version` 指标变为 `0` 时,报警规则会触发警报。

    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)
    1 您要创建的告警规则的名称。
    2 条件在触发告警之前应为真的持续时间。
    3 定义新规则的 PromQL 查询表达式。
    4 告警规则分配给告警的严重性。
    5 与告警关联的消息。
  3. 将配置文件应用于集群

    $ oc apply -f example-app-alerting-rule.yaml
其他资源
  • 有关 OpenShift Container Platform 4.17 监控架构的详细信息,请参阅 监控概述

访问用户定义项目的报警规则

要列出用户定义项目的报警规则,您必须已为该项目分配 `monitoring-rules-view` 集群角色。

先决条件
  • 您已为用户定义的项目启用监控。

  • 您已登录为具有您项目的 `monitoring-rules-view` 集群角色的用户。

  • 您已安装 OpenShift CLI(oc)。

步骤
  1. 要列出 `` 中的报警规则

    $ oc -n <project> get prometheusrule
  2. 要列出报警规则的配置,请运行以下命令

    $ oc -n <project> get prometheusrule <rule> -o yaml

在一个视图中列出所有项目的报警规则

作为集群管理员,您可以将核心 OpenShift Container Platform 和用户定义项目的报警规则一起在一个视图中列出。

先决条件
  • 您可以作为具有 `cluster-admin` 角色的用户访问集群。

  • 您已安装 OpenShift CLI(oc)。

步骤
  1. 管理员视角下,导航到观察告警告警规则

  2. 筛选下拉菜单中选择平台用户来源。

    平台来源默认选中。

删除用户自定义项目的告警规则

您可以删除用户自定义项目的告警规则。

先决条件
  • 您已为用户定义的项目启用监控。

  • 您已登录为具有您想要创建报警规则的项目的 `monitoring-rules-edit` 集群角色的用户。

  • 您已安装 OpenShift CLI(oc)。

步骤
  • 要删除<foo>命名空间<namespace>中的规则,请运行以下命令:

    $ oc -n <namespace> delete prometheusrule <foo>
其他资源

将通知发送到外部系统

在 OpenShift Container Platform 4.17 中,触发的告警可以在告警 UI 中查看。默认情况下,告警未配置为发送到任何通知系统。您可以将 OpenShift Container Platform 配置为将告警发送到以下接收器类型:

  • PagerDuty

  • Webhook

  • 电子邮件

  • Slack

  • Microsoft Teams

将告警路由到接收器使您能够在发生故障时及时向相应的团队发送通知。例如,关键告警需要立即关注,通常会发送给个人或关键响应团队。提供非关键警告通知的告警可能会路由到票务系统,以便稍后进行审查。

使用监控告警检查告警是否正常运行

OpenShift Container Platform 监控包含一个持续触发的监控告警。Alertmanager 会重复将监控告警通知发送到已配置的通知提供程序。提供程序通常配置为在其停止接收监控告警时通知管理员。此机制可帮助您快速识别 Alertmanager 和通知提供程序之间的任何通信问题。

配置告警接收器

您可以配置告警接收器,以确保您了解集群的重要问题。

先决条件
  • 您可以作为具有cluster-admin集群角色的用户访问集群。

步骤
  1. 管理员视角下,转到管理集群设置配置Alertmanager

    或者,您可以通过通知抽屉转到同一页面。选择 OpenShift Container Platform Web 控制台右上角的铃铛图标,然后在AlertmanagerReceiverNotConfigured 告警中选择配置

  2. 单击页面接收器部分中的创建接收器

  3. 创建接收器表单中,添加接收器名称并从列表中选择接收器类型

  4. 编辑接收器配置

    • 对于 PagerDuty 接收器

      1. 选择集成类型并添加 PagerDuty 集成密钥。

      2. 添加 PagerDuty 安装的 URL。

      3. 如果您想编辑客户端和事件详细信息或严重性规范,请单击显示高级配置

    • 对于 Webhook 接收器

      1. 添加要向其发送 HTTP POST 请求的端点。

      2. 如果您想编辑将已解决的告警发送到接收器的默认选项,请单击显示高级配置

    • 对于电子邮件接收器

      1. 添加要发送通知的电子邮件地址。

      2. 添加 SMTP 配置详细信息,包括发送通知的地址、用于发送电子邮件的 Smarthost 和端口号、SMTP 服务器的主机名和身份验证详细信息。

      3. 选择是否需要 TLS。

      4. 如果您想编辑默认选项(不将已解决的告警发送到接收器)或编辑电子邮件通知正文配置,请单击显示高级配置

    • 对于 Slack 接收器

      1. 添加 Slack webhook 的 URL。

      2. 添加要发送通知的 Slack 频道或用户名。

      3. 选择显示高级配置,如果您想编辑默认选项(不将已解决的告警发送到接收器)或编辑图标和用户名配置。您还可以选择是否查找和链接频道名称和用户名。

  5. 默认情况下,具有与所有选择器匹配的标签的已触发告警将发送到接收器。如果您希望在将已触发告警发送到接收器之前精确匹配其标签值,请执行以下步骤:

    1. 在表单的路由标签部分添加路由标签名称和值。

    2. 单击添加标签以添加更多路由标签。

  6. 单击创建以创建接收器。

为默认平台告警和用户自定义告警配置不同的告警接收器

您可以为默认平台告警和用户自定义告警配置不同的告警接收器,以确保以下结果:

  • 所有默认平台告警都将发送到负责这些告警的团队拥有的接收器。

  • 所有用户自定义告警都将发送到另一个接收器,以便团队可以只关注平台告警。

您可以通过使用集群监控操作员添加到所有平台告警的openshift_io_alert_source="platform"标签来实现此目的。

  • 使用openshift_io_alert_source="platform"匹配器匹配默认平台告警。

  • 使用openshift_io_alert_source!="platform"'openshift_io_alert_source=""'匹配器匹配用户自定义告警。

如果您已启用专用于用户自定义告警的单独 Alertmanager 实例,则此配置不适用。

为用户自定义项目创建告警路由

如果您是非管理员用户,并且已获得alert-routing-edit集群角色,则可以为用户自定义项目创建或编辑告警路由。

先决条件
  • 集群管理员已为用户自定义项目启用监控。

  • 集群管理员已为用户自定义项目启用告警路由。

  • 您已登录为具有要为其创建告警路由的项目的alert-routing-edit集群角色的用户。

  • 您已安装 OpenShift CLI(oc)。

步骤
  1. 为告警路由创建一个 YAML 文件。此过程中的示例使用名为example-app-alert-routing.yaml的文件。

  2. 向文件中添加AlertmanagerConfig YAML 定义。例如:

    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

    对于用户自定义告警规则,用户自定义路由的范围限定为定义资源的命名空间。例如,在命名空间ns1AlertmanagerConfig对象中定义的路由配置仅适用于同一命名空间中的PrometheusRules资源。

  3. 保存文件。

  4. 将资源应用于集群。

    $ oc apply -f example-app-alert-routing.yaml

    配置将自动应用于 Alertmanager Pod。

配置 Alertmanager 发送通知

您可以通过编辑默认平台告警的alertmanager-main密钥或用户自定义告警的alertmanager-user-workload密钥来配置 Alertmanager 发送通知。

支持的上一版本 Alertmanager 的所有功能在 OpenShift Alertmanager 配置中也受支持。要检查支持的上一版本 Alertmanager 的所有配置选项,请参阅Alertmanager 配置

配置默认平台告警的通知

您可以配置 Alertmanager 来发送通知。通过编辑 `openshift-monitoring` 命名空间中 `alertmanager-main` 密钥中的默认配置,自定义 Alertmanager 如何以及在何处发送有关默认平台警报的通知。

Alertmanager 默认情况下不发送通知。建议您通过在 `alertmanager-main` 密钥配置文件中设置通知详细信息来配置 Alertmanager 以接收通知。

先决条件
  • 您可以作为具有cluster-admin集群角色的用户访问集群。

步骤
  1. 打开 Alertmanager YAML 配置文件

    • 要从 CLI 打开 Alertmanager 配置

      1. 将当前活动的 Alertmanager 配置从 `alertmanager-main` 密钥打印到 `alertmanager.yaml` 文件中。

        $ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
      2. 打开 `alertmanager.yaml` 文件。

    • 要从 OpenShift Container Platform Web 控制台打开 Alertmanager 配置

      1. 转到 Web 控制台的 **管理** → **集群设置** → **配置** → **Alertmanager** → **YAML** 页面。

  2. 通过更新 YAML 中的参数来编辑 Alertmanager 配置

    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> (7)
    1 指定 Alertmanager 在收集一组警报的初始警报时等待多长时间,然后再发送通知。
    2 指定 Alertmanager 在为已发送初始通知的一组警报添加新警报后,必须经过多长时间才能发送通知。
    3 指定警报通知重复之前必须经过的最小时间量。如果希望通知在每个组间隔重复,请将 `repeat_interval` 值设置为小于 `group_interval` 值。重复的通知仍然可能被延迟,例如,当某些 Alertmanager Pod 重新启动或重新调度时。
    4 指定触发警报的服务的名称。
    5 指定标签以匹配您的警报。
    6 指定要用于警报的接收器的名称。
    7 指定接收器配置。
    • 使用 `matchers` 密钥名称来指示警报必须满足哪些匹配器才能与节点匹配。不要使用 `match` 或 `match_re` 密钥名称,这两个名称已弃用,并计划在未来的版本中删除。

    • 如果您定义了抑制规则,请使用以下密钥名称

      • `target_matchers`:指示目标匹配器

      • `source_matchers`:指示源匹配器

      不要使用 `target_match`、`target_match_re`、`source_match` 或 `source_match_re` 密钥名称,这些名称已弃用,并计划在未来的版本中删除。

    以下 Alertmanager 配置示例将 PagerDuty 配置为警报接收器

    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>"

    通过此配置,由 `example-app` 服务触发的严重性为 `critical` 的警报将通过 `team-frontend-page` 接收器发送。通常,这些类型的警报将分页到个人或关键响应团队。

  3. 应用文件中新的配置

    • 要从 CLI 应用更改,请运行以下命令

      $ 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=-
    • 要从 OpenShift Container Platform Web 控制台应用更改,请单击 **保存**。

配置用户定义警报的通知

如果您启用了专用于用户定义警报路由的单独 Alertmanager 实例,则可以通过编辑 `openshift-user-workload-monitoring` 命名空间中的 `alertmanager-user-workload` 密钥来自定义该实例发送通知的位置和方式。

先决条件
  • 您可以作为具有cluster-admin集群角色的用户访问集群。

  • 您已安装 OpenShift CLI(oc)。

步骤
  1. 将当前活动的 Alertmanager 配置打印到 `alertmanager.yaml` 文件中。

    $ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml
  2. 编辑 `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)
    1 指定标签以匹配您的警报。此示例针对所有具有 `service="prometheus-example-monitor"` 标签的警报。
    2 指定要用于警报组的接收器的名称。
    3 指定接收器配置。
  3. 应用文件中新的配置

    $ 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=-