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

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 : max1 )
* 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 つのステップで説明します。

推薦する

2回連続の降格から立ち直る方法

私は以前、最適化が比較的容易なエンターテイメント サイトに携わっていました。6 月初旬にエンタープラ...

ウェブサイト最適化入門シリーズ1:ウェブサイト構築の初期段階に盲目的に従わない

この記事を長い間書きたいと思っていましたが、今日ようやく書き始める時間ができました。今日は主に、We...

Inspur Cloud が四川省気象局の IT システムの複数の機能のアップグレードを支援

気象情報化がなければ、気象の近代化はあり得ません。気象情報化は、「国家気象発展第14次5カ年計画」の...

Jiuzhoutong Wanyougangは製薬業界におけるクラウドコンピューティングの実践を共有し、クラウドとデータの統合について探ります。

[原文記事:51CTO.com] 国内の先進的な医薬品流通企業として、ジョインタウンは「テクノロジー...

ウェブサイトを関連性のあるものにする方法

ウェブサイトの関連性には、コンテンツの関連性とリンクの関連性が含まれます。ウェブサイトの関連性が完璧...

hostdare-ロサンゼルス クアドラネット データセンター VPS シンプルテスト

一昨日、「hostdare - 1.79 USD/512M メモリ/30G SSD/1T トラフィッ...

テンプレートベースのウェブサイト構築は本当に SEO に役立たないのでしょうか?

2018年最もホットなプロジェクト:テレマーケティングロボットがあなたの参加を待っていますテンプレー...

キッシンジャー:ネハレムは、IT業界が飛躍的な発展を遂げることを可能にする孫悟空の宙返りクラウドである

インテル コーポレーションの上級副社長であり、デジタル エンタープライズ グループ (DEG) の共...

ランキングがない悩みを解消する医療ステーション運営の新アイデア

医療ウェブサイトを運営している友人は、まだランクインはしているがランキングには入っていないのではない...

クラウド戦争の次のステップ:エッジ

10 年以上前、Amazon Web Services (AWS) は、柔軟なコンピューティング イ...

Baidu サイトリンクは肉に脂肪を加え、SEO の狼が本当にやってくる

11月初旬、Google Sitelinkにヒントを得たBaidu Sitelinkが正式にリリース...

AWS、COVID-19の薬物検査を加速

[51CTO.comよりオリジナル記事] 庚子年の初めに新型コロナウイルスが流行し、人々の仕事や生活...

ライブストリーミングはソーシャルeコマースの安全な避難所に過ぎない

トラフィックと資本配当のピークにより、ソーシャル e コマースの進化は避けられなくなりました。ライブ...

SEOをうまく行うには、外部リンクだけでは不十分です

多くのウェブマスターは、SEO は主に外部リンクに関するものだと考えています。実際、近年、外部リンク...