Cloud Logging で履歴分析を行う

Google Kubernetes Engine（GKE）で Pod が失敗したり、サービスが想定どおりに動作しない場合は、問題につながる一連のイベントを把握することが重要です。現在の状態を検査するだけでは根本原因を特定できない場合があるため、過去のログデータは非常に重要です。

このページでは、Cloud Logging を使用して GKE ログをクエリして分析し、過去の障害（Pod が起動しなかった理由や、重要な Deployment を削除したユーザーなど）を調査する方法について説明します。

この情報は、クラスタ全体の問題の根本原因分析、変更の監査、システム動作の傾向の把握を行う必要があるプラットフォーム管理者とオペレーターにとって重要です。また、アプリケーション デベロッパーがアプリケーション固有のエラーをデバッグしたり、リクエスト パスをトレースしたり、GKE 環境でコードが時間の経過とともにどのように動作するかを把握したりするうえでも不可欠です。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザー ロールとタスクをご覧ください。

トラブルシューティングの主なログタイプについて

トラブルシューティングを支援するため、Cloud Logging は GKE クラスタ、コンテナ化されたアプリ、その他のGoogle Cloud サービスからいくつかの重要なログタイプを自動的に収集して集約します。

  • ノードとランタイムのログ（kubelet、containerd）: 基盤となるノードサービスからのログ。kubelet はノード上のすべての Pod のライフサイクルを管理するため、コンテナの起動、メモリ不足（OOM）イベント、プローブの失敗、ボリュームのマウントエラーなどの問題のトラブルシューティングには、そのログが不可欠です。これらのログは、NotReady ステータスのノードなど、ノードレベルの問題の診断にも不可欠です。

    containerd はイメージの pull など、コンテナのライフサイクルを管理するため、kubelet がコンテナを起動する前に発生する問題のトラブルシューティングには、そのログが不可欠です。containerd ログは、コンテナ ランタイムの特定のアクティビティと潜在的なエラーを記録するため、GKE のノードレベルの問題の診断に役立ちます。

  • アプリログ（stdout、stderr）: コンテナ化されたプロセスからの標準出力ストリームとエラー ストリーム。これらのログは、クラッシュ、エラー、予期しない動作などのアプリ固有の問題をデバッグするうえで不可欠です。

  • 監査ログ: クラスタで「誰が、どこで、いつ、何をしたのか」を把握できます。これらは、Kubernetes API サーバーに対して行われた管理アクションと API 呼び出しを追跡します。これは、構成の変更や不正アクセスによって発生した問題を診断するのに役立ちます。

一般的なトラブルシューティングのシナリオ

問題を特定したら、これらのログに対してクエリを実行して、何が起こったのかを確認できます。作業を開始するにあたって、ログを確認すると、次のような問題の解決に役立ちます。

  • ノードのステータスが NotReady の場合は、ノードログを確認します。kubelet ログと containerd ログには、ネットワークの問題やリソースの制約など、根本原因が示されていることがよくあります。
  • 新しいノードのプロビジョニングとクラスタへの参加に失敗した場合は、ノードのシリアルポート ログを確認します。これらのログは、ノードのロギング エージェントが完全にアクティブになる前の、アーリーブートと kubelet の起動アクティビティをキャプチャします。
  • 過去に Pod の起動に失敗した場合は、その Pod のアプリログを調べて、クラッシュがないか確認します。ログが空の場合や、Pod をスケジュールできない場合は、関連するイベントの監査ログ、またはターゲット ノードのノードログで、リソースの圧迫やイメージの pull エラーの手がかりを探します。
  • 重要な Deployment が削除されたが、その理由が不明な場合は、管理アクティビティ監査ログに対してクエリを実行します。これらのログは、削除 API 呼び出しを発行したユーザーまたはサービス アカウントを特定するのに役立ち、調査の明確な出発点となります。

ログへのアクセス方法

ログ エクスプローラを使用して、 Google Cloud コンソールで GKE ログのクエリ、表示、分析を行います。ログ エクスプローラには、問題の分離に役立つ強力なフィルタリング オプションが用意されています。

ログ エクスプローラにアクセスして使用する手順は次のとおりです。

  1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

    [ログ エクスプローラ] に移動

  2. クエリペインにクエリを入力します。Logging のクエリ言語を使用して、ターゲット クエリを記述します。始めるにあたって、以下に、一般的なフィルタをいくつかご紹介します。

    フィルタの種類 説明 値の例
    resource.type Kubernetes リソースのタイプ。 k8s_cluster、k8s_node、k8s_pod、k8s_container
    log_id リソースからのログストリーム。 stdout、stderr
    resource.labels.RESOURCE_TYPE.name 特定の名を持つリソースをフィルタします。
    は、RESOURCE_TYPE をクエリを実行するリソースの名前に置き換えます。例: namespace、pod など。    		 example-namespace-name、example-pod-name
    severity ログの重大度レベル。 DEFAULT、INFO、WARNING、ERROR、CRITICAL
    jsonPayload.message=~ ログメッセージ内のテキストの正規表現検索。 scale.down.error.failed.to.delete.node.min.size.reached

    たとえば、特定の Pod のトラブルシューティングを行う場合は、そのエラーログを分離することがあります。その Pod の重大度が ERROR のログのみを表示するには、次のクエリを使用します。

    resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
resource.labels.namespace_name="NAMESPACE_NAME"
severity=ERROR

    次のように置き換えます。

    • POD_NAME: 問題が発生している Pod の名前。
    • NAMESPACE_NAME: Pod が存在する Namespace。Namespace がわからない場合は、kubectl get pods コマンドの出力から Namespace 列を確認します。

    他の例については、Google Cloud Observability ドキュメントの Kubernetes 関連のクエリをご覧ください。

  3. [クエリを実行] をクリックします。

  4. JSON ペイロード、メタデータ、タイムスタンプなどの完全なログメッセージを表示するには、ログエントリをクリックします。

GKE ログの詳細については、GKE ログについてをご覧ください。

次のステップ