記録ルールとアラートルール、そしてテスト

目標

レコーディングルールを2段の階層として設計し、その上にアラートルールを載せて、期待値を計算した単体テストまで書きます。最後に、同じ内容をPrometheus Operatorが読むCRの形に移します。

なぜ重要なのか

レコーディングルールは、「クエリを速くするキャッシュ」ではなく、計算の時点を移す設計上の判断です。クエリ時点の負荷が評価時点に移り、その代償として新しい時系列が永続的にできます。そのため、作る前に個数を掛け算してみる必要があります。ルート120個にウィンドウ5種類なら、ルール1つが600の時系列で、ルールが50個なら3万個です。階層を分ける理由も同じです。階層1が元データを一度スキャンしておけば、階層2とアラートルールはその結果だけを読むので、元データのスキャンがルールの数だけ繰り返されません。そして、ルールは本番のコードです。本番のコードは、テストなしにデプロイしません。

ステップ

/root/pca-rules/recording.ymlを作成し、groupsの下の最初のグループをname: http_sli、interval: 30sで書きます。
そのグループのrulesに、階層1のルールを2つ入れます。record: route:http_requests:rate5mはsum(rate(http_requests_total[5m])) by (route)、record: route:http_requests_errors:rate5mはsum(rate(http_requests_total{status_class="5xx"}[5m])) by (route)にします。
階層2のルールrecord: route:http_error_ratio:rate5mを、階層1の下に追加します。式は、route:http_requests_errors:rate5mをroute:http_requests:rate5mで割ったもので、元のhttp_requests_totalをもう一度使ってはいけません。
record: route:http_request_duration_seconds:p99_rate5mを追加します。式はhistogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))です。このファイルのレコーディングルールは、合計で4つになります。
/root/pca-rules/alerting.ymlを作成し、グループname: http_alertsの下に、アラートCheckoutHighErrorRatioを書きます。exprはroute:http_error_ratio:rate5m > 0.01、for: 5m、labels.severity: pageで、annotationsにはsummaryとrunbook_url(httpで始まるURL)を入れます。
/root/pca-rules/recording_test.ymlに、promtoolの単体テストを書きます。rule_filesはrecording.yml、evaluation_interval: 30s、tests[0].interval: 15sで、input_seriesには2xx(0+150x40)と5xx(0+3x40)の2つの時系列を入れ、promql_expr_testにはexpr: route:http_error_ratio:rate5m、eval_time: 8mを入れ、exp_samplesのvalueは、3を153で割った値(0.0196で始まります)にします。
ネームスペースpca-rulesを作成し、/root/pca-rules/prometheusrule.yamlにPrometheusRuleを書きます。apiVersion: monitoring.coreos.com/v1、kind: PrometheusRule、metadata.name: checkout-sli、metadata.namespace: pca-rules、metadata.labels.release: kube-prometheus-stack、spec.groups[0].name: checkout_sliを設定し、その中にrecord: route:http_error_ratio:rate5mとalert: CheckoutHighErrorRatioを一緒に入れます。

参考

exprは1行で書いてもよく、expr: |ブロックで複数行に書いてもかまいません。採点は空白を無視します。
ステップ6の期待値は、自分で計算してください。15秒間隔で2xxが150、5xxが3ずつ増えるなら、rateの比率は3 / (150 + 3)です。
よくある間違い1: 階層2を階層1より上に書いてしまうことです。同じグループは上から下へ評価されます。
よくある間違い2: レコーディングルール名のコロンを抜かしてしまうことです。コロンは、派生した時系列であることの印です。
よくある間違い3: PrometheusRuleにreleaseラベルを入れ忘れることです。オペレーターのruleSelectorが、このラベルで選びます。

ルールグループの枠を作る

/root/pca-rules/recording.ymlを作成し、groupsの下の最初のグループをname: http_sli、interval: 30sで書きます。

ルールファイルの最上位はgroupsのリストです。各グループはnameと、任意のintervalを持ちます。intervalを省略すると、global.evaluation_intervalが使われます。同じグループのルールは、順番に評価されます。

階層1: 元データを1回だけスキャンする

そのグループのrulesに、階層1のルールを2つ入れます。record: route:http_requests:rate5mはsum(rate(http_requests_total[5m])) by (route)、record: route:http_requests_errors:rate5mはsum(rate(http_requests_total{status_class="5xx"}[5m])) by (route)にします。

recordフィールドに新しい時系列名を、exprに式を書きます。rateをsumの内側に置く順序を守り、2つのルールとも同じ次元(route)で集計しておかないと、あとで割れません。

階層2: 階層1だけを参照する

階層2のルールrecord: route:http_error_ratio:rate5mを、階層1の下に追加します。式は、route:http_requests_errors:rate5mをroute:http_requests:rate5mで割ったもので、元のhttp_requests_totalをもう一度使ってはいけません。

比率のルールが元のメトリクスをもう一度スキャンするなら、階層を分けた意味がありません。先に作った2つの時系列名だけを使って割ってください。グループの中では上から下へ評価されるので、順序も重要です。

p99のレコーディングルール

record: route:http_request_duration_seconds:p99_rate5mを追加します。式はhistogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))です。このファイルのレコーディングルールは、合計で4つになります。

名前は、レベル:メトリクス:演算の規約に従います。コロンがない名前は、元のメトリクスと区別できません。式では、バケットにrateをかけ、集計でleを必ず残してください。

アラートルールのファイル

/root/pca-rules/alerting.ymlを作成し、グループname: http_alertsの下に、アラートCheckoutHighErrorRatioを書きます。exprはroute:http_error_ratio:rate5m > 0.01、for: 5m、labels.severity: pageで、annotationsにはsummaryとrunbook_url(httpで始まるURL)を入れます。

アラートルールは、recordの代わりにalertフィールドを使います。式はレコーディングルールの結果を参照すると、評価のたびに元データをなめずに済みます。forは、条件が連続して真である時間で、途中で一度でも偽になると、タイマーが0に戻ります。

promtoolの単体テストファイル

/root/pca-rules/recording_test.ymlに、promtoolの単体テストを書きます。rule_filesはrecording.yml、evaluation_interval: 30s、tests[0].interval: 15sで、input_seriesには2xx(0+150x40)と5xx(0+3x40)の2つの時系列を入れ、promql_expr_testにはexpr: route:http_error_ratio:rate5m、eval_time: 8mを入れ、exp_samplesのvalueは、3を153で割った値(0.0196で始まります)にします。

input_seriesのvaluesは、시작+증가x횟수(プレースホルダーは開始値、増分、回数です)の構文です。15秒間隔で2xxが150ずつ、5xxが3ずつ増えるなら、エラー比率は3を153で割った値です。期待値を自分で計算して書いておくと、あとでルールの意味が変わったときにCIが見つけてくれます。

PrometheusRule CRに移す

ネームスペースpca-rulesを作成し、/root/pca-rules/prometheusrule.yamlにPrometheusRuleを書きます。apiVersion: monitoring.coreos.com/v1、kind: PrometheusRule、metadata.name: checkout-sli、metadata.namespace: pca-rules、metadata.labels.release: kube-prometheus-stack、spec.groups[0].name: checkout_sliを設定し、その中にrecord: route:http_error_ratio:rate5mとalert: CheckoutHighErrorRatioを一緒に入れます。

オペレーターはruleSelectorでCRを選ぶので、ラベルが合っていないと、ファイルが存在しても無視されます。spec.groupsの構造はルールファイルと同じで、1つのCRにレコーディングルールとアラートルールを一緒に入れられます。CRDがない環境なので、ファイルだけを書いて、ネームスペースだけを実際に作成します。