Cloud Monitoring を使用して事前対応型のモニタリングを行う

問題が発生してから対応すると、ダウンタイムが発生する可能性があります。Google Kubernetes Engine（GKE）で復元力のあるシステムを維持するには、ユーザーに影響を与える前に潜在的な問題を特定する必要があります。

このページでは、主要なパフォーマンス指標を追跡し、傾向を可視化し、アラートを設定してエラー率の上昇やリソース制約などの問題を検出することで、Cloud Monitoring を使用して GKE 環境をプロアクティブにモニタリングする方法について説明します。

この情報は、GKE 環境の健全性、信頼性、効率性を確保するプラットフォーム管理者とオペレーターにとって重要です。また、アプリケーション デベロッパーが実際の環境におけるアプリのパフォーマンスを把握し、デプロイ間の回帰を検出し、最適化のための分析情報を取得するのにも役立ちます。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。

有用な指標を確認する

GKE は、一連の指標を Cloud Monitoring に自動的に送信します。以降のセクションでは、トラブルシューティングに最も重要な指標をいくつか示します。

GKE 指標の完全なリストについては、GKE システム指標をご覧ください。

コンテナのパフォーマンスと健全性指標

特定のアプリに問題があると思われる場合は、これらの指標から始めます。これらの指標は、コンテナが頻繁に再起動しているか、メモリ不足になっているか、CPU 制限によってスロットリングされているかなど、アプリの健全性をモニタリングするのに役立ちます。

指標 説明 トラブルシューティングの重要性
kubernetes.io/container/cpu/limit_utilization インスタンスで現在使用されている CPU 上限の割合。コンテナが CPU 上限を超えることが許可されている場合があるため、この値が 1 より大きくなることがあります。 CPU スロットリングを識別します。値が大きいと、パフォーマンスが低下する可能性があります。
kubernetes.io/container/memory/limit_utilization インスタンスで現在使用されているメモリ上限の割合。この値は 1 を超えることはできません。 メモリ不足（OOM）エラーのリスクをモニタリングします。
kubernetes.io/container/memory/used_bytes コンテナが実際に使用したメモリ（バイト単位）。 メモリ使用量を追跡して、メモリリークの可能性や OOM エラーのリスクを特定します。
kubernetes.io/container/memory/page_fault_count メジャーとマイナーのタイプ別に分類したページ フォールトの数の数。 メモリ負荷が高いことを示します。メジャー ページフォルトは、メモリ上限に達していなくても、メモリがディスクから読み取られている（スワッピング）ことを意味します。
kubernetes.io/container/restart_count コンテナが再起動した回数。 再起動の回数が多い、または増加している場合、アプリのクラッシュ、構成ミス、リソースの枯渇などの潜在的な問題をハイライト表示します。
kubernetes.io/container/ephemeral_storage/used_bytes ローカル エフェメラル ストレージの使用量（バイト単位）。 一時ディスクの使用量をモニタリングし、エフェメラル ストレージの容量不足による Pod の強制排除を防ぎます。
kubernetes.io/container/cpu/request_utilization インスタンスでリクエストされ、現在使用されている CPU の割合。使用量がリクエストを超える可能性があるため、この値が 1 より大きくなることがあります。 CPU リクエストのプロビジョニングが過剰または過少になっていることを特定し、リソース割り当ての最適化に役立ちます。
kubernetes.io/container/memory/request_utilization インスタンスでリクエストされ、現在使用されているメモリの割合。使用量がリクエストを超える可能性があるため、この値が 1 より大きくなることがあります。 メモリ リクエストの過剰または過小なプロビジョニングを特定し、スケジューリングを改善して OOM エラーを防止します。

ノードのパフォーマンスと健全性指標

基盤となる GKE インフラストラクチャの問題を診断する必要がある場合は、これらの指標を確認します。これらの指標は、ノードの全体的な健全性と容量を把握するうえで重要です。ノードが異常な状態か、負荷がかかっているか、新しい Pod をスケジュールするのに十分なメモリがあるかどうかを調査するのに役立ちます。

指標 説明 トラブルシューティングの重要性
kubernetes.io/node/cpu/allocatable_utilization インスタンスで現在使用されている割り当て可能な CPU の割合。 Pod の使用量の合計がノードの使用可能な CPU リソースに負荷をかけているかどうかを示します。
kubernetes.io/node/memory/allocatable_utilization インスタンスで割り当て可能であり、現在使用されているメモリの割合。使用量が割り当て可能なメモリのバイト数を超えることはないため、この値が 1 を超えることはできません。 特に値が高い場合、新しい Pod のスケジュール設定や既存の Pod を動作させるためのメモリが不足していることを示します。
kubernetes.io/node/status_condition（ベータ版） ノードのステータス条件フィールドのノードの条件。 Ready、MemoryPressure、DiskPressure などのノードの健全性状態を報告します。
kubernetes.io/node/ephemeral_storage/used_bytes ノードにより使用されるローカル エフェメラル ストレージのバイト数。 エフェメラル ストレージの使用量が多い場合に警告を発行することで、Pod の起動エラーや強制排除を回避できます。
kubernetes.io/node/ephemeral_storage/inodes_free ローカル エフェメラル ストレージ上のインデックス ノード（i ノード）の空き数。 空き i ノードの数をモニタリングします。ディスク容量が使用可能であっても、i ノードが不足するとオペレーションが停止する可能性があります。
kubernetes.io/node/interruption_count（ベータ版） 中断は、お客様がインフラストラクチャを制御している間にインフラストラクチャがシステムによって強制排除されることです。この指標は、タイプと理由別の現在の中断数です。 システムの強制排除が原因でノードが予期せず消える可能性がある理由について説明します。

Pod のパフォーマンスと健全性指標

これらの指標は、ネットワーキングやストレージなど、Pod と環境のインタラクションに関連する問題のトラブルシューティングに役立ちます。これらの指標は、起動が遅い Pod の診断、ネットワーク接続性の問題の調査、ストレージの事前管理によってボリュームの満杯による書き込みエラーの防止を行う必要がある場合に使用します。

指標 説明 トラブルシューティングの重要性
kubernetes.io/pod/network/received_bytes_count ネットワーク経由でポッドにより受信された累積バイト数。 アプリやネットワークの問題を示す可能性がある異常なネットワーク アクティビティ（高または低）を特定します。
kubernetes.io/pod/network/policy_event_count（ベータ版） データプレーンで確認されたネットワーク ポリシー イベント数の変化。 ネットワーク ポリシーが原因で発生した接続性の問題を特定します。
kubernetes.io/pod/volume/utilization インスタンスにより現在使用されているボリュームの割合。使用量が使用可能なボリューム容量の合計を超えることはないため、この値が 1 を超えることはありません。 使用率が高い（1 に近づいている）と書き込みエラーが発生する可能性がある場合に警告を発し、ボリューム スペースのプロアクティブな管理を可能にします。
kubernetes.io/pod/latencies/pod_first_ready（ベータ版） イメージの pull を含む、Pod のエンドツーエンドの起動レイテンシ（Pod の `Created` から `Ready` まで）。 起動が遅い Pod を診断します。

Metrics Explorer で指標を可視化する

GKE 環境の状態を可視化するには、Metrics Explorer で指標に基づいてグラフを作成します。

Metrics Explorer を使用する手順は次のとおりです。

  1. Google Cloud コンソールで、[Metrics Explorer] ページに移動します。

    Metrics Explorer に移動

  2. [指標] フィールドで、検査する指標を選択または入力します。

  3. 結果を表示し、経時的な傾向を確認します。

たとえば、特定の Namespace の Pod のメモリ使用量を調査するには、次の操作を行います。

  1. [指標を選択] リストで、指標 kubernetes.io/container/memory/used_bytes を選択し、[適用] をクリックします。
  2. [フィルタを追加] をクリックし、[namespace_name] を選択します。
  3. [値] リストで、調査する Namespace を選択します。
  4. [集計] フィールドで、[合計] > [pod_name] を選択し、[OK] をクリックします。この設定では、Pod ごとに個別の時系列線が表示されます。
  5. [グラフを保存] をクリックします。

結果のグラフには、各 Pod のメモリ使用量の推移が表示されます。これにより、メモリ消費量が異常に多い Pod や急増している Pod を視覚的に特定できます。

Metrics Explorer では、表示する指標を柔軟に構築できます。Metrics Explorer の詳細オプションの詳細については、Cloud Monitoring ドキュメントの Metrics Explorer でグラフを作成するをご覧ください。

問題の事前検出に関するアラートを作成する

問題が発生した場合や、指標が特定のしきい値を超えた場合に通知を受け取るには、Cloud Monitoring でアラート ポリシーを設定します。

たとえば、コンテナの CPU 上限が 5 分間 80% を超えたときに通知するアラート ポリシーを設定するには、次の操作を行います。

  1. Google Cloud コンソールで、[アラート] ページに移動します。

    アラートに移動

  2. [ポリシーを作成] をクリックします。

  3. [指標を選択] ボックスで CPU limit utilization をフィルタし、次の指標を選択します。kubernetes.io/container/cpu/limit_utilization。

  4. [適用] をクリックします。

  5. [フィルタを追加] フィールドは空白のままにします。この設定では、クラスタがしきい値を超えるとアラートがトリガーされます。

  6. [データの変換] セクションで、次のようにします。

    1. [ローリング ウィンドウ] リストで、[1 分] を選択します。この設定は、 Google Cloud が 1 分ごとに平均値を計算することを意味します。

    2. [ローリング ウィンドウ関数] リストで、[平均] を選択します。

      これらの設定はどちらも、各コンテナの CPU 上限使用率を毎分平均します。

  7. [次へ] をクリックします。

  8. [アラートを構成する] セクションで、次の操作を行います。

    1. [条件タイプ] で [しきい値] を選択します。
    2. [Alert trigger] で [任意の時系列の違反] を選択します。
    3. [しきい値の位置] で [しきい値より上] を選択します。
    4. [しきい値] に「0.8」と入力します。この値は、モニタリングする 80% のしきい値を表します。
    5. [詳細オプション] をクリックします。
    6. [再テスト ウィンドウ] リストで、[5 分] を選択します。この設定は、CPU 使用率が 5 分間継続して 80% を超えた場合にのみアラートがトリガーされることを意味します。これにより、短いスパイクによる誤報が減少します。
    7. [条件名] フィールドに、条件にわかりやすい名前を付けます。
    8. [次へ] をクリックします。

  9. [通知を構成してアラートを確定する] セクションで、次の操作を行います。

    1. [通知チャンネル] リストで、アラートを受信するチャンネルを選択します。チャンネルがない場合は、[通知チャンネルを管理] をクリックして作成します。
    2. [アラート ポリシーの名前を付ける] フィールドに、わかりやすい名前を入力します。
    3. 他のフィールドはデフォルト値のままにしておきます。
    4. [次へ] をクリックします。

  10. ポリシーを確認し、問題がなければ [ポリシーを作成] をクリックします。

アラートを作成するその他の方法については、Cloud Monitoring ドキュメントのアラートの概要をご覧ください。

次のステップ