保存されたルールが評価されるまで

一言でいうと

PrometheusRuleを作ったということは、ルールをKubernetesに保存したという意味です。そのルールが選択され、Prometheusにロードされ、実際の時系列に対して評価されるかどうかは、それぞれ確認する必要があります。

なぜ必要なのか

仮想の払い出しプラットフォームチームは、障害のアラートルールを追加しました。ターミナルにはcreatedと表示され、コードレビューでも式が正しいと確認されました。数日後、払い出しAPIが503を返しているのに、ページが届きませんでした。ルール名を検索すると、Kubernetesでは見えるのに、Prometheusのrules APIにはありませんでした。チームは「アラートの式をもっと敏感に変えよう」と言いましたが、読まれてもいない式のしきい値を変えても、今回の失敗は直りません。

問題は、別々の2つの成功を、同じものと呼んだことにあります。APIサーバーはオブジェクトの保存を担当し、Operatorは自分が管理するPrometheusに入れるオブジェクトを選んで、構成を作ります。アプリケーションチームがルールを保存する権限を持っていても、すべてのPrometheusがそのルールを読む設計なら、複数のチームのルールが無秩序に混ざります。選択範囲は不便な障壁ではなく、所有権と運用範囲を表す仕組みです。

どう動くのか

観測対象	確認する問い	まだ証明できないこと
KubernetesのPrometheusRule	ルールオブジェクトが保存されているか	Operatorによる選択・実際の評価
Namespaceとルールのラベル	指定された選択範囲に入っているか	構成が実際のプロセスに反映されたか
Prometheus rules API	実行中のインスタンスにグループがロードされたか	条件の成立・アラートの配信
targets API	どのアドレスを、どんな結果で収集しているか	その業務が成功しているか

選択は2回絞り込みます。まず、ruleNamespaceSelectorが、ルールを探すネームスペースを選びます。その範囲で、ruleSelectorがPrometheusRuleのラベルを検査します。デフォルト値と、空のセレクターの意味は、フィールドごとに異なることがあるため、「何も書いていないから、すべて選択されるだろう」と推測しません。正確な動作は、Operatorのルール選択の案内で確認します。

たとえば、monitoring=yesのネームスペースのうち、owner=paymentsのルールだけを読むインスタンスがあるとします。ルールにowner=paymentsを入れても、ネームスペースが範囲外なら読みません。ネームスペースだけを直しても、ルールがowner=ordersなら、やはり読みません。2つを一度に全体選択に変えると、すぐには見えるようになるかもしれませんが、ほかのチームのルールまで読んで、重複アラートやコスト増加を招くことがあります。必要な条件を1つだけ直して、もう一度観測します。

メトリクスの収集も、別の選択経路です。ServiceMonitorが、Serviceのラベルとポート名を通じて収集対象を探し、PrometheusはServiceMonitorのネームスペースとラベルを選択します。ポートの数字を文字列で書くことと、Serviceのポート名を使うことは、同じではありません。権限不足も、ラベルの不一致のように、対象が見えない症状として現れることがあるため、公式のトラブルシューティングの順序に沿って、選択されたオブジェクト、生成された構成、Serviceと検出の権限を、順に確認します。

現場での姿

この単元の準備実験では、対象のメトリクスはupなのに、ルールグループが空でした。ネームスペースのラベルだけを直して、75秒間見ても、ルールは現れませんでした。ルールのラベルを合わせると、約80秒後にロードされました。これは1回の観測値であり、待ち時間を固定することを勧めるものではありません。APIの変更、構成ファイルの投影、リロードと評価が、別々の時点で起きるため、ターミナルのconfiguredを最後の証拠にしてはいけない、という事例です。

失敗レスポンスの形も重要です。最初に作ったexporterは、正しいメトリクス本文を出力していましたが、Content-Typeが空だったため、Prometheus 3のscrapeが失敗しました。対象を見つけることには成功し、内容を読むことに失敗したのです。ラベルをもう一度変えても、この問題は解決しません。targetのlastErrorを読み、生産者のHTTPヘッダーを直しました。この違いは、Prometheus 3の変更案内と突き合わせられます。

収集が成功したupは、アプリケーションがメトリクスを返したという観測です。払い出し機能の外部依存が故障しても、exporterのプロセスは正常に応答し続けることがあります。逆に、メトリクスがないということは、業務が必ず失敗したという意味ではありません。業務の状態と観測の状態を別々に記録し、どちらか一方がわからなければ、その空欄をそのまま残す必要があります。

次のレッスンですること

次の読み物では、ルールをロードしたあとでも、通知が届かない境界を見ます。そのあとのラボで、用意されたルールの式は変えずに、ネームスペース・ルールのラベルを、それぞれ直します。保存されたオブジェクトと、実際のrules・targets APIを合わせて見ます。1つの境界を直したあとに、何が変わり、何がそのままかを記録してください。ラボは、個人VMの実際のk3sを使い、本番クラスターに適用する手順ではありません。