Kubernetesオブザーバビリティの確保
Kubernetes環境は、コンテナが頻繁に起動・終了する 動的トポロジー であるため、「CPUは何%か」といった状態確認(モニタリング)だけでは問題対応が困難です。「なぜこのPodが再起動されるのか」「なぜこのサービスが遅くなったのか」を追跡できる オブザーバビリティ が必要です。
本ガイドでは、WhaTap Kubernetes Monitoringを用いてCluster・Pod・Serviceの各層をどのように一元的に観察するか、どのメニューをいつ使うかを整理します。
オブザーバビリティの4つのシグナル
Kubernetes環境を理解するには、以下の4種類のデータを 掛け合わせて 確認する必要があります。
| シグナル | 役割 | WhaTapで確認する場所 |
|---|---|---|
| Metric | リソース使用率・数量の変化傾向 | Cluster・Node・Podダッシュボード |
| Trace | サービス間の呼び出しフロー・遅延区間 | トランザクショントレース |
| Log | 時系列の事象ログ | コンテナログ |
| Event | K8s自体のイベント(Pod再起動など) | K8sイベントストリーム |
単一データだけでは原因の特定が難しい場合があります。例えば、PodのCPUスパイク(Metric)を確認したら、同じ時点のTraceでどのリクエストがCPUを使用したか、Logで何の作業だったか、Eventでスケジューリングに変化があったかを併せて確認する必要があります。
WhaTap Kubernetes Monitoringによる統合的な視点
WhaTapは、インフラ (Cluster/Node) → コンテナ (Pod) → アプリケーション (Service) の3つの階層を、1つのプロジェクト内で一元化された視点で提供します。
- Cluster: クラスター全体のリソース・状態のサマリー
- Node: ワーカーノード別のCPU・メモリ・ネットワーク・ディスク
- Pod / Container: コンテナ単位のリソース使用と再起動履歴
- Service (アプリケーション): WAS/アプリAPM連携によるトレース・エラー分析
これにより、インフラ管理者とアプリケーション開発者が同じリアルタイムデータを見ながらコミュニケーション できます。
詳細機能については、Kubernetesモニタリングの紹介 を参照してください。
過去時点の分析も可能
問題が発生した 過去の時点(デプロイ前後、特定の障害時間)のTrace・Metric・Log・Eventを自動的に収集・保存するため、再現することなく当時の状況を振り返ることができます。「昨日の午前3時に発生したPod Evictがなぜ起きたのか」を、いま座って分析できます。
観察シナリオの例
特定のサービスが遅くなった場合
- サービスダッシュボード で応答時間・エラー率の異常を確認してください。
- トランザクショントレース で遅いリクエストのコールスタックを確認してください。DB/外部呼び出しのうちどこがボトルネックかを特定できます。
- 該当Podの コンテナリソース を確認してください。CPU/メモリの枯渇有無を確認できます。
- 同じ時間帯の K8sイベント でPodの再起動・スケジューリングの変化を確認してください。
- 必要に応じて コンテナログ でエラーメッセージを確 認してください。
Podが繰り返し再起動する場合
- K8sイベント で再起動回数・理由(OOMKilled、CrashLoopBackOffなど)を確認してください。
- 再起動前の時点の Podメモリ使用率 と アプリケーションログ をタイムラインに合わせて比較してください。
- トラフィック急増の有無は、上流の サービスダッシュボード で交差確認してください。
次のステップ
- インストール・初期設定 → Kubernetesモニタリングのインストール
- コンテナマップでネットワーク関係を把握 → コンテナマップ
- アプリケーション連携 → Kubernetes + APMの統合観察 (APMの自動インストール)
- GPUワークロードのモニタリング → GPUダッシュボード
- 障害対応ルーチン → 障害対応シナリオ