本文へ移動
Telemetry
ドキュメントを見る
ガイド更新日: 2026年7月28日Telemetry 編集チームと製品チームによるレビュー1 最小読み取り時間

コーディング エージェントでこのドキュメントを使用してください

Claude Code、Codex、Cursor、または別のコーディング エージェント用の集中プロンプト パックを開き、それをここで説明するワークフローに適応させます。

このページの内容
  1. トランジションをゲージから分離する
  2. 不安定なワークロードをランク付けする
  3. チャーンではなくインパクトを警告

Kubernetes SQL による信頼性モニタリング

Kubernetes は存続期間の短いオブジェクトを多数作成するため、生の観測値をポッドごとにグループ化すると、ノイズの多いレポートが生成されることがよくあります。ワークロードの境界から開始します。つまり、クラスター、名前空間、デプロイメントまたはジョブの所有者、アプリケーションのリリース、制御された移行、準備の結果、ワークロードが実行する顧客対応の作業です。

トランジションをゲージから分離する

を発する container_restarted 監視された再起動カウンターが増加したときのイベント。累積カウンタをコンテキストとして保持しますが、サンプル間で合計しないでください。準備状況を別のブール値の観察として記録します。計画的なロールアウトでは正常なポッドを置き換えることができますが、クラッシュ ループでは再起動の移行が繰り返され、継続的な Readiness の喪失が発生することがよくあります。

境界のあるクラスター、名前空間、およびワークロード名を使用します。 Kubernetes シークレット、環境変数値、完全なマニフェスト、コンテナ引数、生のログ メッセージ、または顧客ペイロードをイベントにコピーしないでください。

不安定なワークロードをランク付けする

Kubernetes SQL レシピを再起動します ワークロードごとに観測をグループ化し、再起動遷移をカウントし、観測された最大カウンターを保存して、準備完了率を計算します。そのフィクスチャは、遷移カウントと累積的な再起動状態の違いを示しています。

次の順序で結果を調べます。

  1. ロールアウト交換だけでなく、再起動が繰り返されていることを確認します。
  2. 同じ時間帯に準備完了の喪失が発生したかどうかを確認します。
  3. リリース、ノード プール、クラスター、および制御された理由のカテゴリを比較します。
  4. API の障害、ジョブの遅延、またはその他の製品の結果とタイミングを合わせます。

インフラレシピ集 リソースの飽和、ハートビート、インシデントのタイミングが追加されます。これらのシグナルは、アプリケーションの障害と、キャパシティの圧迫やより広範なクラスターの問題とを区別するのに役立ちます。

から始めてください Kubernetes 統合ガイド コレクターとイベントの境界とワークロードと所有者の正規化を構築するとき。

チャーンではなくインパクトを警告

ワークロード ダッシュボードでは、再起動の移行、準備状況、ロールアウト マーカー、およびアプリケーション エラー率をまとめて管理する必要があります。継続的な状態を確認した後にのみページを開きます。 1 つの再スケジュールされたポッドまたは予想されるデプロイメントの置き換えは、通常は実行可能ではありません。

Kubernetes の信頼性の使用例 イベント コントラクトのコーディング エージェント プロンプトを提供します。本番環境への応答にクエリを使用する前に、合成再起動、ロールアウト、リカバリ、および遅延イベントのケースを検証します。

関連製品の機能

構造化イベント テーブルに対して読み取り専用 DataFusion SQL を実行し、結果を再利用します。

所有権と技術リファレンス

Telemetry 編集チームがこの説明を所有しています。製品チームは動作、例、境界をレビューします。

編集基準を見直す