シンクを構成して管理する

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

概要

シンクは、Cloud Logging がログを転送する方法を制御します。シンクを使用すると、ログの一部またはすべてをサポートされている宛先に転送できます。

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

集約シンクは、組織またはフォルダに含まれる Google Cloud リソースのログエントリを組み合わせてルーティングするシンクです。手順については、集約シンクの構成をご覧ください。

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

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

選択できる宛先

ログを次の宛先に転送できます。

  • Cloud Storage: Cloud Storage バケットに保存される JSON ファイル。
  • Pub/Sub: Pub/Sub トピックに配信される JSON メッセージ。サードパーティによる Logging との統合サービス(Splunk など)をサポートします。
  • BigQuery: BigQuery データセットに作成されるテーブル。
  • 別の Cloud Logging バケット: Cloud Logging ログバケットに保持されるログエントリ。

始める前に

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

開始時点で、以下のことを確認してください。

  • ログ エクスプローラにログを表示する Google Cloud プロジェクトを所有している。

  • ログの転送元となる送信元 Cloud プロジェクトについて、次のいずれかの IAM ロールを付与されている。

    • オーナーroles/owner
    • Logging 管理者roles/logging.admin
    • ログ構成書き込みroles/logging.configWriter

    シンクの作成、削除、変更を行うには、これらのロールに含まれる権限を使用します。IAM ロールの設定については、Logging のアクセス制御ガイドをご覧ください。

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

    シンクを作成する前に、Google Cloud CLI、Google Cloud コンソール、または Google Cloud APIs を使用して転送先を作成する必要があります。転送先はどの組織のどの Cloud プロジェクトにも作成できますが、まず、シンクのサービス アカウントに、転送先への書き込み権限があることを確認する必要があります。

シンクを作成する

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

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

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

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

Console

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

    ログルーターに移動

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

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

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

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

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

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

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

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

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

    global リージョンを使用し、別の Google Cloud プロジェクトで定義されている Cloud Logging ログバケットにログエントリを転送する場合、シンクのエクスポート先は次のようになります。

    logging.googleapis.com/projects/DESTINATION_PROJECT/locations/global/buckets/BUCKET_NAME
    

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

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

    • name: シンクの識別子。シンクを作成した後は、シンクの名前は変更できませんが、シンクを削除して新しいシンクを作成することはできます。
    • destination: ログの転送先となるサービスと宛先。たとえば、シンクの宛先が BigQuery データセットの場合、destination は次のようになります。

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

    • filter: シンクに含めるログエントリに一致するように filter プロパティを設定します。フィルタを設定しない場合、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: ログの転送先となるサービスと宛先。たとえば、シンクの宛先が BigQuery データセットの場合、SINK_DESTINATION は次のようになります。

    bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID
    
  • OPTIONAL_FLAGS には次のフラグが含まれています。

    • --log-filter: このフラグを使用して、シンクに含めるログエントリに一致するフィルタを設定します。フィルタを設定しない場合、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 時間ごとに処理され、他の宛先タイプはリアルタイムで処理されます。

シンクの転送先でログを表示する方法については、転送されたログの検索をご覧ください。

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

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

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

シンクが作成されたプロジェクトとは別の Cloud プロジェクトのエクスポート先にログを転送できます。

そのためには、以下のいずれかを行う必要があります。

  • シンクのサービス アカウントに、宛先に書き込む roles/logging.bucketWriter ロールを付与します。手順については、宛先の権限をご覧ください。

  • ログの送信元の Cloud プロジェクトに対する、次のいずれかの IAM 権限を持っている必要があります。

    • オーナーroles/owner
    • Logging 管理者roles/logging.admin
    • ログ設定書き込み (roles/logging.configWriter)

    宛先の Cloud プロジェクトで新しい Logging バケットを作成する場合は、次の権限のいずれかが必要です。

シンクを管理する

シンクが作成されたら、シンクに対して以下のアクションを実行できます。

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

シンクを削除する場合は、次の点に注意してください。

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

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

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

Console

シンクは、[ログルーター] ページで表示および管理できます。

ログルーターに移動

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

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

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

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

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

表の各行には、メニュー があり、次のオプションを利用できます。

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

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

API

  • 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

  • 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 リファレンスをご覧ください。

ログの取り込みを停止する

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

_Required シンクを無効にすることはできません。取り込み料金もストレージ料金も、_Required ログバケットに保存されたログデータには適用されません。_Default シンクを無効にすると、_Default バケットへのログの取り込みを停止できます。ユーザー定義シンクを無効にすることもできます。

_Default バケットにログを送信する Cloud プロジェクト内のすべてのシンクを無効にして、_Default バケットのログ取り込みを停止すると、その Cloud プロジェクトでは、_Default バケットに対する新しい Cloud Logging の取り込みへの課金が行われなくなります。以前に _Default バケット内に取り込まれたすべてのログがバケットの保持期間に達すると、_Default バケットは空になります。

ログを _Default バケットに転送する Cloud プロジェクト シンクを無効にするには、次の手順を行います。

Console

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

    ログルーターに移動

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

    デフォルトのバケットにログをルーティングするすべてのシンクを検索する

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

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

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

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

    ログルーターに移動

  2. ログを _Default バケットに転送するように構成済みの無効なシンクをすべて検索するには、シンクを宛先でフィルタしてから、「_Default」と入力します。

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

API

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

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

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

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

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

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

gcloud

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

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

Console

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

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

      ログルーターに移動

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

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

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

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

    • Cloud Storage のエクスポート先の場合は、シンクの書き込み ID をバケットに追加し、ストレージのオブジェクト作成者の役割を付与します。
    • BigQuery のエクスポート先の場合は、シンクの書き込み ID をデータセットに追加し、BigQuery データ編集者の役割を付与します。
    • Cloud Pub/Sub の場合は、シンクの書き込み ID をトピックに追加し、Pub/Sub パブリッシャーの役割を付与します。
    • 異なる Cloud プロジェクトの Logging バケットのエクスポート先の場合は、シンクの書き込み ID をエクスポート先のログバケットに追加し、roles/logging.bucketWriter 権限を付与します。

    シンク先へのオーナー アクセス権がない場合は、書き込み ID のサービス アカウント名を、その権限を持つ担当者に送信します。送信された担当者は、前のステップの指示に従って、書き込み ID をエクスポート先に追加する必要があります。

API

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

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

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

    • Cloud Storage のエクスポート先の場合は、シンクの書き込み ID をバケットに追加し、ストレージのオブジェクト作成者の役割を付与します。
    • BigQuery のエクスポート先の場合は、シンクの書き込み ID をデータセットに追加し、BigQuery データ編集者の役割を付与します。
    • Cloud Pub/Sub の場合は、シンクの書き込み ID をトピックに追加し、Pub/Sub パブリッシャーの役割を付与します。
    • 異なる Cloud プロジェクトの Logging バケット宛先の場合は、シンクの書き込み ID をエクスポート先のログバケットに追加し、roles/logging.bucketWriter 権限を付与します。

    シンク先へのオーナー アクセス権がない場合は、書き込み ID のサービス アカウント名を、その権限を持つ担当者に送信します。送信された担当者は、前のステップの指示に従って、書き込み ID をエクスポート先に追加する必要があります。

gcloud

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

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

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

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

    • Cloud Storage のエクスポート先の場合は、シンクの書き込み ID をバケットに追加し、ストレージのオブジェクト作成者の役割を付与します。
    • BigQuery のエクスポート先の場合は、シンクの書き込み ID をデータセットに追加し、BigQuery データ編集者の役割を付与します。
    • Cloud Pub/Sub の場合は、シンクの書き込み ID をトピックに追加し、Pub/Sub パブリッシャーの役割を付与します。
    • 異なる Cloud プロジェクトの Logging バケット宛先の場合は、シンクの書き込み ID をエクスポート先のログバケットに追加し、roles/logging.bucketWriter 権限を付与します。

    シンク先へのオーナー アクセス権がない場合は、書き込み ID のサービス アカウント名を、その権限を持つ担当者に送信します。送信された担当者は、前のステップの指示に従って、書き込み ID をエクスポート先に追加する必要があります。

    たとえば、異なる Cloud プロジェクトの Logging バケット間でログを転送する場合は、次のように roles/logging.bucketWriter をサービス アカウントに追加します。

    1. 宛先プロジェクトの Cloud Identity and Access Management ポリシーを取得し、JSON 形式でローカル ファイルに書き込みます。

      gcloud projects get-iam-policy DESTINATION_PROJECT_ID --format json > output.json
      
    2. 作成した Cloud Logging バケットにのみサービス アカウントによって書き込みが許可される IAM 条件を追加します。次に例を示します。

      {
      "bindings": [
       {
         "members": [
           "user:username@gmail.com"
         ],
         "role": "roles/owner"
       },
       {
         "members": [
           "SERVICE_ACCOUNT"
         ],
         "role": "roles/logging.bucketWriter",
         "condition": {
             "title": "Bucket writer condition example",
             "description": "Grants logging.bucketWriter role to service account SERVICE_ACCOUNT used by log sink [SINK_NAME]",
             "expression":
               "resource.name.endsWith(\'locations/global/buckets/BUCKET_ID\')"
         }
       }
      ],
      "etag": "BwWd_6eERR4=",
      "version": 3
      }
    3. IAM ポリシーを更新します。

      gcloud projects set-iam-policy DESTINATION_PROJECT_ID output.json
      

コードサンプル

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

Cloud Logging に取り込まれた Google Kubernetes Engine のノードPodコンテナのログの量は、Metrics Explorer の Cloud Monitoring を使用して表示できます。

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

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

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

Cloud Logging に取り込まれた Dataflow ログデータの量を表示するには、Cloud Monitoring の Metrics Explorer を使用します。

サポート性

Cloud Logging には、ログを取り込み対象から除外する機能が用意されていますが、サポートに有用なログの保持を検討することをおすすめします。これらのログを使用すると、アプリケーションの問題についてすばやくトラブルシューティングを行い特定できます。

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

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

次のステップ