Prometheus で Kubernetes ジョブを監視する際の誤検知の問題を解決する

昨日、Prometheus コースの指導グループのクラスメートが、Prometheus 監視ジョブタスク (コミュニティ Web サイトに同期済み) の誤報に関する問題について言及しました。一般的な意味は、CronJob によって制御されるジョブは、前の実行が失敗した場合にアラームをトリガーすることです。後で生成された新しいジョブは正常に実行できますが、以前のアラームは引き続き受信されます。

これは、ジョブを実行するときに、トラブルシューティングを容易にするために、通常、いくつかの履歴レコードが保持されるためです。したがって、以前に失敗したジョブがあった場合、後で成功したとしても、以前のジョブは存在し続けます。 kube-prometheus の直接インストールとデプロイメントに使用されるデフォルトのアラームルールのほとんどは kube_job_status_failed > 0 であり、これは明らかに不正確です。以前に失敗したジョブを手動で削除することによってのみ、誤報を排除できます。もちろん、この方法で問題は解決できますが、十分に自動化されていません。当初は深く考えず、失敗したジョブを自動的に削除して解決したいと考えていましたが、これでは運用・保守担当者にとっても問題が生じ、戻って問題を解決するのが不便になります。この問題を解決するために考え方を整理してみましょう。

CronJob は、スケジュールされた実行時間ごとに Job オブジェクトを作成します。 .spec.successfulJobsHistoryLimit プロパティと .spec.failedJobsHistoryLimit プロパティを使用して、完了したジョブと失敗したジョブの数を保持できます。デフォルト値はそれぞれ 3 と 1 です。たとえば、次の例では CronJob リソースオブジェクトを宣言しています。

 apiバージョン: バッチ/ v1
 種類: CronJob
 メタデータ:
 名前: こんにちは
仕様:
 スケジュール： 「*/1 * * * *」
 成功したジョブ履歴制限: 1
 失敗したジョブ履歴制限: 1
 ジョブテンプレート:
 仕様:
 テンプレート：
 仕様:
 コンテナ:
 - 名前: こんにちは
画像: ビジーボックス
imagePullPolicy : IfNotPresent
 指示：
 - / bin / sh
 - - う
- 日付;
 再起動ポリシー: 失敗時

上記のリソースオブジェクトの仕様によれば、Kubernetes は失敗したジョブと成功したジョブを 1 つだけ保持します。

 名前完了期間年齢
こんにちは-4111706356 0 / 1 2分10日
hello-4111706356 1 / 1 5秒5秒

上記の誤検知問題を解決するには、Kubernetes API サーバーを監視し、オブジェクトのステータスに関するインジケーターを生成する kube-state-metrics サービスを使用する必要があります。単一の Kubernetes コンポーネントの健全性に焦点を当てるのではなく、デプロイメント、ノード、ジョブ、ポッド、その他のリソースオブジェクトの状態など、さまざまな内部オブジェクトの健全性に焦点を当てます。ここでは次の指標を使用します。

kube_job_owner: ジョブとそれをトリガーした CronJob の関係を見つけるために使用されます。
kube_job_status_start_time: ジョブがトリガーされた時刻を取得します。
kube_job_status_failed: 実行に失敗したタスクを取得します。
kube_cronjob_spec_suspend: 中断されたジョブを除外します。

以下は、CronJob によって実行される hello タスクによって生成されたタグを含むメトリックの例です。

 kube_job_owner { job_name = "hello-1604875860" 、 namespace = "myNamespace" 、 owner_is_controller = "true" 、 owner_kind = "CronJob" 、 owner_name = "hello" } 1
 kube_job_status_start_time { ジョブ名= "hello-1604875860" 、 名前空間= "myNamespace" } 1604875874
 kube_job_status_failed { job_name = "hello-1604875860" 、 namespace = "myNamespace" 、 reason = "BackoffLimitExceeded" } 1
 kube_cronjob_spec_suspend { cronjob = "hello" 、 ジョブ= "kube-state-metrics" 、 名前空間= "myNamespace" } 0

正確な監視とアラームを確実に行うには、同じ CronJob によってトリガーされたジョブグループの最後のタスクを取得するだけで済みます。アラームはジョブの実行に失敗した場合にのみトリガーされます。

kube_job_status_failed および kube_job_status_start_time インジケーターには CronJob のラベルが含まれていないため、最初の手順としてこのラベルを追加します。必要なのは、kube_job_owner インジケーターの owner_name です。マージするには、次の promql ステートメントを使用できます。

 最大（
 kube_job_status_開始時間
 * ON ( ジョブ名、 名前空間) GROUP_RIGHT ()
 kube_job_owner { 所有者名! = "" }
 ）
 BY ( ジョブ名, 所有者名, 名前空間)

ここで max 関数を使用するのは、HA のために複数の kube-state-metrics を実行する可能性があるためです。そのため、max 関数を使用して各ジョブタスクの結果を返します。ジョブ履歴に 2 つのタスク (1 つは失敗、もう 1 つは成功) が含まれていると仮定すると、結果は次のようになります。

 { ジョブ名= "hello-1623578940" 、 名前空間= "myNamespace" 、 所有者名= "hello" } 1623578959
 { ジョブ名= "hello-1617667200" 、 名前空間= "myNamespace" 、 所有者名= "hello" } 1617667204

各ジョブの所有者がわかったので、最後に実行されたタスクを見つける必要があります。これは、owner_name タグごとに結果を集計することで実行できます。

 最大（
 kube_job_status_開始時間
 * ON ( ジョブ名、 名前空間) GROUP_RIGHT ()
 kube_job_owner { 所有者名! = "" }
 ）
 BY ( 所有者名)

上記のステートメントは、各所有者 (つまり、CronJob) の最新のタスク開始時刻を見つけ、それを上記のステートメントとマージして、最後に実行されたジョブタスクと同じ開始時刻のレコードを保持します。

 最大（
 kube_job_status_開始時間
 * ON ( ジョブ名、 名前空間) GROUP_RIGHT ()
 kube_job_owner { 所有者名! = "" }
 ）
 BY ( ジョブ名, 所有者名, 名前空間)
 == ON ( 所有者名) GROUP_LEFT ()
 最大（
 kube_job_status_開始時間
 * ON ( ジョブ名、 名前空間) GROUP_RIGHT ()
 kube_job_owner { 所有者名! = "" }
 ）
 BY ( 所有者名)

結果には、各 CronJob によって最後に実行されたジョブのみが表示されます。

 { ジョブ名= "hello-1623578940" 、 名前空間= "myNamespace" 、 所有者名= "hello" } 1623578959

読みやすさを向上させるために、job_name タグと owner_name タグを job と cronjob に置き換えることもできます。これにより、理解しやすくなります。

 ラベルの置き換え(
 ラベルの置き換え(
 最大（
 kube_job_status_開始時間
 * ON ( ジョブ名、 名前空間) GROUP_RIGHT ()
 kube_job_owner { 所有者名! = "" }
 ）
 BY ( ジョブ名, 所有者名, 名前空間)
 == ON ( 所有者名) GROUP_LEFT ()
 最大（
 kube_job_status_開始時間
 * ON ( ジョブ名、 名前空間) GROUP_RIGHT ()
 kube_job_owner { 所有者名! = "" }
 ）
 BY ( 所有者名)、
 "ジョブ" 、 "$1" 、 "ジョブ名" 、 "(.+)" )、
 "cronjob" 、 "$1" 、 "owner_name" 、 "(.+)" )

次のような結果が表示されるはずです。

 { ジョブ= "hello-1623578940" 、 cronjob = "hello" 、 job_name = "hello-1623578940" 、 namespace = "myNamespace" 、 owner_name = "hello" } 1623578959

上記のクエリステートメントは比較的複雑なので、アラームが評価されるたびにリアルタイム計算を実行すると、Prometheus に大きな負担がかかります。ここでは、記録ルールを使用して同様のオフライン計算方法を実装し、効率を大幅に向上させることができます。各 CronJob の最後に実行されたジョブレコードを取得するには、次の記録ルールを作成します。

 - レコード: ジョブ: kube_job_status_start_time : 最大
式: |
 ラベルの置き換え(
 ラベルの置き換え(
 最大（
 kube_job_status_開始時間
 * ON ( ジョブ名、 名前空間) GROUP_RIGHT ()
 kube_job_owner { 所有者名! = "" }
 ）
 BY ( ジョブ名, 所有者名, 名前空間)
 == ON ( 所有者名) GROUP_LEFT ()
 最大（
 kube_job_status_開始時間
 * ON ( ジョブ名、 名前空間) GROUP_RIGHT ()
 kube_job_owner { 所有者名! = "" }
 ）
 BY ( 所有者名)、
 "ジョブ" 、 "$1" 、 "ジョブ名" 、 "(.+)" )、
 "cronjob" 、 "$1" 、 "owner_name" 、 "(.+)" )

CronJob が最近実行を開始したジョブがわかったので、失敗したジョブを除外したい場合は、kube_job_status_failed インジケーターを使用できます。

 - レコード: ジョブ: kube_job_status_failed : 合計
式: |
 クランプ_max ( ジョブ: kube_job_status_start_time : max 、 1 )
 * ON ( ジョブ) GROUP_LEFT ()
 ラベルの置き換え(
 ( kube_job_status_failed > 0 )、
 「ジョブ」 、 「$1」 、 「ジョブ名」 、 「(.+)」
 ）

ここでは、clamp_max 関数を使用して、job:kube_job_status_start_time:max の結果を、上限が 1 である時系列のセットに変換します。これを使用して、失敗したジョブを乗算でフィルタリングし、最近失敗したジョブタスクのセットを取得します。また、kube_job_status_failed:sum という名前の記録ルールにも追加します。

最後の手順は、次に示すように、失敗したジョブタスクにアラームルールを直接追加することです。

 - アラート: CronJobStatusFailed
 式: |
 ジョブ: kube_job_status_failed : 合計
 * ON ( cronjob 、 名前空間) GROUP_LEFT ()
 ( kube_cronjob_spec_suspend == 0 )

誤検知を避けるため、保留中のタスクを除外しました。これまでに、Prometheus による CronJob タスクの監視における誤検知の問題を解決しました。 kube-prometheus には多数の監視アラームルールが組み込まれていますが、実際のニーズに適さない場合もあるため、完全に信頼できるわけではありません。

<<: 企業がクラウド支出を管理するためのクラウドコスト最適化戦略

>>: クラウドコンピューティングの真の価値を見つける方法を 5 つのステップで説明します。