構文は正しいのにアラートが間違う

目標

レコーディングルールとアラートルールを自分で修正し、正常・リセット・欠損・待機時間のテストを書いて、意味のエラーを検出します。

なぜ重要なのか

文法の成功は、意味の成功ではありません。正常なデータや空のテストだけでは、誤ったルールも通ってしまいます。このラボでは、固定されたPrometheus 3.14.0の実際のpromtoolと、合成の時系列を使います。本番のLabHubや外部のPrometheusの設定、実際の収集対象、Alertmanagerは変更しません。 55分のラボです。必要なら有効期限が切れる前に延長してください。セッションが終了すると、VMと学習者のファイルは回収されます。

用意されているファイルとコマンド

作業フォルダーは/root/pca-rule-labです。以下のステップのファイル名は、すべてこのフォルダーが基準です。 materials/inputs.jsonは固定の入力、materials/expected.jsonは全体の期待結果です。 materials/starter-ファイル名は、意図的なエラーがある出発点です。該当するファイルを、作業フォルダーの同じファイル名でコピーして編集してください。インストールされている材料のファイル自体は上書きしないでください。3つのルールファイルを別々に置くので、あとのステップの修正が、前のステップの答案を消すことはありません。材料や例から正解を推測せず、本文の契約と比較してください。

python3 /opt/fixtures/pca_rule_lab.py complete Nは、現在の答案を検査して、observation-N.jsonに文法・意味の検査結果と、入力のハッシュを保存します。失敗したら、出力のexpとgotを比較し、答案を直してから、もう一度実行してください。 grade Nは、実際のエンジンをもう一度実行しますが、答案と観測は変更しません。prepare Nは、前のステップだけを埋めます。 solve Nは、正解を見ることで、ない答案だけを作り、既存の部分的な答案は上書きしません。 answer Nは、正解の内容をターミナルに出力するだけです。部分的な答案は、その内容と比較して自分で修正できます。テストファイルのrule_filesは、rules.json 1つのままにします。ヘルパーは、該当するステップのルールを、一時コピーのrules.jsonに移したうえで、promtool check rulesとpromtool test rulesを実行します。学習者のフォルダーにrules.jsonを作る必要はありません。 JSONはYAMLの表現として有効であり、直接YAMLで書いてもかまいません。入力・クエリ・時刻・期待値は固定された演習の契約で、テストの順序・入力の順序・サンプルの順序・空白は違ってもかまいません。ルールの式は、結果で検査します。グループ1つ、レコーディングルール3つとアラート1つ、名前・順序・間隔・ラベルは、starterのとおりに維持してください。追加のルール・テンプレート・外部ファイル・YAMLのエイリアスは、この演習の範囲外です。ファイルはUTF-8で64KiB以下でなければなりません。

ステップ

diagnosis.jsonに、syntax_proves_semantics=false、normal_data_sufficient=falseのブール値と、reset_good_rate=10.75、reset_bad_rate=10の数値を書き、complete 1を実行してください。同じ誤った集計ルールの、文法の成功、正常なデータでの成功、リセットの反例での失敗を、observation-1.jsonで比較します。
materials/starter-rate-rules.ymlをrate-rules.ymlにコピーし、pca:requests:rate5mのexprを直してください。元の時系列ごとにrateを計算してから、routeごとに合算することで、正常な6分の/checkout=11、/status=2、リセットの6分の/checkout=10.75になる必要があります。残りのルール・グループ・1mの間隔・ラベルは維持して、complete 2を実行します。
materials/starter-reset-tests.ymlをreset-tests.ymlにコピーし、masked-counter-resetの6分のリクエスト率の期待値を、10から10.75に直してください。2つのシナリオの入力・クエリ・ラベル・残りの期待値は、materials/expected.jsonと照合します。complete 3は、学習者のルールの成功と、集計順序・routeの損失という誤答の失敗を、どちらも検査します。
materials/starter-coverage-rules.ymlをcoverage-rules.ymlにコピーしてください。pca:requests:ready_rate5mのexprで、ないrouteを0で埋める部分を取り除き、現在のcount by(route)が2であるrouteだけを残してください。明示的なstaleのときは/checkoutの結果がなく、実際のリクエストなしのときは値0がある必要があります。/status=2は保存して、complete 4を実行します。
materials/starter-coverage-tests.ymlをcoverage-tests.ymlにコピーしてください。missing-is-not-zeroの6分のready_rate5mの期待サンプルから、/checkout=0を取り除きます。real-zeroの0のサンプルは維持してください。missing-sample-is-not-stalenessの現在の数2・サンプルの経過時間60秒・リクエスト率11も維持して、complete 5を実行します。現在の時系列数を、鮮度の保証と解釈しないでください。
materials/starter-alert-rules.ymlをalert-rules.ymlにコピーし、PcaHighRequestRateにfor: 2mを設定してください。exprは保護したrate > 10.5、severityはpracticeのままにします。正常なデータは、5分・6分がpending、7分がfiringで、6分にstaleを入れたあとは、7分・8分がpending、9分がfiringになる必要があります。complete 6を実行して、6つのシナリオ全体を検査します。
materials/starter-alert-tests.ymlをalert-tests.ymlにコピーしてください。gap-restarts-pendingの7分のfiringのアラートの期待値を、空のexp_alertsに直します。9分の発火と、ALERTSのpending・なし・firingの検査、単純なサンプル欠落の7分の発火は、維持してください。complete 7は、forなし・1分・3分・保護条件なしという、4つの誤答も検査します。
report.jsonに、missing_is_zero=false、count_proves_freshness=false、notification_delivery_tested=false、production_scraping_tested=falseのブール値と、stale_gap_fires_at="9m"、missing_sample_fires_at="7m"の文字列を書いてください。complete 8で、ルール・テストの契約・前のステップの観測を、再検証します。実際の通知の配信や、本番のscrapeを確認したと書かないでください。

参考と限界

初期の0から始まる合成入力と、1分の評価間隔の結果です。5mの窓の境界の外挿を含むので、入力を変えて、同じ数字を期待しないでください。/checkoutのaだけがリセットされるあいだ、bは増え続け、/statusは独立した対照用のrouteです。明示的なstaleと、単純なサンプルの欠落は、別の入力です。count=2は、サンプルの鮮度やインスタンスの身元の保証ではありません。待機時間は仮想の評価時間であり、実際に9分待つことはありません。pendingとfiringは、ALERTSのラベルでも検査します。アラートのfiringを確認したことは、外部への通知の配信を確認したことではありません。実際のscrapeのネットワーク動作は、このテストにはありません。資料のハッシュは、偶発的な上書きと、他のラボの観測の混用を見つけるための仕組みです。同じVMのrootがすべてのコードを改ざんすることを防ぐ、セキュリティ上の保証ではありません。採点は60秒、準備は90秒の予算で、エンジンはさらに短く制限されます。公式のルールテスト

文法と意味の検査の責任を分ける

diagnosis.jsonに、syntax_proves_semantics=false、normal_data_sufficient=falseのブール値と、reset_good_rate=10.75、reset_bad_rate=10の数値を書き、complete 1を実行してください。同じ誤った集計ルールの、文法の成功、正常なデータでの成功、リセットの反例での失敗を、observation-1.jsonで比較します。

同じルールが、異なる入力でどんな結果を出すかを見てください。

リセットを隠さないレコーディングルールを書く

materials/starter-rate-rules.ymlをrate-rules.ymlにコピーし、pca:requests:rate5mのexprを直してください。元の時系列ごとにrateを計算してから、routeごとに合算することで、正常な6分の/checkout=11、/status=2、リセットの6分の/checkout=10.75になる必要があります。残りのルール・グループ・1mの間隔・ラベルは維持して、complete 2を実行します。

合計にrateを適用すると、元のリセットを失うことがあります。

誤った集計を拒否するテストを書く

materials/starter-reset-tests.ymlをreset-tests.ymlにコピーし、masked-counter-resetの6分のリクエスト率の期待値を、10から10.75に直してください。2つのシナリオの入力・クエリ・ラベル・残りの期待値は、materials/expected.jsonと照合します。complete 3は、学習者のルールの成功と、集計順序・routeの損失という誤答の失敗を、どちらも検査します。

期待値を実装に合わせて下げると、テストは誤ったルールを許してしまいます。

ない測定と実際の0を区別するルールを書く

materials/starter-coverage-rules.ymlをcoverage-rules.ymlにコピーしてください。pca:requests:ready_rate5mのexprで、ないrouteを0で埋める部分を取り除き、現在のcount by(route)が2であるrouteだけを残してください。明示的なstaleのときは/checkoutの結果がなく、実際のリクエストなしのときは値0がある必要があります。/status=2は保存して、complete 4を実行します。

現在のサンプルがないことと、存在する値0は、別の状態です。

欠損と鮮度の限界をテストに残す

materials/starter-coverage-tests.ymlをcoverage-tests.ymlにコピーしてください。missing-is-not-zeroの6分のready_rate5mの期待サンプルから、/checkout=0を取り除きます。real-zeroの0のサンプルは維持してください。missing-sample-is-not-stalenessの現在の数2・サンプルの経過時間60秒・リクエスト率11も維持して、complete 5を実行します。現在の時系列数を、鮮度の保証と解釈しないでください。

直前のサンプルがlookback内で選ばれるかを、timestampで見てください。

アラートの発火前後の時間の境界を設定する

materials/starter-alert-rules.ymlをalert-rules.ymlにコピーし、PcaHighRequestRateにfor: 2mを設定してください。exprは保護したrate > 10.5、severityはpracticeのままにします。正常なデータは、5分・6分がpending、7分がfiringで、6分にstaleを入れたあとは、7分・8分がpending、9分がfiringになる必要があります。complete 6を実行して、6つのシナリオ全体を検査します。

発火直前の状態も検査してこそ、早すぎる発火を見つけられます。

途切れた待機が再開するかをテストする

materials/starter-alert-tests.ymlをalert-tests.ymlにコピーしてください。gap-restarts-pendingの7分のfiringのアラートの期待値を、空のexp_alertsに直します。9分の発火と、ALERTSのpending・なし・firingの検査、単純なサンプル欠落の7分の発火は、維持してください。complete 7は、forなし・1分・3分・保護条件なしという、4つの誤答も検査します。

staleで条件が途切れたあとのforは、復帰した時点からもう一度数えます。

ルールとテストをあわせて再検証し、範囲を報告する

report.jsonに、missing_is_zero=false、count_proves_freshness=false、notification_delivery_tested=false、production_scraping_tested=falseのブール値と、stale_gap_fires_at="9m"、missing_sample_fires_at="7m"の文字列を書いてください。complete 8で、ルール・テストの契約・前のステップの観測を、再検証します。実際の通知の配信や、本番のscrapeを確認したと書かないでください。

テストで確認した状態と、外部システムの動作を分けて報告してください。