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

Cloud Logging には、 Cloud Logging API v2: Logging エージェントおよび Logging クライアント ライブラリを操作するためのいくつかのメカニズムが用意されています。 エージェント(Ops エージェントと従来の Logging エージェントの両方)、および Logging クライアント ライブラリは、gRPC Logging API を呼び出します。一部の言語の従来の Logging エージェントとクライアント ライブラリは REST Logging API を呼び出します。

これらのメカニズムの主な違いの 1 つは、Logging API の呼び出し方法です。クライアント ライブラリを使用するアプリケーションは API を直接呼び出しますが、エージェントはアプリケーションのプロキシとして機能します。エージェントを使用している場合は、アプリケーションは確立されたロギング フレームワークを使用してログを出力できます。Google Kubernetes Engine や Container-Optimized OS などのコンテナ環境では、エージェントはデフォルトで stdoutstderr からログを収集します。VM 上でエージェントは、既知のファイルの場所または Windows イベントログ、journald、syslogd などのロギング サービスからログを収集します。

このページでは、クライアント ライブラリとエージェントのどちらを使用して Cloud Logging にログを送信するかを決定する際に役立つ、Logging エージェントとクライアント ライブラリについて説明します。

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

エージェントとクライアント ライブラリのどちらを使用するかを決めるときは、次の点を考慮してください。

アプリケーションは Google Cloud の外部で実行されていますか?

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

オンプレミス システムから Logging にログをルーティングするには、Blue Medora の BindPlane を使用することもできます。

アプリケーションを実行している Google Cloud サービスは、stdoutstderr による自動ログ取り込みをサポートしていますか?

一部の Google Cloud サービスはフルマネージドであるため、エージェントを使用してログをルーティングする必要はありません。Go、Node.js、Python など、選択した言語の任意のロギング フレームワークを使用して、デフォルトで stdoutstderr がサポートされているプロダクトの Logging にログをルーティングできます。クライアント ライブラリを使用せずに stdoutstderr でログを取り込むメリットは、アプリケーションのクラッシュによってログの取り込みが壊れることがないことです。stdoutstderr を使用して構造化ログを取り込む方法については、アプリケーションでログ形式を柔軟に変更できますか?をご覧ください。

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

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

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

stdoutstderr による自動ログ取り込みをサポートしていない 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 エージェントがユースケースに対応できない場合は、従来の Cloud Monitoring エージェントまたはMonitoring クライアント ライブラリを使用して指標を収集します。

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

この質問は、構造化ログを取り込むことができるかどうかを判断するのに役立ちます。Logging に構造化ロギング形式でログを送信すると、Logging は構造化ログを認識します。クライアント ライブラリには、この形式を処理するメソッドが用意されています。

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

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

各オプションの概要

ロギング パターンの図

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

    • 利点

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

      • アプリケーションがクラッシュすると、ログの取得が中断されます。
  • Ops エージェント

    • メリット
      • Ops エージェントは、安定したオープンソース テクノロジーを使用したログと指標の取り込みの両方をサポートします。ログ収集には Fluent Bit、指標収集には OpenTelemetry Collector を使用します。
      • ローカル環境にログを保持できます。
      • アプリケーションのクラッシュからログを復元できる場合があります。
  • 以前の Logging エージェント

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

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