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

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

Cloud Logging は、現在の Google Cloud プロジェクトのログバケット以外の宛先にログを転送するログシンクのサービス アカウントを自動的に作成し、管理します。複数のプロジェクトのシンクで使用されるサービス アカウントを作成して管理できます。詳細については、ユーザー管理のサービス アカウントでログシンクを構成するをご覧ください。

概要

シンクは、Cloud Logging がログを転送する方法を制御します。シンクを使用すると、ログの一部またはすべてを次の宛先にルーティングできます。

  • Cloud Logging バケット: Cloud Logging のストレージが提供されます。ログバケットには、複数の Google Cloud プロジェクトで受信するログエントリを保存できます。Log Analytics を使用するようにログバケットをアップグレードし、リンクされた BigQuery データセットを作成すると、Cloud Logging データを他のデータと結合できます。ログバケットに保存されているログの表示については、ログのクエリと表示の概要Cloud Logging バケットにルーティングされたログの表示をご覧ください。
  • BigQuery データセット: BigQuery データセットにログエントリのストレージを提供します。保存されたログエントリに対して、ビッグデータ分析機能を使用できます。Cloud Logging のデータを他のデータソースと組み合わせるには、Log Analytics を使用するようにログバケットをアップグレードし、リンクされた BigQuery データセットを作成することをおすすめします。BigQuery にルーティングされたログエントリの表示については、BigQuery にルーティングされたログを表示するをご覧ください。
  • Cloud Storage バケット: Cloud Storage にログエントリのストレージを提供します。ログエントリは、JSON ファイルとして保存されます。 Cloud Storage にルーティングされたログエントリの表示については、Cloud Storage にルーティングされたログを表示するをご覧ください。
  • Pub/Sub トピック: サードパーティ統合をサポートします。ログエントリは JSON 形式にフォーマットされ、Pub/Sub トピックにルーティングされます。Pub/Sub に転送されたログエントリの表示については、Pub/Sub に転送されたログを表示するをご覧ください。
  • Splunk: Splunk のサポートを提供します。Splunkログエントリを Pub/Sub トピックにルーティングし、Splunk を使用してそのトピックをサブスクライブする必要があります。
  • Google Cloud プロジェクト: ログエントリを異なる Google Cloud プロジェクトにルーティングします。ログエントリを別の Google Cloud プロジェクトにルーティングすると、宛先のプロジェクトのログルーターがログエントリを受信して処理します。宛先プロジェクトのシンクは、受信したログエントリのルーティング方法を決定します。 宛先プロジェクトによって所有されているログバケットに宛先プロジェクトがログエントリをルーティングすると、Error Reporting はログエントリを分析できます。
  • その他のリソース: ログエントリを、別のプロジェクト内のサポートされている宛先にルーティングします。使用するパスについては、宛先パスの形式をご覧ください。

シンクは、特定の Google Cloud リソース(Google Cloud プロジェクト、請求先アカウント、フォルダ、組織)に属します。リソースはログエントリを受信すると、そのリソースに含まれるシンクに従ってログエントリを転送します。ログエントリは、一致する各シンクに関連付けられている宛先に送信されます。

集約シンクは、組織やフォルダに含まれる Google Cloud リソース のログエントリを組み合わせてルーティングするシンクの一種です。手順については、組織レベルのログをサポートされている宛先に照合して転送するをご覧ください。

シンクの作成と管理には、Google Cloud コンソール、Cloud Logging API、Google Cloud CLI を使用できます。Google Cloud コンソールを使用すると、他の方法に比べて次のような利点があります。

  • すべてのシンクを 1 か所で表示して管理します。
  • シンクを作成する前に、シンクのフィルタと一致したログエントリを表示します。
  • シンクのシンク先を作成して承認します。

準備

このドキュメントでは、Google Cloud プロジェクト レベルでシンクを作成、管理する方法について説明します。請求先アカウント、フォルダ、組織に対して、集約されていないシンクを作成することもできます。

使用するには、以下の手順を行います。

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

  2. Enable the Cloud Logging API.

    Enable the API

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

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

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

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

    宛先にログをルーティングするには、シンクを作成する前に宛が存在する必要があります。宛先は、どの組織のどの Google Cloud プロジェクトにも作成できます。

    ログを他の宛先にルーティングする際には、なんらかの制限が適用される場合があります。詳しくは、宛先の制限をご覧ください。

シンクを作成する

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

シンクは、Google Cloud プロジェクト 1 つあたり最大 200 個作成できます。

注: シンクを作成したら、シンクの宛先にログを書き込むための適切な権限が Logging に付与されていることを確認してください。エクスポート先の権限を設定するをご覧ください。

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

Console

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

    [ログルーター] に移動

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

  2. 既存の Google Cloud プロジェクトを選択します。

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

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

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

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

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

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

      • Cloud Logging バケット: Logging バケットを選択または作成します。
      • BigQuery データセット: エクスポートされたログを受信する特定のデータセットを選択または作成します。パーティション分割テーブルを使用することもできます。
      • Cloud Storage バケット: エクスポートされたログを受信する特定の Cloud Storage バケットを選択または作成します。
      • Pub/Sub トピック: エクスポートされたログを受信する特定のトピックを選択または作成します。
      • Splunk: Splunk サービスの Pub/Sub トピックを選択します。
      • Google Cloud プロジェクト: エクスポートされたログを受信する Google Cloud プロジェクトを選択または作成します。
      • その他のリソース: 別のプロジェクトにあるサポートされている宛先にログエントリを転送するには、このオプションを選択します。使用するパスについては、宛先パスの形式をご覧ください。
  6. [シンクに含めるログの選択] パネルで、次のようにします。

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

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

      たとえば、すべてのデータアクセス ログを 1 つの Logging バケットにルーティングするようにフィルタを作成できます。このフィルタは次のようになります。

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

      フィルタの長さは 20,000 文字までです。

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

  7. (省略可)[シンクに含めないログの選択] パネルで、次の操作を行います。

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

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

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

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

API

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

    • name: シンクの識別子。シンクを作成した後は、シンクの名前は変更できませんが、シンクを削除して新しいシンクを作成することはできます。
    • destination: ログの転送先となるサービスと宛先。ログを異なるプロジェクト、または別のプロジェクトの宛先にルーティングするには、宛先パスの形式で説明されているとおりに、destination フィールドに適切なパスを設定します。

      たとえば、シンクの宛先が BigQuery データセットの場合、destination は次のようになります。

      bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID
      
  2. LogSink オブジェクトで、適切なオプション情報を指定します。

    • filterfilter プロパティを設定します。フィルタを設定しない場合、Google Cloud プロジェクトからのログはすべて宛先に転送されます。フィルタの長さは 20,000 文字までです。
    • exclusions: シンクから除外するログエントリに一致するように、このプロパティを設定します。sample 関数を使用して、除外するログエントリの部分を選択することもできます。シンクごとに最大 50 個の除外フィルタを作成できます。
    • description: このプロパティは、シンクの目的やユースケースを説明するために設定します。
  3. projects.sinks.create を呼び出してシンクを作成します。

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

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

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

gcloud

シンクを作成するには、次のgcloud logging sinks createコマンドを実行します。

次のように、コマンドの変数に適切な値を指定します。

  • SINK_NAME: シンクの識別子を指定します。シンクを作成した後は、シンクの名前は変更できませんが、シンクを削除して新しいシンクを作成することはできます。
  • SINK_DESTINATION: ログの転送先となるサービスと宛先。ログを異なるプロジェクト、または別のプロジェクトの宛先にルーティングするには、宛先パスの形式で説明されているとおりに、SINK_DESTINATION に適切なパスを設定します。

    たとえば、シンクの宛先が BigQuery データセットの場合、SINK_DESTINATION は次のようになります。

    bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID
    
  • OPTIONAL_FLAGS には、次のフラグがあります。

    • --log-filter: このフラグを使用して、シンクに含めるログエントリに一致するフィルタを設定します。フィルタを設定しない場合、Google Cloud プロジェクトからのログはすべて宛先に転送されます。
    • --exclusion: このフラグを使用して、シンクから除外するログエントリの除外フィルタを設定します。sample 関数を使用して、除外するログエントリの部分を選択することもできます。このフラグは繰り返すことができます。シンクごとに最大 50 個の除外フィルタを作成できます。
    • --description: このフラグは、シンクの目的またはユースケースを説明するために使用します。
gcloud logging sinks create SINK_NAME SINK_DESTINATION OPTIONAL_FLAGS

たとえば、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 リファレンスをご覧ください。

Cloud Storage バケットへの新しいログシンクがログのルーティングを開始するまでに、数時間かかる場合があります。Cloud Storage へのシンクは 1 時間ごとに処理され、他の宛先タイプはリアルタイムで処理されます。

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

シンクの宛先でログを表示する方法については、Cloud Logging バケットにルーティングされるログを表示するをご覧ください。

シンクを作成した後は、logging.googleapis.com/exports/ 指標を使用して受信したログエントリの数と量を表示できます。

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

機密情報をシンクフィルタに入れないでください。シンクフィルタはサービスデータとして扱われます。

宛先パスの形式

別のプロジェクトにある宛先にルーティングする場合は、Logging、BigQuery、Cloud Storage、または Pub/Sub のサービスと宛先の情報を指定する必要があります。

  • ログエントリを別の 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
    

シンクを管理する

シンクを作成したら、シンクに対して次の操作を行うことができます。

  • シンクの詳細を表示する
  • シンクの更新
  • シンクを無効にする
  • シンクを削除
  • シンクのトラブルシューティング
  • シンクログのボリュームとエラー率を表示する

シンクを削除する前に、次の点を考慮してください。

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

シンクに加えたどの変更も、適用されるまで数分かかることがあります。

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

Console

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

    [ログルーター] に移動

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

  2. Google Cloud コンソールの任意の場所からリソース セレクタを使用して、シンクを含む Google Cloud プロジェクトを選択します。

    プルダウン メニューでプロジェクトを選択しているところです。

  3. 集約シンクを表示するには、シンクを含む組織、フォルダ、または請求先アカウントを選択します。

[ログルーター] ページには、シンクのテーブルサマリが含まれています。表の各行には、シンクのプロパティに関する情報が含まれています。

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

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

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

いずれかの列名をクリックすると、昇順または降順でデータを並べ替えることができます。

API

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

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

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

    シンクのエクスポート先、フィルタ、説明は更新できます。シンクを無効または再度有効にすることもできます。

  • シンクを無効にするには、projects.sink.update を呼び出し、disabled プロパティを true に設定します。

    シンクを再度有効にするには、projects.sink.update を呼び出して disabled プロパティを false に設定します。

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

    Logging API を使用してシンクを管理するこれらのメソッドの詳細については、LogSink リファレンスをご覧ください。

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 _Default  --disabled
    

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

    gcloud logging sinks update _Default  --no-disabled
    
  • シンクを削除するには、API メソッド projects.sinks.delete に対応する gcloud logging sinks delete コマンドを使用します。

    gcloud logging sinks delete SINK_NAME
    

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

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

Google Cloud プロジェクトごとに、Logging によって自動的に _Required_Default の 2 つのログバケットが作成されます。Logging は、対応する名前のバケットにログを転送する 2 つのログシンク _Required_Default を自動的に作成します。

_Required シンクは無効にできません。_Default シンクを無効にして、ログの _Default バケットへの保存を停止できます。任意のユーザー定義のシンクを無効にすることもできます。

_Default バケットにログを送信する Google Cloud プロジェクト内のすべてのシンクを無効にすると、そのログバケットに新しいログが保存されなくなります。以前に _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. 各シンクで、[メニュー] を選択し、[シンクを有効にする] を選択します。

API

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

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

  2. たとえば、_Default シンクを無効にするには、projects.sink.update を呼び出し、disabled プロパティを true に設定します。

これで _Default シンクが無効になり、_Default バケットにログがルーティングされなくなりました。

_Default バケットにルーティングしている Google Cloud プロジェクト内の他のシンクを無効にするには、上記の手順を繰り返します。

シンクを再度有効にするには、projects.sink.update を呼び出して disabled プロパティを false に設定します。

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. たとえば、_Default シンクを無効にするには、gcloud logging sinks update コマンドを使用し、--disabled フラグを含めます。

    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

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

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

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

シンクの書き込み ID は、そのシンクに関連付けられているサービス アカウントの識別子です。現在の Google Cloud プロジェクトのログバケットに書き込むシンクを除き、すべてのシンクには書き込み ID があります。シンクのエクスポート先が現在の Google Cloud プロジェクトのログバケットの場合、シンクは追加のエクスポート先の権限を必要としません。したがって、書き込み ID フィールドの値はコンソールに None として表示され、API と Google Cloud CLI のコマンドでは報告されません。

シンクが転送先に転送するように、Google Cloud プロジェクト レベルの権限を設定する手順を以下に示します。Google Cloud プロジェクトではなく、請求先アカウント、フォルダ、または組織も指定できます。

Console

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

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

      [ログルーター] に移動

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

    2. [メニュー] を選択し、[シンクの詳細を表示] を選択します。書き込み ID が [シンクの詳細] パネルに表示されます。

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

  3. シンクの書き込み ID をクリップボードにコピーするには、[コピー] をクリックします。

  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 権限が必要です。
    シンクのエクスポート先へのオーナー アクセス権がない場合は、書き込み ID をプリンシパルとして追加するようにプロジェクト オーナーに依頼します。

API

  1. API メソッド projects.sinks.list を呼び出して、Google Cloud プロジェクト内のシンクを一覧表示します。

  2. 権限を変更するシンクを見つけて、シンクの詳細に "writerIdentity" というラベルの JSON キーが含まれている場合は、次のステップに進みます。詳細に "writerIdentity" フィールドが含まれていない場合は、シンクのエクスポート先の権限を構成する必要はありません。

  3. エクスポート先へのオーナー アクセス権がある場合は、次のようにしてエクスポート先にサービス アカウントを追加します。

    • 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 権限が必要です。
    シンクのエクスポート先へのオーナー アクセス権がない場合は、書き込み ID をプリンシパルとして追加するようにプロジェクト オーナーに依頼します。

gcloud

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

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

    次のステップで SERVICE_ACCT_NAME フィールドの値は書き込み ID であり、次のようになります。

    serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.com
    
  3. エクスポート先へのオーナー アクセス権がある場合は、次のようにしてエクスポート先にサービス アカウントを追加します。

    • 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 権限が必要です。
    シンクのエクスポート先へのオーナー アクセス権がない場合は、書き込み ID をプリンシパルとして追加するようにプロジェクト オーナーに依頼します。

    たとえば、ログ書き込みロール(roles/logging.logWriter)をプロジェクト my-test-project のサービス アカウント service-123456789012@gcp-sa-logging.iam.gserviceaccount.com に付与するには、次のコマンドを実行します。

    gcloud projects add-iam-policy-binding my-test-project --member='serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.com' --role='roles/logging.logWriter'
    

宛先の制限

ログをルーティングする宛先によっては、いくつかの制限が存在する場合があります。

異なる Google Cloud プロジェクトのログバケットにルーティングする

異なる Google Cloud プロジェクトのログバケットにログをルーティングする場合は、次の制限が適用されます。

  • 顧客管理の暗号鍵を使用するログバケットに保存されているログでは、Error Reporting が無効になっています。

異なる Google Cloud プロジェクトにルーティングする

異なる Google Cloud プロジェクトにログをルーティングする場合は、次の制限が適用されます。

  • 1 ホップの制限があります。たとえば、ログエントリをプロジェクト A からプロジェクト B にルーティングしている場合、ログエントリをプロジェクト B から異なるプロジェクトにルーティングできません。

  • 監査ログは、宛先プロジェクトの _Required バケットに転送されません。別のシンクまたはバケットを作成して、それらを保存する必要があります。

  • ルーティングする先の Google Cloud プロジェクトを含む組織またはフォルダに既存の集約シンクがある場合、ログはそれらの集約シンクによってルーティングされません。

コードサンプル

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

フィルタの例

次に、シンクを作成するときに特に役立つフィルタの例をいくつか示します。

包含フィルタと除外フィルタの作成時に役立つその他の例については、サンプルクエリをご覧ください。

_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 のログを除外する

Google Kubernetes Engine のコンテナと GKE システム namespaces の 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コンテナのログの量は、Cloud Monitoring の Metrics Explorer を使用して表示できます。

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

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

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

ログバケットに保存された Dataflow ログの量を表示するには、Cloud Monitoring の 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 ジョブの詳細ページを使用してジョブログを表示できない場合があります。

次のステップ