PromQL Alerts

IBM Cloud Monitoring では、 PromQL を使用して、インフラストラクチャー内の変更をモニターし、アラートを出すことができます。

Prometheus警告の定義

Prometheusのアラートを定義する際には、以下のように指定する必要があります：

条件

有効な PromQL 式を入力してください。 メトリック・アラートとは異なり、 PromQL 照会では、指定された条件を満たす時系列のみが返されます。 例えば、 sysdig_host_cpu_used_percent > 80 と入力すると、CPU 使用率が 80% を超えるホストのみが照会結果に含まれます。 すべてのホストがこのしきい値を下回る場合、照会は 「解決済み」 状態を返します。これは 「データなし」 状態と同じです。

ユーザーは、アラートが本当に解決されたかどうか、またはメトリックが消失してサイレントに失敗したかどうかを判別する際に混乱する可能性があります。 これは、 Prometheus の 「データなし」 状態を解決済み状態と区別できないためです。 Prometheusで「データなし」に対処するための 戦略 があります。

Duration

この期間は、アラートをトリガーする前にアラート条件が true のままでなければならない期間です。 Prometheusには 3つの状態がある： Resolved Pending および Firing。 10m の期間が設定されている場合、 Firing 状態に移行する前に、10 分間の連続期間にわたってアラート条件を一貫して満たす必要があることを意味します。 式が満たされているが、必要な期間が満たされていないアラートは、 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 アラートは、直前の 1 時間の平均ネットワーク送信量を調べます。 この平均が 5 分間連続して 10MB を超えると、アラートがトリガーされます。

一方、 highNetworkTraffic2 は、過去 5 分間の平均ネットワーク送信量に焦点を当てています。 この平均が過去 1 時間に 10MB を超えた場合、アラートがトリガーされます。

より長い期間を使用すると、ノイズの多いアラートを減らすことができますが、一部のアラートがトリガーせずにすぐにしきい値を満たす可能性があることも意味します。 ノイズの多いアラートを抑止することと、場合によっては特定の条件で通知を遅延させることとの間にはトレードオフがあります。

Prometheusとスレッショルド・アラートの違い

Prometheusは、しきい値アラートと同じメトリクスを照会します。 2 つのアラート・タイプの違いは、評価アルゴリズムにあります。

Prometheusとスレッショルド・アラートの違い
しきい値アラート Prometheus
ネイティブ No Data サポート No Data 状態が Resolved 状態と同じである
複数しきい値サポート 複数のしきい値のアラートを 2 つ作成する必要があります
期間なし 期間により、追加の Pending アラート状態が作成されます。
デフォルトですべての時系列が返される照会 照会は、アラート照会を満たす時系列のみを返します。

データなしおよび複数のしきい値の処理

No Data シナリオを特定し、複数のしきい値を設定することの利点を確認するには、 Prometheus アラートからしきい値アラートに切り替えることができます。

メトリック・アラート処理 No Data および複数のしきい値を作成するには、以下のようにします。

  1. 新しいメトリック・アラートを作成する。
  2. アラート作成モードを Form から PromQL に切り替えます。
  3. PromQLを使用してしきい値アラートの設定を続行します。
  4. オプションで、警告しきい値を追加し、 No Data に通知します。

Prometheus アラート・ルールのインポート

Prometheus ルールをインポートできます。 「アップロード」 Prometheus 「ルール」 オプションをクリックし、 「アップロード」 Prometheus 「ルール」 YAML エディターに YAML 形式でルールを入力します。 Prometheusのアラートルールをインポートすると、 Prometheusのアラートに変換されます。

各アラート・ルールには、以下の必須フィールドが含まれている必要があります。

  • alert
  • expr
  • for

例: Prometheus 異常終了ループ・アラート

このアラートは、 prometheus、 pushgateway または alertmanager ジョブでの潜在的な再始動ループを検出します。

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 エラー率アラート

この例では、 NginxHighHttp5xxErrorRate 、5％以上の HTTP エラー率を検出する。

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