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

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

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

概要

Sinksは、Cloud Logging がログエントリを転送する方法を決定します。シンクを使用すると、ログエントリの一部またはすべてを次の宛先に転送できます。

  • Cloud Logging バケット: Cloud Logging のストレージが提供されます。ログバケットには、複数の Google Cloud プロジェクトで受信するログエントリを保存できます。ログバケットは、ログエントリの元のプロジェクトに配置することも、別のプロジェクトに配置することもできます。ログバケットに保存されているログの表示については、ログのクエリと表示の概要と Cloud Logging バケットにルーティングされたログの表示をご覧ください。

    Cloud Logging データを他のデータと結合するには、ログ分析を使用するようにログバケットをアップグレードし、リンクされたデータセットを作成します。これは、[BigQuery Studio] ページと [Looker Studio] ページでクエリできる読み取り専用のデータセットです。

  • BigQuery データセット: 書き込み可能な BigQuery データセットにログエントリのストレージを提供します。BigQuery データセットは、ログエントリの元のプロジェクトに配置することも、別のプロジェクトに配置することもできます。保存されたログエントリに対して、ビッグデータ分析機能を使用できます。BigQuery にルーティングされたログエントリの表示については、BigQuery にルーティングされたログを表示するをご覧ください。

  • Cloud Storage バケット: Cloud Storage にログエントリのストレージを提供します。 Cloud Storage バケットは、ログエントリの元のプロジェクトに配置することも、別のプロジェクトに配置することもできます。ログエントリは、JSON ファイルとして保存されます。 Cloud Storage にルーティングされたログエントリの表示については、Cloud Storage に転送されたログを表示するをご覧ください。

  • Pub/Sub トピック: サードパーティ統合をサポートします。 ログエントリは JSON 形式にフォーマットされ、Pub/Sub トピックにルーティングされます。トピックは、ログエントリの元のプロジェクトに配置することも、別のプロジェクトに配置することもできます。Pub/Sub に転送されたログエントリの表示については、Pub/Sub に転送されたログを表示するをご覧ください。

  • Google Cloud プロジェクト: ログエントリを別の Google Cloud プロジェクトにルーティングします。この構成では、宛先プロジェクトのシンクによってログエントリが処理されます。

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

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

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

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

始める前に

このドキュメントでは、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 に指定した認証情報を使用します。

      Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init

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

シンクを作成する

Google Cloud プロジェクトでシンクを作成する手順は以下のとおりです。組織、フォルダ、請求先アカウントで発生したログエントリを転送するには、同じ手順を使用します。

  • シンクは、Google Cloud プロジェクト 1 つあたり最大 200 個作成できます。
  • 機密情報をシンクフィルタに入れないでください。シンクフィルタはサービスデータとして扱われます。
  • Cloud Storage バケットへの新しいシンクで、ログエントリのルーティングを開始するまでに数時間かかることがあります。Cloud Storage へのシンクは 1 時間ごとに処理されますが、他の宛先タイプはリアルタイムで処理されます。

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

  • シンクは BigQuery データセットのスキーマを定義しません。 代わりに、BigQuery で最初に受信するログエントリによって宛先テーブルのスキーマが決定されます。詳しくは、ルーティングされたログの BigQuery スキーマをご覧ください。

  • シンクの宛先でログエントリを表示する方法については、Cloud Logging バケットに転送されたログを表示するをご覧ください。

  • 転送されるログエントリの数と量を表示するには、logging.googleapis.com/exports/ 指標を表示します。

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

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

Console

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

    [ログルーター] に移動

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

  2. 転送するログエントリが送信される Google Cloud プロジェクトを選択します。

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

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

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

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

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

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

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

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

    • ログエントリを別の Google Cloud プロジェクトにルーティングするには、[Google Cloud プロジェクト] を選択し、宛先の完全修飾名を入力します。構文については、宛先パスの形式をご覧ください。

    • ログエントリを別の 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 関数を使用して、除外するログエントリの一部を選択することもできます。このオプションは繰り返すことができます。シンクごとに最大 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/PROJECT_ID.DATASET_ID

  • Cloud Storage:

    storage.googleapis.com/BUCKET_NAME

  • Pub/Sub トピック： 

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

シンクを管理する

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

  • 詳細を表示
  • 更新

  • 無効にする

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

  • 削除

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

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

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

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

Console

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

    [ログルーター] に移動

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

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

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

  • 有効: シンクの状態が有効か無効かを示します。
  • タイプ: シンクの宛先サービス（Cloud Logging bucket など）。
  • 名前: シンクの作成時に指定されたシンクの識別子（例: _Default）。
  • 説明: シンクの作成時に指定されたシンクの説明。
  • エクスポート先: 転送されたログエントリを送信する宛先の完全な名前。
  • 作成日: シンクが作成された日時。
  • 最終更新日時: シンクが最後に編集された日時。

表の各行に対して、[その他の操作] メニューには次のオプションがあります。

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

テーブルを列で並べ替えるには、列の名前を選択します。

gcloud

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

    gcloud logging sinks list

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

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

    gcloud logging sinks describe SINK_NAME

  • シンクを更新するには、API メソッド projects.sink.update に対応する gcloud logging sinks 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

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

    gcloud logging sinks update SINK_NAME --disabled

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

    gcloud logging sinks update SINK_NAME --no-disabled

  • シンクを削除するには、API メソッド projects.sinks.delete に対応する gcloud logging 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 プロジェクト シンクを無効にする方法を示します。

Console

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

    [ログルーター] に移動

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

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

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

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

無効になっているシンクを再度有効にして、シンクのエクスポート先へのログエントリのルーティングを再開するには、次の操作を行います。

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

    [ログルーター] に移動

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

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

gcloud

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

    gcloud logging sinks list

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

    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 を呼び出します。

エクスポート先の権限を設定する

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

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

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

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

Console

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

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

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

      [ログルーター] に移動

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

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

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

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

  5. 宛先が別のプロジェクトのサービスである場合、または別のプロジェクトである場合は、ツールバーで宛先プロジェクトを選択します。

  6. サービス アカウントを宛先プロジェクトの IAM プリンシパルとして追加します。

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

      [IAM] に移動

      検索バーを使用してこのページを検索する場合は、小見出しが [IAM と管理者] である結果を選択します。

    2. 宛先プロジェクトを選択します。

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

    4. サービス アカウントに必要な IAM ロールを付与します。

      • Cloud Storage のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、ストレージ オブジェクト作成者のロール（roles/storage.objectCreator）をそれに付与します。
      • BigQuery のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、BigQuery データ編集者のロール（roles/bigquery.dataEditor）をそれに付与します。
      • Splunk を含む Cloud Pub/Sub のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、Pub/Sub パブリッシャーのロール（roles/pubsub.publisher）をそれに付与します。
      • 異なる Google Cloud プロジェクトの Logging バケットのエクスポート先の場合は、IAM を使用して、シンクの書き込み ID をプリンシパルとして追加してから、ログバケット書き込みロール（roles/logging.bucketWriter）をそれに付与します。
      • Google Cloud プロジェクトのエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、ログ書き込みロール（roles/logging.logWriter）をそれに付与します。具体的には、プリンシパルに logging.logEntries.route 権限が必要です。

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. サービス アカウントを宛先プロジェクトの IAM プリンシパルとして追加します。

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

    • PROJECT_ID: プロジェクトの ID。
    • PRINCIPAL: ロールを付与するプリンシパルの識別子。通常、プリンシパル ID の形式は PRINCIPAL-TYPE:ID です。例: user:my-user@example.com。 PRINCIPAL が使用できる形式の一覧については、プリンシパル ID をご覧ください。

    • ROLE: IAM ロール。

      • Cloud Storage のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、ストレージ オブジェクト作成者のロール（roles/storage.objectCreator）をそれに付与します。
      • BigQuery のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、BigQuery データ編集者のロール（roles/bigquery.dataEditor）をそれに付与します。
      • Splunk を含む Cloud Pub/Sub のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、Pub/Sub パブリッシャーのロール（roles/pubsub.publisher）をそれに付与します。
      • 異なる Google Cloud プロジェクトの Logging バケットのエクスポート先の場合は、IAM を使用して、シンクの書き込み ID をプリンシパルとして追加してから、ログバケット書き込みロール（roles/logging.bucketWriter）をそれに付与します。
      • Google Cloud プロジェクトのエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、ログ書き込みロール（roles/logging.logWriter）をそれに付与します。具体的には、プリンシパルに logging.logEntries.route 権限が必要です。

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

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

REST

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

宛先の制限

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

  • ログエントリを別の Google Cloud プロジェクトのログバケットに転送すると、Error Reporting はそれらのログエントリを分析しません。詳細については、Error Reporting の概要をご覧ください。
  • ログエントリを BigQuery に転送する場合は、BigQuery データセットで書き込みが有効になっている必要があります。ログエントリをリンク済みデータセット（読み取り専用）に転送することはできません。

  • ログエントリを別の Google Cloud プロジェクトに転送する場合は、次の制限が適用されます。

    • 1 ホップの上限があります。

      たとえば、ログエントリをプロジェクト A からプロジェクト B に転送する場合、ログエントリをプロジェクト B から別のプロジェクトに転送することはできません。

    • 監査ログが宛先プロジェクトの _Required ログバケットに転送されません。

      たとえば、プロジェクト A からプロジェクト B にログエントリを転送する場合、プロジェクト A の _Required ログバケットにはプロジェクト A の監査ログが含まれます。プロジェクト A の監査ログはプロジェクト B に転送されません。これらのログエントリを転送するには、宛先がログバケットであるシンクを作成します。

    • 宛先プロジェクトが別のフォルダまたは組織にある場合、そのフォルダまたは組織の集約シンクはログエントリをルーティングしません。

      たとえば、プロジェクト A がフォルダ X にあるとします。ログエントリがプロジェクト A で発生した場合、ログエントリはフォルダ X の集約シンクとプロジェクト A のシンクによって処理されます。プロジェクト A に、ログエントリをフォルダ Y にあるプロジェクト B に転送するシンクが含まれているとします。プロジェクト A のログエントリはプロジェクト B のシンクを通りますが、フォルダ Y の集約シンクは通過しません。

  • ログ エクスプローラを使用して、集約シンクを使用してプロジェクトに転送されたログエントリを表示するには、[範囲を絞り込む] フィールドをストレージ スコープに設定し、これらのログエントリにアクセスできるログビューを選択します。

コードサンプル

クライアント ライブラリ コードを使用して選択した言語でシンクを構成するには、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 を使用します。

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

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

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

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

サポート性

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 ジョブの詳細ページを使用してジョブログを表示できない場合があります。

次のステップ