跳到主要内容

告警规则

配置提醒

告警功能的配置涉及监控数据查询、告警逻辑设置、通知策略管理等多个环节，建议由专业的运维技术人员负责。合理的告警规则可以帮助团队及时发现并响应系统异常，而不合理的配置可能导致多噪音、误报、漏报。

在配置告警规则前，请认真阅读本帮助文档，确保充分理解各项配置的作用及最佳实践。通常建议先整体阅读 2-3 遍，熟悉流程和关键配置后再上手操作。对于复杂的监控场景，建议先在测试环境中验证，确认规则准确无误后再应用到生产环境，以确保监控告警的准确性和可靠性。

配置项详解​

以下详细说明了告警规则中各配置项的作用、含义及最佳实践建议，旨在帮助用户更高效地配置和管理告警规则。

1. 告警规则名称 (Enter alert rule name)

  • 说明：填写一个唯一且具有描述性的名称，用以标识该告警规则。
  • 建议：使用易读且能反映监控对象或业务场景的名称，如 prod_cpu_high_usage 或 生产环境磁盘使用率过高。

2. 查询与告警条件定义 (Define query and alert condition)

告警规则一般分为三个步骤，每一步都对数据进行处理，直至判断是否触发告警：

2.1 步骤 A – 查询原始数据

  • 操作：通过 PromQL 查询，从数据源获取时间序列数据。
  • 建议：确保查询语句准确，并返回所需的关键指标数据。

2.2 步骤 B – 数据处理（Reduce）

  • 作用：将步骤 A 返回的时间序列数据归约为单个数值。
  • 配置项：
    • Input：引用步骤 A 的查询结果。
    • Function：选择 Last，即取最新的数据值。
    • Mode：使用 Strict 模式，要求输入数据必须有效，否则不进行计算。
  • 建议：选择合适的归约函数（如 Last、Avg、Max 等），以确保计算结果能够准确反映当前状态。

2.3 步骤 C – 阈值判断（Threshold）

  • 作用：判断步骤 B 得到的数值是否满足触发告警的条件。
  • 配置项：
    • Input：引用步骤 B 的归约结果。
    • 条件：例如 “Is above”（大于）某个设定阈值时触发告警。
    • 可选：设置自定义恢复阈值，防止告警抖动。
  • 建议：根据监控对象特性及历史数据，合理设置阈值，避免误报或漏报。

3. 评估行为配置 (Set evaluation behavior)

3.1 文件夹 (Folder)

  • 作用：逻辑上对告警规则进行分类管理，便于不同业务或团队快速定位。
  • 配置项：
    • Choose：从已有文件夹中选择，如 General。
    • New folder：新建文件夹，建议使用业务、环境（生产/测试）或团队命名，如 Prod。
  • 建议：统一命名规则，方便权限管理和后续维护。

3.2 评估组与评估间隔 (Evaluation Group and Interval)

  • 作用：定义告警规则的检查频率及资源分配策略，确保系统性能与实时性之间的平衡。
  • 关键概念：
    • Evaluation group and interval：一组共享相同评估间隔的告警规则，便于统一调度和优化资源使用。
    • New evaluation group：新建分组，建议结合业务场景、告警规则的关键性以及评估间隔的特点来命名，以便于理解和维护。
      • 这里根据优先级分层式提供一些简洁的评估组命名示例：
        • Critical-1m
        • Standard-5m
        • High-15m
  • 建议：
    • 对于关键、实时性要求高的指标（如 CPU 使用率、内存占用），可采用较短的间隔（例如 1m）。
    • 对于实时性要求不高的指标，可以适当拉长间隔（例如 15m），以降低资源消耗。

3.3 待处理期 (Pending Period)

  • 作用：在触发告警前，要求告警条件持续满足一定时间，防止因短暂波动导致误报。
  • 配置选项：
    • None：条件一旦满足立即触发告警，适用于对延迟要求极低的场景。
    • 1m/2m/.../5m：条件需持续满足指定时间后才触发告警。
  • 建议：
    • 对于易受短暂波动影响的指标（如网络抖动），建议设置 1-2 分钟的待处理期。
    • 对于关键系统指标，需权衡延迟与准确性，选择适当的时间窗口。
    • 一般无特殊要求，保持默认 1m 即可。

4. 标签与通知配置 (Configure labels and notifications)

4.1 标签 (Labels)

  • 作用：
    • 为告警添加元数据（如 severity=high、team=ops），便于后续搜索、过滤和告警路由。
  • 建议（无特殊要求可不配置）：
    • 设定统一的标签规范，确保不同规则之间的一致性。
    • 利用标签将告警按业务、紧急程度等维度分类。

4.2 通知配置 (Notifications)

  • 作用：定义告警触发时的通知接收方式和渠道。
  • 关键配置项：
    • Contact Point：选择或配置具体的通知渠道（如 Email、DingDing 等）。
    • Mute Timings、Grouping 和 Override Timings：用于精细控制通知的抑制、分组和发送频率。
  • 建议：
    • 定期检查和更新通知渠道，确保责任人能及时收到告警信息。
    • 利用分组和抑制策略避免因同一故障产生大量重复通知。

5. 通知消息模板 (Configure notification message)

5.1 Summary（摘要，可选）

  • 作用：用一句话概括告警的核心问题，便于快速识别和响应。
  • 建议：保持简洁明了，突出关键问题。

5.2 Description（描述，可选）

  • 作用：详细描述告警规则的监控对象、检测逻辑及可能的影响范围，方便后续故障排查。
  • 建议：可以包含上下文信息、历史趋势或建议的初步排查步骤。

5.3 Runbook URL（应急预案链接，可选）

  • 作用：关联至详细的应急预案文档，指导故障处理流程。
  • 建议：确保链接地址有效，且预案内容及时更新。

5.4 添加自定义注解 (Add Custom Annotation)

  • 作用：扩展告警消息的上下文信息，添加额外的键值对，如负责人、服务名等。
  • 建议：根据实际需求添加必要的注解，便于后续自动化处理和归档。

5.5 关联仪表盘和面板 (Link Dashboard and Panel)

  • 作用：在告警通知中提供直接跳转至相关监控仪表盘或面板的链接，加速故障定位。
  • 建议：确保链接保持最新，与 Grafana 中实际配置的仪表盘对应。

配置示例​

以下以磁盘使用率过高为例，提供一个逻辑简单且实用的配置示例，帮助用户快速上手告警规则配置。

1. 告警规则名称 (Enter alert rule name)

  • name：磁盘使用率过高

2. 查询与告警条件定义 (Define query and alert condition)

  • PromQL：

    100 * ((node_filesystem_size_bytes{fstype=~"xfs|ext4", mountpoint=~"/|/data"} - node_filesystem_avail_bytes{fstype=~"xfs|ext4", mountpoint=~"/|/data"}) / node_filesystem_size_bytes{fstype=~"xfs|ext4", mountpoint=~"/|/data"})
    • 本 PromQL 含义是查询 / 与 /data 路径磁盘使用率。

  • 告警阈值：90

3. 评估行为配置 (Set evaluation behavior)

  • Folder：选择文件夹，如果没有则创建，例如 Prod。

  • Evaluation Group and Interval：选择分组，如果没有则创建，例如:

    • Evaluation group name（评估组名称）：Standard-5m。
    • Evaluation interval（评估间隔）：5m。

  • Pending period：设置待处理期，不能低于评估间隔，例如 5m。

4. 标签与通知配置 (Configure labels and notifications)

  • Contact point：选择告警接收渠道（需要提前配置通知方式）

5. 通知消息模板 (Configure notification message)

  • Summary：设置一句摘要：

    磁盘设备：{{ $labels.device }}，挂载路径：{{ $labels.mountpoint }}，当前使用率：{{ printf "%.2f" $values.B.Value }} %

6. 配置完成后，点击右上角 Save rule and exit 进行保存退出。

在告警规则页面即可看到新增的规则：

调低阈值，测试触发告警事件，消息呈现效果如下：

常用 PromQL​

CPU使用率过高​

PromQL：

100 * (1 - avg(irate(node_cpu_seconds_total{mode="idle"}[2m])) by (instance))
  • 阈值示例：90

Summary：

CPU 当前使用率：{{ printf "%.2f" $values.B.Value }} %

内存使用率过高​

PromQL：

(1 - (node_memory_MemAvailable_bytes / (node_memory_MemTotal_bytes)))* 100
  • 阈值示例：90

Summary：

内存当前使用率：{{ printf "%.2f" $values.B.Value }} %

磁盘使用率过高​

PromQL：

100 * ((node_filesystem_size_bytes{fstype=~"xfs|ext4", mountpoint=~"/|/data"} - node_filesystem_avail_bytes{fstype=~"xfs|ext4", mountpoint=~"/|/data"}) / node_filesystem_size_bytes{fstype=~"xfs|ext4", mountpoint=~"/|/data"})
  • 阈值示例：90

Summary：

磁盘设备：{{ $labels.device }}，挂载路径：{{ $labels.mountpoint }}，当前使用率：{{ printf "%.2f" $values.B.Value }} %

Kafka消费组堆积​

PromQL：

sum(kafka_consumergroup_lag{}) by (consumergroup, topic)
  • 阈值示例：10000

Summary：

消费组：{{ $labels.consumergroup }}，Topic：{{ $labels.topic }}，当前堆积量：{{ printf "%.2f" $values.B.Value }}