管理ツール

Cloud Logging で GKE ログを検索して使用する方法

※この投稿は米国時間 2020 年 6 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

ログはトラブルシューティングの重要な部分であり、必要なときにログを使用できることが大切です。ロギングに関しては、Google Kubernetes Engine(GKE)が Google Cloud の Logging サービスと統合されています。ですが、おそらく皆さんは GKE ログや Cloud Logging を詳細に調べたことがないのではないでしょうか。ここでは、GKE でのロギングの仕組みと、Cloud Logging に保存される GKE ログの構成方法、検索方法、効果的な操作方法について概要をご紹介します。

GKE ログが Cloud Logging に送信される仕組み

GKE クラスタで実行されている、コンテナ化されたコード(コードまたはパッケージ済みのソフトウェア)は通常、さまざまなログを生成します。これらのログは一般的に標準出力(「stdout」)と標準エラー「stderr」に書き込まれ、エラー、情報、デバッグのメッセージを含みます。 

Google Cloud に新しい GKE クラスタを設定すると、システムログとアプリログはデフォルトで有効になります。専用エージェントは GKE ノードに自動的にデプロイされて管理され、ログを収集し、コンテナ、ポッド、クラスタに関する有用なメタデータを追加して、ログを Cloud Logging に送信します。次に、システムログとアプリログがともに Cloud Logging に取り込まれ、保存されます。追加の構成は必要ありません。 

Cloud Logging で GKE ログを検索する

こうしたログを Cloud Logging サービスで検索するには、このリンクをクリックするか、ログビューアで次のクエリを実行して、GKE 関連の Kubernetes リソースでログをフィルタします。 

resource.type=("k8s_container" OR "container" OR "k8s_cluster" OR "gke_cluster" OR "gke_nodepool" OR "k8s_node") 

log viewers.jpg

このクエリは GKE の Kubernetes リソース(クラスタ、ノード、ポッド、コンテナ)に関連するログを表示します。または、GKE クラスタ内で任意のワークロードにアクセスし、デプロイメント、ポッド、コンテナの詳細でコンテナログのリンクをクリックすることで、Cloud Logging コンソールでログを直接表示することもできます。 

Cloud Logging console.gif

クエリでログエントリが返されない場合、ログが生成されない原因や、Cloud Logging に収集されない原因を探す必要があります。  

GKE ログが収集されていることを確認する

前述のように、GKE クラスタを作成すると、システムログとアプリログはデフォルトで収集されるように設定されます。ログ収集の構成方法を更新するには、クラスタを作成するかクラスタ構成を更新します。 

Cloud Logging でログが一切表示されない場合、GKE と Cloud Logging の統合が適切に有効になっているかをご確認ください。クラスタ構成のステータスを確認するには、こちらの手順に沿って操作してください。 

test cluster.jpg

GKE 統合が有効になっていない場合、クラスタのログ収集を有効にするには、Google Cloud Console でクラスタを編集するか、gcloud container clusters update コマンドラインを使用します。

Cloud Logging および Cloud Monitoring との GKE 統合を有効にしても GKE ログが一切表示されない場合は、ログが除外されていないかをご確認ください。ログの除外の追加により、すべてまたは特定の GKE ログが Cloud Logging に取り込まれないようにログが除外されている可能性があります。これらの除外を調整することで、必要な GKE ログを Cloud Logging に取り込めます。 

GKE バージョン 1.15.7 以降は、システムログのみをキャプチャするように GKE クラスタを構成できます。Cloud Logging および Cloud Monitoring との GKE 統合を有効にしても Cloud Logging にシステムログしか表示されない場合は、このオプションが選択されていることをご確認ください。アプリログの収集が有効か無効かを確認した上で有効にするには、こちらの手順に沿って操作してください。 

GKE ログをより効果的に

構造化ログを利用すると、より効果的なクエリを作成できます。Cloud Logging では、ログを構造化すると、JSON オブジェクトが解析され、アプリケーションの JSON メッセージのクエリが作成しやすくなります。JSON オブジェクトがログメッセージに含まれている場合、GKE は構造をログメッセージに自動的に追加します。デベロッパーは、JSON オブジェクトに特定の要素を追加して Cloud Logging に保存する際に、Cloud Logging で対応するフィールドに自動的にマッピングすることもできます。これは、ログメッセージの重大度、トレース ID、ラベルを設定するのに有用な場合があります。

トレースをログメッセージと組み合わせて使用することも、アプリの状態とパフォーマンスをモニタリングし維持するための一般的な方法です。トレースはアプリケーション内のすべてのトランザクションに価値あるコンテキストを提供するため、特に分散アプリケーションの場合にトラブルシューティング作業の効率が大幅に改善されます。Cloud Trace(または他のトレース ソリューション)を使用して分散アプリケーションのトレースをモニタリングする場合、ログをより便利にする別の方法は、ログメッセージにトレース ID を含めることです。この接続を使用すると、アプリのトラブルシューティング時に、ログメッセージから Cloud Trace に直接リンクできます。

GKE ログの使用量を削減する 

GKE はシステムログとアプリログの両方を生成します。大量のログは便利ではあるものの、想定を超えてしまう場合があります。たとえば、ノード上の kublet ログをはじめ、Kubernetes によって生成される特定のログメッセージは、情報過多で繰り返しばかりの可能性があります。こうしたログは、トラブルシューティング向けに本番環境クラスタを運用している場合に有効ですが、開発のみの環境での有効性は低いかもしれません。ログが多すぎると思われる場合は、特定のフィルタとともにログの除外を利用して、使わないログメッセージを除外できます。ただし、ログは問題のトラブルシューティングを行うときになって初めて必要になることが多いので、ログの除外については慎重に検討してください。ログの繰り返しを部分的に除外(または特定の割合のログを除外)すると、ノイズを軽減できます。 

Cloud Logging は、Kubernetes が生成するさまざまなログを理解する助けになります。GKE アプリで Cloud Logging を使用する方法については、ブログ投稿をご覧ください。

- By プロダクト マネージャー Rami Shalom、Charles Baer