Prometheusは、設定して定期的に評価できる2種類のルール（レコーディングルールとアラートルール）をサポートしています。Prometheusにルールを含めるには、必要なルールステートメントを含むファイルを作成し、Prometheus設定の`rule_files`フィールドを介してPrometheusにファイルを読み込ませます。ルールファイルはYAMLを使用します。
ルールファイルは、Prometheusプロセスに`SIGHUP`を送信することで、実行時にリロードできます。変更は、すべてのルールファイルの形式が正しい場合にのみ適用されます。
ネイティブヒストグラムに関する注意（実験的機能）：ネイティブヒストグラムは常にゲージヒストグラムとして記録されます（今のところ）。ほとんどの場合、`rate（）`の後など、ゲージヒストグラムが自然に作成されます。
Prometheusサーバーを起動せずにルールファイルの構文が正しいかどうかをすばやく確認するには、Prometheusの`promtool`コマンドラインユーティリティツールを使用できます。
promtool check rules /path/to/example.rules.yml
`promtool`バイナリは、プロジェクトのダウンロードページで提供されている`prometheus`アーカイブの一部です。
ファイルの構文が有効な場合、チェッカーは解析されたルールのテキスト表現を標準出力に出力し、`0`の戻りステータスで終了します。
構文エラーまたは無効な入力引数がある場合、エラーメッセージを標準エラーに出力し、`1`の戻りステータスで終了します。
レコーディングルールを使用すると、頻繁に必要な式や計算コストの高い式を事前に計算し、その結果を新しい時系列データセットとして保存できます。事前に計算された結果のクエリは、必要なときに毎回元の式を実行するよりもはるかに高速になることがよくあります。これは、更新するたびに同じ式を繰り返しクエリする必要があるダッシュボードで特に役立ちます。
レコーディングルールとアラートルールは、ルールグループ内に存在します。グループ内のルールは、同じ評価時間で、定期的に順番に実行されます。レコーディングルール名は有効なメトリック名である必要があります。アラートルール名は有効なラベル値である必要があります。
ルールファイルの構文は次のとおりです。
groups:
[ - <rule_group> ]
簡単なルールファイルの例を次に示します。
groups:
- name: example
rules:
- record: code:prometheus_http_requests_total:sum
expr: sum by (code) (prometheus_http_requests_total)
<rule_group># The name of the group. Must be unique within a file.
name: <string>
# How often rules in the group are evaluated.
[ interval: <duration> | default = global.evaluation_interval ]
# Limit the number of alerts an alerting rule and series a recording
# rule can produce. 0 is no limit.
[ limit: <int> | default = 0 ]
# Offset the rule evaluation timestamp of this particular group by the specified duration into the past.
[ query_offset: <duration> | default = global.rule_query_offset ]
rules:
[ - <rule> ... ]
<rule>レコーディングルールの構文は次のとおりです。
# The name of the time series to output to. Must be a valid metric name.
record: <string>
# The PromQL expression to evaluate. Every evaluation cycle this is
# evaluated at the current time, and the result recorded as a new set of
# time series with the metric name as given by 'record'.
expr: <string>
# Labels to add or overwrite before storing the result.
labels:
[ <labelname>: <labelvalue> ]
アラートルールの構文は次のとおりです。
# The name of the alert. Must be a valid label value.
alert: <string>
# The PromQL expression to evaluate. Every evaluation cycle this is
# evaluated at the current time, and all resultant time series become
# pending/firing alerts.
expr: <string>
# Alerts are considered firing once they have been returned for this long.
# Alerts which have not yet fired for long enough are considered pending.
[ for: <duration> | default = 0s ]
# How long an alert will continue firing after the condition that triggered it
# has cleared.
[ keep_firing_for: <duration> | default = 0s ]
# Labels to add or overwrite for each alert.
labels:
[ <labelname>: <tmpl_string> ]
# Annotations to add to each alert.
annotations:
[ <labelname>: <tmpl_string> ]
レコーディングルールによって作成されたメトリックの命名に関するベストプラクティスも参照してください。
アラートルールによって生成されるアラートとレコーディングルールによって生成される時系列の制限は、グループごとに設定できます。制限を超えると、ルールによって生成された*すべて*の時系列が破棄され、アラートルールの場合、ルールのアクティブ、保留中、または非アクティブな*すべて*のアラートもクリアされます。イベントは評価でエラーとして記録されるため、古いマーカーは書き込まれません。
これは、基礎となるメトリックがPrometheusで受信および保存されていることを確認するのに役立ちます。メトリックの可用性の遅延は、分散システムの性質上、Prometheusがリモート書き込みターゲットとして実行されている場合に発生する可能性が高くなりますが、スクレイピングの異常や評価間隔が短い場合にも発生する可能性があります。
ルールグループが次の評価の開始予定時刻（`evaluation_interval`で定義）までに評価を完了していない場合、次の評価はスキップされます。ルールグループのそれ以降の評価は、最初の評価が完了するかタイムアウトするまでスキップされ続けます。これが発生すると、レコーディングルールによって生成されるメトリックにギャップが生じます。ルールグループの反復が欠落するたびに、`rule_group_iterations_missed_total`メトリックが増加します。
このドキュメントはオープンソースです。問題の報告またはプルリクエストを送信して、改善にご協力ください。