Kubernetes Workload Telemetry: 境界から検証された行まで
制御されたアプリケーション境界で Kubernetes Workload Telemetry を使用し、イベント コントラクトを小さく保ち、集約ビューを構築する前に既知の結果を検証します。
- 1
結果を選択してください
コンテナの再起動分析
- 2
契約を定義する
クラスター、名前空間、ワークロード、ポッド、event_name、および環境
- 3
境界を計測する
レポートを作成する前に、各ポッドをその Deployment、StatefulSet、DaemonSet、または Job owner に解決して、ダッシュボードが有効期間の短い Pod 名にわたって断片化しないようにします。
- 4
証拠を検証する
Exercise a known fixture, then inspect kubernetes_workload_event for one correctly typed terminal row.
始める前に
前提条件と境界
- スコープ内のワークロード ステータス フィールドへの読み取り専用アクセスを持つコレクターまたはコントローラー
- 安定したクラスター、名前空間、ワークロード所有者、およびアプリケーション リリースのラベル
- シークレット、マニフェスト、環境値、生のログ、および顧客ペイロードを除外するリダクション ポリシー
配信設定
サーバー側のインストールと初期化
サーバー専用コードで telemetry-sh をインポートし、process.env.TELEMETRY_API_KEY で一度初期化します。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。
npmのインストール
npm install telemetry-sh- 1制限されたネットワーク動作を持つ再利用可能なサーバー側配信クライアントを 1 つ準備します。
- 2成功、失敗、再試行、またはタイムアウトの境界に結果イベントを追加します。
- 3アラートを有効にする前に、制御されたフィクスチャを送信し、保存されている行を検査します。
スニペット
1 つの構造化されたイベントから始める
ワークフローが完了、失敗、または再試行される場所にこの図形を追加します。次に、実際のフィールドからダッシュボードを構築します。
Kubernetes Workload Telemetryイベント
import telemetry from "telemetry-sh";
export async function logKubernetesWorkloadSample({
cluster,
namespace,
workload,
pod,
restartCount,
ready,
applicationRelease,
previousRestartCount,
}) {
const eventName =
restartCount > previousRestartCount
? "container_restarted"
: "workload_sampled";
await telemetry.log("kubernetes_workload_event", {
cluster,
namespace,
workload,
pod,
event_name: eventName,
restart_count: restartCount,
ready,
application_release: applicationRelease,
environment: "production",
});
}イベント契約
クラスター、名前空間、ワークロード、ポッド、event_name、および環境
restart_count、準備完了、rollout_id、application_release、および observed_generation
ソース値の収集が承認された場合のみ、制限された理由カテゴリ
実装のチェックポイント
チェックポイント 1
レポートを作成する前に、各ポッドをその Deployment、StatefulSet、DaemonSet、または Job owner に解決して、ダッシュボードが有効期間の短い Pod 名にわたって断片化しないようにします。
チェックポイント 2
累積カウンターが増加すると、container_restarted 遷移を発行します。カウンタをコンテキストとして保持し、ゲージ サンプルを合計しないでください。
チェックポイント 3
ページングの前に、繰り返しの再起動と継続的な準備の喪失とアプリケーションの結果を関連付けます。
検証
イベントが到着したことを証明する
既知の成功例と失敗例を実行した後、これを実行します。最終的なイベント コントラクトがスニペットと異なる場合は、フォールバック テーブル名を置き換えます。
Kubernetes Workload Telemetry 検証クエリ
SELECT *
FROM kubernetes_workload_event
ORDER BY timestamp_utc DESC
LIMIT 20;実装の参考資料
新しい運用パスを有効にする前に、イベント契約、データ安全性に関するガイダンス、上流の主要ドキュメントを確認してください。
生産境界
結果イベントを小さく、回復可能なものに保つ
このパターンが提供するのは、
- 上流のワークフローの横にある、制限付きの SQL 対応の結果。
- ダッシュボード、アラート、およびイベント間の相関関係の安定したフィールド。
- 成功、失敗、再試行、タイムアウトの動作を検証するためのフィクスチャ駆動のパス。
このパターンでは提供されません
- OTLP エクスポーター、自動収集パイプライン、または詳細なトレースと診断ログの代替。
- ペイロードにイベント ID が含まれているという理由だけで、1 回だけ配信されます。
- 生のプロバイダー ペイロード、ユーザー コンテンツ、資格情報、または規制されたデータを収集する許可。
イベントスキーマの開始点
このワークフローのイベント コントラクト
クエリまたはスニペットを運用環境に適用する前に、行粒度、出力境界、必要なタイプ、プライバシー クラス、サンプル ペイロード、および検証チェックリストを確認してください。
関連製品の機能
このワークフローを続行します アラート
レビューされた信頼性クエリを、所有するしきい値と応答のワークフローにプロモートします。
関連する SQL レシピ
SQL で次の質問に答えてください
このワークフローの構造化フィールドに対してクエリを実行し、結果の例を検査して、有用な回答をダッシュボードまたはアラートに変換します。
ワークロードごとに Kubernetes 再起動を検索する
どの Kubernetes ワークロードが再起動され、準備チェックに失敗していますか?
レシピを開くホストとコンテナのリソースの飽和状態を確認する
どのインフラストラクチャ ソースが永続的にリソース制限を受けていますか?
レシピを開くインシデントの検出と復旧時間を計算する
各サービスがインシデントを検出して回復するまでにどれくらいの時間がかかりますか?
レシピを開く欠落しているサービスのハートビートを検出する
ハートビートの送信を停止したと予想されるテレメトリ ソースはどれですか?
レシピを開く実装ファミリーごとに参照する
関連する統合パターンを比較する
この統合と組み合わせるテンプレート
さらなる統合
AWS ECS と Fargate Telemetry の統合
ローカル タスク メタデータ エンドポイントを使用して、ECS タスク ファミリー、リビジョン、アベイラビリティ ゾーン、リリース コンテキストをアプリケーションの結果に追加します。
オープンガイドn8n ワークフロー Telemetry
n8n ワークフローの完了、失敗、再試行、項目数、およびダウンストリーム配信結果を、HTTP 要求ノードを介して、制限された Telemetry イベントに送信します。
オープンガイドAWS Lambda 構造化イベント監視
コンパクトな構造化イベントを使用して、Lambda の呼び出し、コールド スタート、期間、再試行、ビジネスの結果を追跡します。
オープンガイド