サポートされている宛先にログをルーティングする

このドキュメントでは、 Google Cloud プロジェクトで発生したログエントリをサポートされている宛先にルーティングするログシンクを作成して管理する方法について説明します。

シンクは書き込みアクションを実行するため、宛先への書き込みが許可されている必要があります。宛先がシンクと同じプロジェクト内のログバケットの場合、シンクは自動的に承認されます。他のすべての宛先では、宛先へのデータの書き込みに必要な権限が付与されているサービス アカウントにシンクを接続する必要があります。

サービス アカウントが必要な場合は、Cloud Logging によって自動的に作成、管理されます。ただし、サービス アカウントに付与される権限の変更が必要になる場合があります。Logging によって作成されたサービス アカウントを使用する必要はありません。複数のプロジェクトのシンクによって使用されるサービス アカウントを作成して管理できます。詳細については、ユーザー管理のサービス アカウントでログシンクを構成するをご覧ください。

概要

このページでは、シンクの作成方法と、 Google Cloud コンソールまたは API の使用時に表示されるオプションの構成方法について説明します。

シンクは、特定の Google Cloud リソース（ Google Cloud プロジェクト、請求先アカウント、フォルダ、組織）に属します。リソースがログエントリを受信すると、そのリソースのすべてのシンクがログエントリを処理します。ログエントリがシンクのフィルタと一致すると、ログエントリはそのシンクの宛先に転送されます。

通常、シンクはリソースで発生したログエントリのみを転送します。フォルダと組織の場合は、フォルダまたは組織で発生したログエントリと、そのフォルダまたは組織に含まれるリソースを転送する集約シンクを作成できます。このドキュメントでは、集約シンクについては説明しません。詳細については、集約シンクの概要をご覧ください。

シンクの作成と管理には、 Google Cloud コンソール、Cloud Logging API、Google Cloud CLI を使用できます。 Google Cloud コンソールの使用をおすすめします。

• [ログルーター] ページには、すべてのシンクと、シンクを管理するためのオプションが表示されます。
• シンクを作成するときに、シンクのフィルタと一致するログエントリをプレビューできます。
• シンクの宛先は、シンクの作成時に構成できます。
• 認可手順の一部は自動的に完了します。

選択できる宛先

シンクの宛先は、シンクとは異なるリソースに配置できます。たとえば、ログシンクを使用して、あるプロジェクトのログを別のプロジェクトに保存されているログバケットにルーティングできます。

次の宛先がサポートされています。

Google Cloud プロジェクト

宛先プロジェクトのログシンクでログエントリを再ルーティングする場合、またはインターセプト集約シンクを作成した場合は、この宛先を選択します。シンクの宛先であるプロジェクトのログシンクは、プロジェクトを除くサポートされている任意の宛先にログエントリを再ルーティングできます。

ログバケット

Cloud Logging によって管理されるリソースにログデータを保存する場合は、この宛先を選択します。ログバケットに保存されているログデータは、ログ エクスプローラやログ分析などのサービスを使用して表示および分析できます。

ログデータを他のビジネスデータと結合する場合は、ログデータをログバケットに保存し、リンクされた BigQuery データセットを作成できます。リンクされたデータセットは読み取り専用のデータセットで、他の BigQuery データセットと同様にクエリできます。

BigQuery データセット

ログデータを他のビジネスデータと結合する場合は、この宛先を選択します。指定するデータセットは書き込み可能である必要があります。シンクの宛先を、リンクされた BigQuery データセットに設定しないでください。リンクされたデータセットは読み取り専用です。

Cloud Storage バケット

ログデータを長期保存する場合は、この宛先を選択します。Cloud Storage バケットは、ログエントリの発生元のプロジェクトに配置することも、別のプロジェクトに配置することもできます。ログエントリは、JSON ファイルとして保存されます。

Pub/Sub トピック

Google Cloud からログデータをエクスポートし、Splunk や Datadog などのサードパーティ統合を使用する場合は、この宛先を選択します。ログエントリは JSON 形式にフォーマットされ、Pub/Sub トピックにルーティングされます。

宛先の制限事項

このセクションでは、宛先固有の制限事項について説明します。

• ログエントリを別の Google Cloud プロジェクトのログバケットに転送する場合、Error Reporting はそれらのログエントリを分析しません。詳細については、Error Reporting の概要をご覧ください。

• ログエントリを BigQuery データセットにルーティングする場合は、BigQuery データセットで書き込みが有効になっている必要があります。リンクされたデータセットは読み取り専用のため、ログエントリをルーティングすることはできません。

• ログデータを Cloud Storage バケットにルーティングする新しいシンクを作成した場合は、ログエントリのルーティングが開始されるまで数時間かかることがあります。これらのシンクは 1 時間ごとに処理されます。

• ログシンクの宛先が Google Cloud プロジェクトの場合、次の制限が適用されます。

  • 1 ホップの上限があります。
  • _Required ログシンクのフィルタに一致するログエントリは、宛先プロジェクトで生成された場合にのみ、宛先プロジェクトの _Required ログバケットにルーティングされます。
  • ログエントリのリソース階層にある集約シンクのみがログエントリを処理します。

  たとえば、プロジェクト A のログシンクの宛先がプロジェクト B である場合、次のようになります。

  • 1 ホップの制限により、プロジェクト B のログシンクはログエントリをプロジェクト Google Cloud に再ルーティングできません。
  • プロジェクト B の _Required ログバケットには、プロジェクト B で発生したログエントリのみが保存されます。このログバケットには、プロジェクト A で発生したログエントリなど、他のリソースで発生したログエントリは保存されません。
  • プロジェクト A とプロジェクト B のリソース階層が異なる場合、プロジェクト A のログシンクがプロジェクト B にルーティングするログエントリは、プロジェクト B のリソース階層の集約シンクに送信されません。
  • プロジェクト A とプロジェクト B に同じリソース階層がある場合、ログエントリはその階層の集約シンクに送信されます。ログエントリが集約シンクによってインターセプトされなかった場合、ログルーターでログエントリがプロジェクト A のシンクに送信されます。

始める前に

このドキュメントでは、Google Cloud プロジェクト レベルでシンクを作成、管理する手順について説明します。組織、フォルダ、請求先アカウントで発生したログエントリを転送するシンクも同じ手順で作成できます。

作業を始める前に、次のことを行います。

1. Enable the Cloud Logging API.

   Enable the API

2. Google Cloud プロジェクトに、ログ エクスプローラで表示できるログエントリがあることを確認します。

3. シンクの作成、変更、削除を行うために必要な権限を取得します。プロジェクトに対するログ構成書き込み（roles/logging.configWriter）IAM ロールを付与するよう管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

   必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

   IAM ロールの付与については、Logging のアクセス制御ガイドをご覧ください。

4. サポート対象の宛先にリソースがあるか、作成できる。

   ログエントリを宛先に転送するには、シンクを作成する前に宛先が存在している必要があります。宛先は、どの組織のどのGoogle Cloud プロジェクトにも作成できます。

5. シンクを作成する前に、シンクの宛先に適用される制限事項を確認します。詳細については、このドキュメントの宛先の制限事項をご覧ください。

6. Select the tab for how you plan to use the samples on this page:

   Console

   When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

   gcloud

   In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

   REST

   このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。

   After installing the Google Cloud CLI, initialize it by running the following command:

   gcloud init

   If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

   詳細については、 Google Cloud 認証ドキュメントの REST を使用して認証するをご覧ください。

   シンクを作成する

   このセクションでは、 Google Cloud プロジェクトにシンクを作成する方法について説明します。1 つの Google Cloud プロジェクトに最大 200 個のシンクを作成できます。転送されるログエントリの数量を確認するには、logging.googleapis.com/exports/ 指標を表示します。

   Logging クエリ言語を使用して、含めるログエントリに一致するフィルタ式を作成します。機密情報はシンクフィルタに記述しないでください。シンクフィルタはサービスデータとして扱われます。

   クエリに複数のステートメントが含まれている場合は、それらのステートメントの結合方法を指定するか、Cloud Logging がステートメント間に結合制約 AND を暗黙的に追加することを許可します。たとえば、クエリまたはフィルタ ダイアログに resource.type = "gce_instance" と severity >= "ERROR" の 2 つのステートメントが含まれているとします。実際のクエリは resource.type = "gce_instance" AND severity >= "ERROR" です。Cloud Logging は、論理和制約（OR）と論理積制約（AND）の両方をサポートしています。OR ステートメントを使用する場合は、句を括弧でグループ化することをおすすめします。

   シンクを作成する方法は次のとおりです。

   コンソール

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

      [ログルーター] に移動

      検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。

   2. ログエントリの転送元の Google Cloud プロジェクトを選択します。

      たとえば、Project-A というプロジェクトから Project-B というプロジェクトのログバケットにデータアクセスのログエントリを転送する場合は、Project-A を選択します。

   3. [シンクを作成] を選択します。

   4. [シンクの詳細] パネルで、次の詳細を入力します。

      • シンクの名前: シンクの識別子を指定します。シンクを作成した後はシンク名を変更できませんが、シンクを削除して新しいシンクを作成することはできます。

      • シンクの説明（省略可）: シンクの目的またはユースケースについて記述します。

   5. [シンクの宛先] パネルで、[シンクサービスの選択] メニューを使用して、シンクのサービスと宛先を選択します。次のいずれかを行います。

      • ログエントリを同じGoogle Cloud プロジェクト内のサービスに転送するには、次のいずれかのオプションを選択します。

        • Cloud Logging バケット: Logging バケットを選択または作成します。
        • BigQuery データセット: 転送されたログエントリを受信する書き込み可能なデータセットを選択または作成します。パーティション分割テーブルを使用することもできます。
        • Cloud Storage バケット: 転送されたログエントリを受信する Cloud Storage バケットを選択または作成します。
        • Pub/Sub トピック: 転送されたログエントリを受信するトピックを選択または作成します。
        • Splunk: Splunk サービスの Pub/Sub トピックを選択します。

      • ログエントリを別の Google Cloud プロジェクトにルーティングする場合は、[Google Cloud プロジェクト] を選択して、宛先の完全修飾名を入力します。

        logging.googleapis.com/projects/DESTINATION_PROJECT_ID
        

      • ログエントリを別のGoogle Cloud プロジェクトのサービスにルーティングするには、次の手順で操作します。

        1. [その他のリソース] を選択します。
        2. 宛先の完全修飾名を入力します。構文については、宛先パスの形式をご覧ください。

   6. 含めるログエントリを指定します。

      1. [シンクに含めるログの選択] パネルに移動します。

      2. [一致フィルタの作成] フィールドに、含めるログエントリに一致するフィルタ式を入力します。フィルタの構文の詳細については、Logging のクエリ言語をご覧ください。

         フィルタを設定しない場合は、選択したリソースのすべてのログエントリが宛先に転送されます。

         たとえば、データアクセスのすべてのログエントリを Logging バケットに転送するには、次のフィルタを使用します。

         log_id("cloudaudit.googleapis.com/data_access") OR log_id("externalaudit.googleapis.com/data_access")
         

         フィルタの長さは 20,000 文字以下にする必要があります。

      3. 正しいフィルタを入力したことを確認するには、[ログをプレビュー] を選択します。フィルタが事前に入力された状態で、ログ エクスプローラが新しいタブで開きます。

   7. （省略可）除外フィルタを構成して、含まれるログエントリの一部を除外します。

      1. [シンクに含めないログの選択] パネルに移動します。

      2. [除外フィルタ名] フィールドに名前を入力します。

      3. [除外フィルタの作成] セクションで、除外するログエントリに一致するフィルタ式を入力します。sample 関数を使用して、除外するログエントリの一部を選択することもできます。

      シンクごとに最大 50 個の除外フィルタを作成できます。フィルタの長さは 20,000 文字以下にする必要があります。

   8. [シンクを作成] を選択します。

   9. シンクのサービス アカウントに、シンクの宛先にログエントリを書き込む権限を付与します。詳細については、宛先の権限を設定するをご覧ください。

   gcloud

   シンクを作成する方法は次のとおりです。

   1. 次の gcloud logging sinks create コマンドを実行します。

      gcloud logging sinks create SINK_NAME SINK_DESTINATION
      

      コマンドを実行する前に、次のように置き換えます。

      • SINK_NAME: ログシンクの名前。シンクの作成後に名前を変更することはできません。

      • SINK_DESTINATION: ログエントリの転送先となるサービスまたはプロジェクト。宛先パスの形式で説明されているように、SINK_DESTINATION に適切なパスを設定します。

        たとえば、シンクの宛先が Pub/Sub トピックの場合、SINK_DESTINATION は次のようになります。

        pubsub.googleapis.com/projects/PROJECT_ID/topics/TOPIC_ID
        

      次のオプションも指定できます。

      • --log-filter: シンクに含めるログエントリに一致するフィルタを設定する場合には、このオプションを使用します。一致フィルタの値を指定しないと、このフィルタはすべてのログエントリと一致します。
      • --exclusion: シンクの転送から除外するログエントリに除外フィルタを設定するには、このオプションを使用します。sample 関数を使用して、除外するログエントリの一部を選択することもできます。このオプションは繰り返すことができますが、1 つのシンクに作成できる除外フィルタは 50 個までです。
      • --description: シンクの目的またはユースケースを記述する場合は、このオプションを使用します。

      たとえば、Logging バケットにシンクを作成する場合、コマンドは次のようになります。

      gcloud logging sinks create my-sink logging.googleapis.com/projects/myproject123/locations/global/buckets/my-bucket \
       --log-filter='logName="projects/myproject123/logs/matched"' --description="My first sink"
      

      Google Cloud CLI を使用してシンクを作成する方法については、gcloud logging sinks リファレンスをご覧ください。

   2. コマンドのレスポンスに "writerIdentity" というラベルの JSON キーが含まれている場合は、シンクのサービス アカウントに、シンクの宛先への書き込み権限を付与します。詳細については、宛先の権限を設定するをご覧ください。

      レスポンスに "writerIdentity" というラベルの JSON キーが含まれていない場合は、宛先の権限を設定する必要はありません。

   REST

   1. Google Cloud プロジェクトにロギングシンクを作成するには、Logging API で projects.sinks.create を使用します。LogSink オブジェクトで、メソッドのリクエストの本文に適切な必須値を指定します。

      • name: シンクの名前。シンクを作成した後にシンク名は変更できませんが、シンクを削除して新しいシンクを作成することはできます。

      • destination: ログエントリの転送先となるサービスと宛先。ログエントリを異なるプロジェクト、または別のプロジェクトの宛先に転送するには、宛先パスの形式で説明されているとおりに、destination フィールドに適切なパスを設定します。

        たとえば、シンクの宛先が Pub/Sub トピックの場合、destination は次のようになります。

        pubsub.googleapis.com/projects/PROJECT_ID/topics/TOPIC_ID
        

   2. LogSink オブジェクトで、適切なオプション情報を指定します。

      • filter: シンクに含めるログエントリに一致するように filter フィールドを設定します。フィルタを設定しない場合、Google Cloud プロジェクトからのすべてのログエントリが宛先に転送されます。フィルタの長さは 20,000 文字以下にする必要があります。
      • exclusions: シンクから除外するログエントリに一致するように、このフィールドを設定します。sample 関数を使用して、除外するログエントリの一部を選択することもできます。シンクごとに最大 50 個の除外フィルタを作成できます。
      • description: シンクの目的やユースケースを記述する場合は、このフィールドを設定します。

   3. projects.sinks.create を呼び出して、シンクを作成します。

   4. API レスポンスに "writerIdentity" というラベルの JSON キーが含まれている場合は、シンクのサービス アカウントに、シンクの宛先への書き込み権限を付与します。詳細については、宛先の権限を設定するをご覧ください。

      API レスポンスに "writerIdentity" というラベルの JSON キーが含まれていない場合は、宛先の権限を設定する必要はありません。

   Logging API を使用してシンクを作成する方法については、LogSink リファレンスをご覧ください。

   エラー通知を受け取った場合は、転送とシンクのトラブルシューティングをご覧ください。

   宛先パスの形式

   ログエントリを別のプロジェクトのサービスに転送する場合は、シンクにサービスの完全修飾名を指定する必要があります。同様に、ログエントリを別の Google Cloud プロジェクトに転送する場合は、宛先プロジェクトの完全修飾名をシンクに指定する必要があります。

   • Cloud Logging ログバケット:

     logging.googleapis.com/projects/DESTINATION_PROJECT_ID/locations/LOCATION/buckets/BUCKET_NAME
     

   • 別の Google Cloud プロジェクト:

     logging.googleapis.com/projects/DESTINATION_PROJECT_ID
     

   • BigQuery データセット:

     bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID
     

   • Cloud Storage:

     storage.googleapis.com/BUCKET_NAME
     

   • Pub/Sub トピック:

     pubsub.googleapis.com/projects/PROJECT_ID/topics/TOPIC_ID
     

   宛先の権限を設定する

   このセクションでは、シンクの宛先にログエントリを書き込むための Identity and Access Management 権限を Logging に付与する方法について説明します。Logging のロールと権限の完全なリストについては、アクセス制御をご覧ください。

   必要なサービス アカウントがすでに存在していない限り、Cloud Logging はシンクの作成時にリソースの共有サービス アカウントを作成します。基盤となるリソース内のすべてのシンクに同じサービス アカウントが使用されるため、サービス アカウントがすでに存在している場合があります。リソースには、 Google Cloud プロジェクト、組織、フォルダ、請求先アカウントがあります。

   シンクの書き込み ID は、そのシンクに関連付けられているサービス アカウントの ID です。ログエントリの発生元の Google Cloud プロジェクトのログバケットに書き込むシンクを除き、すべてのシンクには書き込み ID があります。後者の構成ではサービス アカウントは不要であるため、シンクの [書き込み ID] フィールドはコンソールで「None」と表示されます。API と Google Cloud CLI コマンドは書き込み ID を報告しません。

   次の手順は、プロジェクト、フォルダ、組織、請求先アカウントに適用されます。

   コンソール

   1. 宛先を含むGoogle Cloud プロジェクトに対するオーナー アクセス権があることを確認します。シンクの宛先に対するオーナー権限がない場合は、書き込み ID をプリンシパルとして追加するようプロジェクト オーナーに依頼します。

   2. 新しいシンクからシンクの書き込み ID（メールアドレス）を取得するには、次の操作を行います。

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

         [ログルーター] に移動

         検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。

      2. ツールバーで、シンクを含むプロジェクトを選択します。
      3. [more_vert メニュー] を選択し、[シンクの詳細を表示する] を選択します。[シンクの詳細] パネルに書き込み ID が表示されます。

   3. writerIdentity フィールドの値にメールアドレスが含まれている場合は、次のステップに進みます。値が None の場合、シンクの宛先権限を構成する必要はありません。

   4. シンクの書き込み ID をクリップボードにコピーします。

      メールアドレスはプリンシパルを識別します。接頭辞 serviceAccount: はアカウントの種類を指定します。

   5. シンクの書き込み ID で指定されたプリンシパルに、エクスポート先にログデータを書き込む権限を付与します。

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

         [IAM] に移動

         このページを検索バーで検索する場合は、小見出しが「IAM と管理」の結果を選択します。

      2. ツールバーで、選択したプロジェクトが宛先を保存するプロジェクトか、シンクの宛先であることを確認します。たとえば、宛先がログバケットの場合は、ログバケットを保存するプロジェクトがツールバーに表示されていることを確認します。

      3. [person_addアクセスを許可] をクリックします。

      4. シンクの書き込み ID で指定されたプリンシパルに、ログシンクの宛先に基づいて IAM ロールを付与します。

         • Google Cloud プロジェクト: ログ書き込みのロール（roles/logging.logWriter）を付与します。具体的には、プリンシパルに logging.logEntries.route 権限が必要です。
         • ログバケット: ログバケット書き込みのロール（roles/logging.bucketWriter）を付与します。
         • Cloud Storage バケット: ストレージ オブジェクト作成者のロール（roles/storage.objectCreator）を付与します。
         • BigQuery データセット: BigQuery データ編集者のロール（roles/bigquery.dataEditor）を付与します。
         • Pub/Sub トピック（Splunk を含む）: Pub/Sub パブリッシャーのロール（roles/pubsub.publisher）を付与します。

   gcloud

   1. 宛先を含むGoogle Cloud プロジェクトに対するオーナー アクセス権があることを確認します。シンクの宛先に対するオーナー権限がない場合は、書き込み ID をプリンシパルとして追加するようプロジェクト オーナーに依頼します。

   2. シンク内の writerIdentity フィールドからサービス アカウントを取得します。

      gcloud logging sinks describe SINK_NAME
      

   3. 権限を変更するシンクを探し、シンクの詳細の行に writerIdentity が含まれている場合は、次のステップに進みます。詳細に writerIdentity フィールドが含まれていない場合、シンクの宛先権限を構成する必要はありません。

      サービス アカウントの書き込み ID は次のようになります。

      serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.com
      

   4. gcloud projects add-iam-policy-binding コマンドを呼び出して、エクスポート先にログデータを書き込む権限をシンクの書き込み ID に付与します。

      次のコマンドを使用する前に、次のように置き換えます。

      • PROJECT_ID: プロジェクトの ID。ログシンクの宛先を保存するプロジェクトを指定します。宛先がプロジェクトの場合は、そのプロジェクトを指定します。
      • PRINCIPAL: ロールを付与するプリンシパルの ID。通常、プリンシパル ID の形式は PRINCIPAL-TYPE:ID です。例: user:my-user@example.com PRINCIPAL に使用できる形式の一覧については、プリンシパル ID をご覧ください。

      • ROLE: IAM ロール。ログシンクの宛先に基づいて、シンクの書き込み ID に IAM ロールを付与します。

        • Google Cloud プロジェクト: ログ書き込みのロール（roles/logging.logWriter）を付与します。具体的には、プリンシパルに logging.logEntries.route 権限が必要です。
        • ログバケット: ログバケット書き込みのロール（roles/logging.bucketWriter）を付与します。
        • Cloud Storage バケット: ストレージ オブジェクト作成者のロール（roles/storage.objectCreator）を付与します。
        • BigQuery データセット: BigQuery データ編集者のロール（roles/bigquery.dataEditor）を付与します。
        • Pub/Sub トピック（Splunk を含む）: Pub/Sub パブリッシャーのロール（roles/pubsub.publisher）を付与します。

      gcloud projects add-iam-policy-binding コマンドを実行します。

      gcloud projects add-iam-policy-binding PROJECT_ID --member=PRINCIPAL --role=ROLE
      

   REST

   サービス アカウントにロールを付与する場合は、 Google Cloud コンソールまたは Google Cloud CLI を使用することをおすすめします。

   シンクを管理する

   シンクが作成されたら、シンクに対して次の操作を行うことができます。シンクに加えた変更が適用されるまで数分かかることがあります。

   • 詳細を表示
   • 更新

   • 無効化

     • _Required シンクは無効にできません。
     • _Default シンクを無効にして、_Default Logging バケットにログエントリが転送されないようにすることが可能です。
     • 組織に作成された新しいGoogle Cloud プロジェクトやフォルダで _Default シンクを無効にする場合は、デフォルトのリソース設定を構成することを検討してください。

   • 削除

     • _Default シンクと _Required シンクは削除できません。
     • シンクを削除すると、ログエントリの転送は停止します。
     • シンクに専用のサービス アカウントがある場合、そのシンクを削除すると、サービス アカウントも削除されます。2023 年 5 月 22 日より前に作成されたシンクには、専用のサービス アカウントがあります。2023 年 5 月 22 日以降に作成されたシンクには、共有サービス アカウントがあります。シンクを削除しても、共有サービス アカウントは削除されません。

   • エラーのトラブルシューティング

   • ログのボリュームとエラー率を表示する

   Google Cloud プロジェクトでシンクを管理する手順は次のとおりです。 Google Cloud プロジェクトの代わりに、請求先アカウント、フォルダ、または組織を指定できます。

   コンソール

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

      [ログルーター] に移動

      検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。

   2. ツールバーで、シンクを含むリソースを選択します。リソースには、プロジェクト、フォルダ、組織、請求先アカウントがあります。

   選択したリソースのシンクが [ログルーター] ページに表示されます。表の各行には、シンクのプロパティに関する情報が含まれています。

   • 有効: シンクの状態が有効か無効かを示します。
   • タイプ: シンクの宛先サービス（Cloud Logging bucket など）。
   • 名前: シンクの作成時に指定されたシンクの名前。例: _Default
   • 説明: シンクの作成時に指定されたシンクの説明。
   • 宛先: 転送されたログエントリを送信する宛先の完全な名前。
   • 作成日: シンクが作成された日時。
   • 最終更新日時: シンクが最後に編集された日時。
   • ボリューム: ログシンクにルーティングされたログの合計量を表します。この値には、ログバケット、プロジェクト、その他の宛先にルーティングされたデータ量が含まれます。

   表の各行で [more_vert その他の操作] メニューを使用できます。このメニューでは、次のオプションを選択できます。

   • シンクの詳細を表示する: シンクの名前、説明、宛先のサービス、宛先、一致フィルタと除外フィルタを表示します。[編集] を選択すると、[シンクを編集] パネルが開きます。
   • シンクを編集: [シンクを編集] パネルを表示します。ここでは、シンクのパラメータを更新できます。
   • シンクを無効にする: シンクを無効にし、ログエントリの宛先への転送を停止します。シンクの無効化の詳細については、ログバケットへのログの保存を停止するをご覧ください。
   • シンクを有効にする: 無効になっているシンクを有効にして、シンクの宛先へのログエントリの転送を再開します。
   • シンクを削除: シンクを削除し、シンクの宛先へのログエントリの転送を停止します。
   • シンクのトラブルシューティング: ログ エクスプローラを開きます。ここでは、シンクのエラーをトラブルシューティングできます。
   • シンクログのボリュームとエラー率を表示する: Metrics Explorer を開きます。ここでシンクのデータを確認して、分析できます。

   表を列で並べ替えるには、列名を選択します。

   gcloud

   • Google Cloud プロジェクトのシンクのリストを取得するには、gcloud logging sinks list コマンドを使用します。これは、Logging API メソッド projects.sinks.list に対応しています。

     gcloud logging sinks list
     

     集約シンクのリストを表示するには、適切なオプションを使用して、シンクを含むリソースを指定します。たとえば、シンクを組織レベルで作成した場合は、--organization=ORGANIZATION_ID オプションを使用して組織のシンクを一覧表示します。

   • シンクの説明を取得するには、gcloud logging sinks describe コマンドを使用します。これは、Logging API メソッド projects.sinks.get に対応しています。

     gcloud logging sinks describe SINK_NAME
     

   • シンクを更新するには、gcloud logging sinks update コマンドを使用します。これは、API メソッド projects.sink.update に対応しています。

     シンクを更新して、宛先、フィルタ、説明の変更や、シンクの無効化と再有効化を行うことができます。

     gcloud logging sinks update SINK_NAME NEW_DESTINATION --log-filter=NEW_FILTER

     NEW_DESTINATION や --log-filter の部分に変更がない場合は、それらを省略します。

     たとえば、my-project-sink というシンクの宛先を my-second-gcs-bucket という新しい Cloud Storage バケットの宛先に更新する場合、コマンドは次のようになります。

     gcloud logging sinks update  my-project-sink storage.googleapis.com/my-second-gcs-bucket
     

   • シンクを無効にするには、--disabled オプションを指定して gcloud logging sinks update コマンドを使用します。これは、API メソッド projects.sink.update に対応しています。

     gcloud logging sinks update SINK_NAME --disabled
     

     シンクを再度有効にするには、gcloud logging sinks update コマンドを使用します。--disabled オプションを削除して --no-disabled オプションを指定します。

     gcloud logging sinks update SINK_NAME --no-disabled
     

   • シンクを削除するには、gcloud logging sinks delete コマンドを使用します。これは、API メソッド projects.sinks.delete に対応しています。

     gcloud logging sinks delete SINK_NAME
     

     Google Cloud CLI でシンクを管理する方法については、gcloud logging sinks リファレンスをご覧ください。

   REST

   • Google Cloud プロジェクトのシンクを確認するには、projects.sinks.list を呼び出します。

   • シンクの詳細を表示するには、projects.sinks.get を呼び出します。

   • シンクを更新するには、projects.sink.update を呼び出します。

     シンクの宛先、フィルタ、説明を更新できます。シンクを無効にしたり、再度有効にすることもできます。

   • シンクを無効にするには、LogSink オブジェクトの disabled フィールドを true に設定し、projects.sink.update を呼び出します。

     シンクを再度有効にするには、LogSink オブジェクトの disabled フィールドを false に設定してから、projects.sink.update を呼び出します。

   • シンクを削除するには、projects.sinks.delete を呼び出します。

     Logging API を使用してシンクを管理する方法については、LogSink リファレンスをご覧ください。

   ログバケットへのログエントリの保存を停止する

   _Default シンクとユーザー定義のシンクは無効にできます。シンクを無効にすると、ログエントリの宛先への転送を停止します。たとえば、_Default シンクを無効にすると、ログエントリは _Default バケットに転送されなくなります。以前に保存されたログエントリがすべてバケットの保持期間に達すると、_Default バケットは空になります。

   次の手順では、ログエントリを _Default ログバケットに転送する Google Cloud プロジェクト シンクを無効にする方法について説明します。

   コンソール

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

      [ログルーター] に移動

      検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。

   2. ログエントリを _Default ログバケットに転送するすべてのシンクを確認するには、シンクを宛先でフィルタし、「_Default」と入力します。

   3. 各シンクの [more_vert メニュー] を選択して、[シンクを無効にする] を選択します。

      シンクが無効になり、 Google Cloud プロジェクト シンクがログエントリを _Default バケットに転送しなくなります。

   無効になっているシンクを再度有効にして、ログエントリが再びシンクの宛先に転送されるようにするには、次の操作を行います。

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

      [ログルーター] に移動

      検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。

   2. ログエントリを _Default ログバケットに転送するすべてのシンクを確認するには、シンクを宛先でフィルタし、「_Default」と入力します。
   3. 各シンクの [more_vert メニュー] を選択して、[シンクを有効にする] を選択します。

   gcloud

   1. Google Cloud プロジェクトのシンクのリストを取得するには、gcloud logging sinks list コマンドを使用します。これは、Logging API メソッド projects.sinks.list に対応しています。

      gcloud logging sinks list
      

   2. _Default ログバケットに転送しているシンクを特定します。宛先の名前などのシンクの説明を取得するには、gcloud logging sinks describe コマンドを使用します。これは、Logging API のメソッド projects.sinks.get に対応しています。

      gcloud logging sinks describe SINK_NAME
      

   3. --disabled オプションを指定して gcloud logging sinks update コマンドを実行します。たとえば、_Default シンクを無効にするには、次のコマンドを使用します。

      gcloud logging sinks update _Default  --disabled
      

      これで _Default シンクが無効になり、ログエントリが _Default ログバケットに転送されなくなりました。

   _Default バケットに転送している Google Cloud プロジェクト内の他のシンクを無効にするには、前の手順を繰り返します。

   シンクを再度有効にするには、gcloud logging sinks update コマンドを使用します。--disabled オプションを削除して --no-disabled オプションを指定します。

   gcloud logging sinks update _Default  --no-disabled
   

   REST

   1. Google Cloud プロジェクトのシンクを確認するには、Logging API メソッド projects.sinks.list を呼び出します。

      _Default バケットに転送しているシンクを特定します。

   2. たとえば、_Default シンクを無効にするには、LogSink オブジェクトの disabled フィールドを true に設定してから、projects.sink.update を呼び出します。

      これで _Default シンクが無効になり、ログエントリが _Default バケットに転送されなくなりました。

   _Default バケットに転送している Google Cloud プロジェクト内の他のシンクを無効にするには、前の手順を繰り返します。

   シンクを再度有効にするには、LogSink オブジェクトの disabled フィールドを false に設定し、projects.sink.update を呼び出します。

   コードサンプル

   クライアント ライブラリ コードに構成した言語でシンクを構成するには、Logging クライアント ライブラリ: ログシンクをご覧ください。

   フィルタの例

   次に、シンクの作成時に特に役立つフィルタの例をいくつか示します。一致フィルタと除外フィルタの作成時に役立つその他の例については、サンプルクエリをご覧ください。

   _Default シンクフィルタを復元する

   _Default シンクのフィルタを編集した場合は、このシンクの構成を元に戻すことをおすすめします。作成時に、_Default シンクは次の一致フィルタと空の除外フィルタで構成されます。

     NOT log_id("cloudaudit.googleapis.com/activity") AND NOT \
     log_id("externalaudit.googleapis.com/activity") AND NOT \
     log_id("cloudaudit.googleapis.com/system_event") AND NOT \
     log_id("externalaudit.googleapis.com/system_event") AND NOT \
     log_id("cloudaudit.googleapis.com/access_transparency") AND NOT \
     log_id("externalaudit.googleapis.com/access_transparency")
   

   Google Kubernetes Engine コンテナと Pod のログを除外する

   GKE システム namespaces の Google Kubernetes Engine コンテナと Pod のログエントリを除外するには、次のフィルタを使用します。

   resource.type = ("k8s_container" OR "k8s_pod")
   resource.labels.namespace_name = (
   "cnrm-system" OR
   "config-management-system" OR
   "gatekeeper-system" OR
   "gke-connect" OR
   "gke-system" OR
   "istio-system" OR
   "knative-serving" OR
   "monitoring-system" OR
   "kube-system")
   

   GKE システム logNames の Google Kubernetes Engine ノードのログエントリを除外するには、次のフィルタを使用します。

   resource.type = "k8s_node"
   logName:( "logs/container-runtime" OR
   "logs/docker" OR
   "logs/kube-container-runtime-monitor" OR
   "logs/kube-logrotate" OR
   "logs/kube-node-configuration" OR
   "logs/kube-node-installation" OR
   "logs/kubelet" OR
   "logs/kubelet-monitor" OR
   "logs/node-journal" OR
   "logs/node-problem-detector")
   

   ログバケットに保存されている Google Kubernetes Engine のノード、Pod、コンテナのログエントリの量を確認するには、Metrics Explorer を使用します。

   • ノードのログエントリのボリュームを確認する
   • Pod のログエントリのボリュームを確認する
   • コンテナのログエントリのボリュームを確認する

   サポート性に不要な Dataflow ログを除外する

   サポート性に不要な Dataflow ログエントリを除外するには、次のフィルタを使用します。

   resource.type="dataflow_step"
   labels."dataflow.googleapis.com/log_type"!="system" AND labels."dataflow.googleapis.com/log_type"!="supportability"
   

   ログバケットに保存された Dataflow ログの量を確認するには、Metrics Explorer を使用します。

   • Dataflow ログエントリの量を確認する

   サポート性

   Cloud Logging では、ログエントリを除外してログバケットへの保存を防ぐことができますが、サポートに役立つログエントリについては保持することを検討してください。これらのログエントリは、アプリケーションの問題のトラブルシューティングと特定に役立ちます。

   たとえば、GKE システムのログエントリは、クラスタで発生したイベントに対して生成されるため、GKE アプリケーションとクラスタのトラブルシューティングに役立ちます。これらのログエントリは、アプリケーション コードまたは基盤となる GKE クラスタがアプリケーション エラーの原因かどうかを特定するうえで役立ちます。GKE システムログには、Kubernetes API Server コンポーネントによって生成された Kubernetes 監査ロギングも含まれます。このログには、kubectl コマンドと Kubernetes イベントを使用して行われた変更が含まれます。

   Dataflow の場合は、少なくともシステムログ（labels."dataflow.googleapis.com/log_type"="system"）とサポートログ（labels."dataflow.googleapis.com/log_type"="supportability"）をログバケットに書き込むことをおすすめします。これらのログは、デベロッパーが Dataflow パイプラインを監視し、トラブルシューティングを実施するのに不可欠ですが、Dataflow の [ジョブの詳細] ページにジョブログが表示されない場合があります。

   次のステップ

   • シンクを使用してログエントリを転送する際に問題が発生した場合は、ログの転送に関するトラブルシューティングをご覧ください。

   • 宛先でログを表示する方法と、ログエントリをフォーマットして整理する方法については、シンクの宛先でログを表示するで確認してください。

   • Logging のクエリ言語によるクエリとフィルタリングの詳細については、Logging のクエリ言語をご覧ください。

   フィードバックを送信