IBM Cloud Docs
PromQL 警报

PromQL 警报

IBM Cloud Monitoring 允许您使用 PromQL 来监视基础结构中的更改并发出警报。

定义Prometheus警报

定义 Prometheus 警报时,需要指定以下内容:

条件

输入有效的 PromQL 表达式。 与度量警报不同,PromQL 查询仅返回满足指定条件的时间序列。 例如,如果输入 sysdig_host_cpu_used_percent > 80,那么只有 CPU 使用率高于 80% 的主机才会包含在查询结果中。 如果所有主机都低于此阈值,那么查询将返回 已解决 状态,这与 无数据 状态相同。

用户可能会混淆,以确定警报是否已真正解决,或者度量是否已消失并以静默方式失败。 这是因为无法将 Prometheus 中的 无数据 状态与已解析状态区分开来。 有 策略 用于处理 Prometheus中的“无数据”。

Duration

持续时间是在触发警报之前,警报条件必须保持为 true 的时间长度。 Prometheus警报有三种状态:Resolved, Pending,和 Firing。 如果设置了持续时间 10m,那么这意味着必须持续满足警报条件 10 分钟,然后才能过渡到 Firing 状态。 其表达式满足但未满足所需持续时间的警报处于 Pending 状态。

警报解决延迟

警报解决延迟与 Prometheus中的 keep_firing_for 相同。 此设置允许在用户定义的持续时间内连续触发警报事件,即使在警报条件不再有效之后也是如此。 可以使用“警报解决延迟”配置在底层度量中具有时间间隔 no-data 的警报,以防止不必要的噪声和错误解决。 如果在“警报解决延迟”过去之前再次满足警报条件,那么警报将继续触发,而无需再次满足持续时间。

范围和持续时间

警报持续时间是特定条件在触发警报之前必须持续的时间长度。 不应将其与警报范围混淆,警报范围定义评估相关度量数据的时间段。

下面我们来看一看以下示例:

  rules:
  - alert: highNetworkTraffic1
    expr: avg(rate(network_bytes_total[1h])) > 10000000
    for: 5m
  - alert: highNetworkTraffic2
    expr: avg(rate(network_bytes_total[5m])) > 10000000
    for: 1h

highNetworkTraffic1 警报检查前一小时的平均网络传输率。 如果此平均值在连续持续时间 5 分钟内超过 10MB,那么将触发警报。

另一方面,highNetworkTraffic2 关注过去 5 分钟内的平均网络传输。 如果此平均值在过去一小时内超过 10MB,那么将触发警报。

虽然使用更长的持续时间可以帮助减少嘈杂的警报,但这也意味着某些警报可能暂时满足阈值而不会触发。 在抑制嘈杂警报和可能延迟特定条件的通知之间存在权衡。

Prometheus警报与阈值警报的区别

Prometheus 警报查询的指标与阈值警报相同。 两种警报类型之间的差异在评估算法中。

Prometheus警报与阈值警报的区别
阈值警报 Prometheus警报
本机 No Data 支持 No Data 状态与 Resolved 状态相同
多阈值支持 必须为多个阈值创建两个警报
无持续时间 持续时间将创建额外的 Pending 警报状态
缺省情况下,查询将返回所有时间序列 查询仅返回满足警报查询的时间序列

处理无数据和多个阈值

要了解识别 No Data 场景和配置多个阈值的好处,可以将 Prometheus 警报切换为阈值警报。

要创建度量警报处理 No Data 和多个阈值,请执行以下操作:

  1. 创建新的“度量警报”。
  2. 将警报创建方式从 表单 切换到 PromQL
  3. 继续使用 PromQL 配置阈值警报。
  4. (可选) 在 No Data 上添加警告阈值和通知。

导入 Prometheus 警报规则

您可以导入 Prometheus 规则。 单击 上载 Prometheus 规则 选项,并在 上载 Prometheus 规则 YAML 编辑器中输入 YAML 格式的规则。 导入 Prometheus 警报规则会将其转换为 Prometheus 警报。

每个警报规则都必须包含以下必填字段:

  • alert
  • expr
  • for

示例: Prometheus 崩溃循环警报

此警报会检测 prometheuspushgatewayalertmanager 作业上的潜在重新启动循环。

groups:
- name: crashlooping
  rules:
  - alert: PrometheusTooManyRestarts
    expr: changes(process_start_time_seconds{job=~"prometheus|pushgateway|alertmanager"}[10m]) > 2
    for: 0m
    labels:
      severity: warning
    annotations:
      summary: Prometheus too many restarts (instance {{ $labels.instance }})
      description: Prometheus has restarted more than twice in the last 15 minutes. It might be crashlooping.\n  VALUE = {{ $value }}\n

示例:HTTP 错误率警报 HTTP 错误率警报

在此示例中,NginxHighHttp5xxErrorRate 检测到 HTTP 错误率为 5%或更高。

NginxLatencyHigh 监视所有主机和节点的 p99 等待时间 3 秒或更长时间。

对状态为 5xx (> 5%)或高延迟的 HTTP 请求发出警报:

groups:
- name: default
  rules:
  - alert: NginxHighHttp5xxErrorRate
    expr: sum(rate(nginx_http_requests_total{status=~"^5.."}[1m])) / sum(rate(nginx_http_requests_total[1m])) * 100 > 5
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: Nginx high HTTP 5xx error rate (instance {{ $labels.instance }})
      description: Too many HTTP requests with status 5xx
  - alert: NginxLatencyHigh
    expr: histogram_quantile(0.99, sum(rate(nginx_http_request_duration_seconds_bucket[2m])) by (host, node)) > 3
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: Nginx latency high (instance {{ $labels.instance }})
      description: Nginx p99 latency is higher than 3 seconds