昨日、Prometheus コースの指導グループのクラスメートが、Prometheus 監視ジョブ タスク (コミュニティ Web サイトに同期済み) の誤報に関する問題について言及しました。一般的な意味は、CronJob によって制御されるジョブは、前の実行が失敗した場合にアラームをトリガーすることです。後で生成された新しいジョブは正常に実行できますが、以前のアラームは引き続き受信されます。 これは、ジョブを実行するときに、トラブルシューティングを容易にするために、通常、いくつかの履歴レコードが保持されるためです。したがって、以前に失敗したジョブがあった場合、後で成功したとしても、以前のジョブは存在し続けます。 kube-prometheus の直接インストールとデプロイメントに使用されるデフォルトのアラーム ルールのほとんどは kube_job_status_failed > 0 であり、これは明らかに不正確です。以前に失敗したジョブを手動で削除することによってのみ、誤報を排除できます。もちろん、この方法で問題は解決できますが、十分に自動化されていません。当初は深く考えず、失敗したジョブを自動的に削除して解決したいと考えていましたが、これでは運用・保守担当者にとっても問題が生じ、戻って問題を解決するのが不便になります。この問題を解決するために考え方を整理してみましょう。 CronJob は、スケジュールされた実行時間ごとに Job オブジェクトを作成します。 .spec.successfulJobsHistoryLimit プロパティと .spec.failedJobsHistoryLimit プロパティを使用して、完了したジョブと失敗したジョブの数を保持できます。デフォルト値はそれぞれ 3 と 1 です。たとえば、次の例では CronJob リソース オブジェクトを宣言しています。 apiバージョン: バッチ/ v1 上記のリソース オブジェクトの仕様によれば、Kubernetes は失敗したジョブと成功したジョブを 1 つだけ保持します。 名前完了期間年齢 上記の誤検知問題を解決するには、Kubernetes API サーバーを監視し、オブジェクトのステータスに関するインジケーターを生成する kube-state-metrics サービスを使用する必要があります。単一の Kubernetes コンポーネントの健全性に焦点を当てるのではなく、デプロイメント、ノード、ジョブ、ポッド、その他のリソース オブジェクトの状態など、さまざまな内部オブジェクトの健全性に焦点を当てます。ここでは次の指標を使用します。
以下は、CronJob によって実行される hello タスクによって生成されたタグを含むメトリックの例です。 kube_job_owner { job_name = "hello-1604875860" 、 namespace = "myNamespace" 、 owner_is_controller = "true" 、 owner_kind = "CronJob" 、 owner_name = "hello" } 1 正確な監視とアラームを確実に行うには、同じ CronJob によってトリガーされたジョブ グループの最後のタスクを取得するだけで済みます。アラームはジョブの実行に失敗した場合にのみトリガーされます。 kube_job_status_failed および kube_job_status_start_time インジケーターには CronJob のラベルが含まれていないため、最初の手順としてこのラベルを追加します。必要なのは、kube_job_owner インジケーターの owner_name です。マージするには、次の promql ステートメントを使用できます。 最大( ここで max 関数を使用するのは、HA のために複数の kube-state-metrics を実行する可能性があるためです。そのため、max 関数を使用して各ジョブ タスクの結果を返します。ジョブ履歴に 2 つのタスク (1 つは失敗、もう 1 つは成功) が含まれていると仮定すると、結果は次のようになります。 { ジョブ名= "hello-1623578940" 、 名前空間= "myNamespace" 、 所有者名= "hello" } 1623578959 各ジョブの所有者がわかったので、最後に実行されたタスクを見つける必要があります。これは、owner_name タグごとに結果を集計することで実行できます。 最大( 上記のステートメントは、各所有者 (つまり、CronJob) の最新のタスク開始時刻を見つけ、それを上記のステートメントとマージして、最後に実行されたジョブ タスクと同じ開始時刻のレコードを保持します。 最大( 結果には、各 CronJob によって最後に実行されたジョブのみが表示されます。 { ジョブ名= "hello-1623578940" 、 名前空間= "myNamespace" 、 所有者名= "hello" } 1623578959 読みやすさを向上させるために、job_name タグと owner_name タグを job と cronjob に置き換えることもできます。これにより、理解しやすくなります。 ラベルの置き換え( 次のような結果が表示されるはずです。 { ジョブ= "hello-1623578940" 、 cronjob = "hello" 、 job_name = "hello-1623578940" 、 namespace = "myNamespace" 、 owner_name = "hello" } 1623578959 上記のクエリステートメントは比較的複雑なので、アラームが評価されるたびにリアルタイム計算を実行すると、Prometheus に大きな負担がかかります。ここでは、記録ルールを使用して同様のオフライン計算方法を実装し、効率を大幅に向上させることができます。各 CronJob の最後に実行されたジョブ レコードを取得するには、次の記録ルールを作成します。 - レコード: ジョブ: kube_job_status_start_time : 最大 CronJob が最近実行を開始したジョブがわかったので、失敗したジョブを除外したい場合は、kube_job_status_failed インジケーターを使用できます。 - レコード: ジョブ: kube_job_status_failed : 合計 ここでは、clamp_max 関数を使用して、job:kube_job_status_start_time:max の結果を、上限が 1 である時系列のセットに変換します。これを使用して、失敗したジョブを乗算でフィルタリングし、最近失敗したジョブ タスクのセットを取得します。また、kube_job_status_failed:sum という名前の記録ルールにも追加します。 最後の手順は、次に示すように、失敗したジョブ タスクにアラーム ルールを直接追加することです。 - アラート: CronJobStatusFailed 誤検知を避けるため、保留中のタスクを除外しました。これまでに、Prometheus による CronJob タスクの監視における誤検知の問題を解決しました。 kube-prometheus には多数の監視アラーム ルールが組み込まれていますが、実際のニーズに適さない場合もあるため、完全に信頼できるわけではありません。 |
<<: 企業がクラウド支出を管理するためのクラウドコスト最適化戦略
>>: クラウド コンピューティングの真の価値を見つける方法を 5 つのステップで説明します。
私は以前、最適化が比較的容易なエンターテイメント サイトに携わっていました。6 月初旬にエンタープラ...
この記事を長い間書きたいと思っていましたが、今日ようやく書き始める時間ができました。今日は主に、We...
気象情報化がなければ、気象の近代化はあり得ません。気象情報化は、「国家気象発展第14次5カ年計画」の...
[原文記事:51CTO.com] 国内の先進的な医薬品流通企業として、ジョインタウンは「テクノロジー...
ウェブサイトの関連性には、コンテンツの関連性とリンクの関連性が含まれます。ウェブサイトの関連性が完璧...
一昨日、「hostdare - 1.79 USD/512M メモリ/30G SSD/1T トラフィッ...
2018年最もホットなプロジェクト:テレマーケティングロボットがあなたの参加を待っていますテンプレー...
インテル コーポレーションの上級副社長であり、デジタル エンタープライズ グループ (DEG) の共...
医療ウェブサイトを運営している友人は、まだランクインはしているがランキングには入っていないのではない...
Racknerd は、米国 4 か所のコンピューター ルーム (ロサンゼルス、ダラス、シカゴ、ニュー...
10 年以上前、Amazon Web Services (AWS) は、柔軟なコンピューティング イ...
11月初旬、Google Sitelinkにヒントを得たBaidu Sitelinkが正式にリリース...
[51CTO.comよりオリジナル記事] 庚子年の初めに新型コロナウイルスが流行し、人々の仕事や生活...
トラフィックと資本配当のピークにより、ソーシャル e コマースの進化は避けられなくなりました。ライブ...
多くのウェブマスターは、SEO は主に外部リンクに関するものだと考えています。実際、近年、外部リンク...