Logging エージェントとクライアント ライブラリのどちらを使用すべきですか？

このドキュメントでは、Cloud Logging にプログラムでアプリケーション ログを送信する際に、クライアント ライブラリまたは Logging エージェントのどちらを使用するか決定するのに役立つ情報を提供します。Logging エージェントは、stdout やファイルなどのファイルに書き込まれたデータをログとして Cloud Logging に送信します。Google Kubernetes Engine、App Engine フレキシブル環境、Cloud Functions などのサービスには、統合された Logging エージェントが含まれています。Compute Engine の場合は、Ops エージェントまたは以前の Cloud Logging エージェントをインストールできます。これらのエージェントは、既知のファイルの場所またはロギング サービス（Windows Event Log、journald、syslogd など）からログを収集します。

クライアント ライブラリまたは Logging エージェントを使用しない場合や、テストのみを行う場合は、gcloud logging write コマンドを使用してログを書き込む方法、または HTTP コマンドを Cloud Logging API エンドポイント entries.write に送信する方法があります。Cloud Logging API は、HTTP 呼び出しと gRPC 呼び出しの両方をサポートしています。Ops エージェントとほとんどの Logging クライアント ライブラリは、gRPC Logging API を呼び出します。以前の Logging エージェント、および一部の言語用のクライアント ライブラリでは、REST Logging API が呼び出されます。

注: 以前の Logging エージェントについては、新機能の開発や新しいオペレーティング システムのサポートは予定されていません。新しいワークロードには Ops エージェントを使用し、最終的には、Ops エージェントを使用するように既存の VM を移行することをおすすめします。

エージェントまたはクライアント ライブラリの選択

エージェントとクライアント ライブラリのどちらかを決める場合は、次の質問を検討してください。

アプリケーションが Google Cloud の外部で実行されているか。

アプリケーションが Google Cloud で実行されていない場合は、Logging API にログを送信する方法が必要です。オンプレミス システムから Logging にログをルーティングするには、observIQ による BindPlane を使用することをおすすめします。BindPlane の詳細については、observIQ と BindPlane についてをご覧ください。

または、クライアント ライブラリを使用して、アプリケーションから直接 Logging にログを転送することもできます。サーバーレス コンピューティングなどのエフェメラル環境では、クライアント ライブラリを使用して Logging API を直接呼び出す必要があります。

アプリケーションを実行している Google Cloud サービスは

プロジェクトへの stdout と stderr のコンテンツの書き込みをサポートしていますか。

一部の Google Cloud サービスはフルマネージドであるため、エージェントを使用して Google Cloud プロジェクトにログを送信する必要はありません。Go、Node.js、Python など、選択した言語の任意の確立したロギング フレームワークを使用して、stdout と stderr がデフォルトでサポートされているプロダクトの Logging にログを送信できます。クライアント ライブラリを使用する代わりに stdout と stderr を使用する利点は、アプリケーションのクラッシュによってプロジェクトへのログの送信が中断されないことです。stdout および stderr による構造化ログの送信については、[アプリケーションでログ形式を柔軟に変更できますか？] セクションをご覧ください。

Logging クライアント ライブラリを使用できますが、必ずしも必要のないローカルテストのための Logging に対して依存関係が生じる可能性があります。クライアント ライブラリを使用する場合は、バッファリングと再試行を明示的に処理するために、より複雑なコーディングが必要になることもあります。また、Logging クライアント ライブラリを使用するたびに API への新しい接続ストリームが作成されます。これらの新しい接続は、複雑さを高め、追加のポートを使用して、アプリケーションからのログのみを含む個別のリクエストを送信します。これは、ログが多くない場合、無駄になる可能性があります。

アプリケーション ログは、ローカル環境でアクセスできる必要がありますか？

ローカル環境でアプリケーション ログにアクセスする必要がある場合、デバッグやその他の目的で、一部の言語でロギング モジュールを使用して stdout と stderr に出力できます。一部の言語の Logging クライアント ライブラリでは、stdout と stderr へのログのルーティングがサポートされています。

stdout と stderr に書き込まれたログの Google Cloud プロジェクトへの自動送信がサポートされていない Google Cloud サービスでアプリケーションを実行する場合は、stdout ログと stderr ログをディスク上のファイルに収集し、これらをスクレイピングし、Logging に送信するようにエージェントを構成できます。詳細については、Ops エージェントまたは以前の Logging エージェントの構成ガイドをご覧ください。

エージェントのインストール プロセスは手動または自動ですか？

一部のサービスでは、エージェントが自動的にインストールされることがあります。また、ユーザーが自分でインストールすることもできます。使用しているサービスでエージェントをインストールできない場合は、クライアント ライブラリを使用して Logging を使用する必要があります。

すでにシステムで Fluentd を実行していますか？

従来の Logging エージェントは Fluentd に基づいています。

システムですでに Fluentd を実行しており、そのデーモンを使用して Logging にログを送信する場合は、fluentd 用の Google Cloud Logging プラグインを使用します。

Cloud Monitoring のアプリケーション指標も収集していますか？

Compute Engine VM では、Ops エージェントがログとほとんどの指標を収集できます。詳細については、Ops エージェントの機能をご覧ください。

Ops エージェントがユースケースに対応できない場合は、従来の Monitoring エージェントまたはMonitoring クライアント ライブラリを使用して指標を収集します。

アプリケーションでログ形式を柔軟に変更できますか？

この質問は、アプリケーションで構造化ログを生成できるかどうかを確定するのに役立ちます。Logging API に構造化ロギング形式でログを送信すると、Logging は構造化ログを認識します。クライアント ライブラリは、この形式を処理するメソッドを提供します。

構造化ログを書き込むには 2　つの方法があります。1　つはLogEntry エンベロープの特定のフィールドを設定することで、もう 1 つはLogEntry エンベロープ内の jsonPayload フィールドを設定することです。前者のスキーマは Cloud Logging によって決定されますが、後者のスキーマはユーザーによって決定されます。

構造化ログを認識するようにエージェントを構成する必要があります。エージェントは、デフォルトで JSON 形式のログを検出し、構造化ログとして処理するように構成されています。アプリケーション自体のログ形式が変更できず、そのログを構造化ログとして認識させる場合は、構造化ロギング形式（通常は JSON）でログを　stdout と stderr に書き込む必要があります。これにより、エージェントはそれらを構造化ログとして認識できます。それ以外の場合は、独自のフォーマットを理解するためにエージェントを構成する必要があります。

各オプションの概要

• Cloud Logging クライアント ライブラリ

  • 利点

    • Cloud Logging API にログを直接ルーティングできます。
    • 一部の言語では、ライブラリを使用してログを stdout と stderr に出力できます。

  • 欠点

    • アプリケーションがクラッシュすると、Google Cloud プロジェクトにログが送信されなくなります。

• Ops エージェント

  • メリット
    • Ops エージェントは、安定したオープンソース テクノロジー（ログ収集用に Fluent Bit、指標収集用に OpenTelemetry Collector）を使用して、ログと指標を送信できます。
    • 多くの一般的なアプリケーションからログと指標の両方を収集できます。サードパーティ アプリケーションからログをモニタリングして収集するをご覧ください。
    • ローカル環境にログを保持できます。
    • アプリケーションのクラッシュからログを復元できる場合があります。
    • Ops エージェントは積極的に開発中です。

• 以前の Logging エージェント

  • メリット
    • エージェントは Fluentd を使用してログを収集します。
    • ローカル環境にログを保持できます。
    • アプリケーションのクラッシュからログを復元できる場合があります。
  • デメリット
    • エージェントは現在サポートされていますが、開発は続いていません。

• Google Cloud プロジェクトに自動的に送信される stdout ログと stderr ログ

  • メリット
    • このプロセスは、ローカル環境にログを出力する一般的な方法です。
    • 任意のロギング ライブラリを使用できます。
    • アプリケーションのクラッシュからログを復元できる場合があります。
  • デメリット
    • すべての環境が Logging にログを自動的にルーティングするわけではありません。