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

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

概要

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

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

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

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

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

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

始める前に

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

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

ログエクスプローラにログを表示する Google Cloud プロジェクトを所有している。
シンクを作成、変更、削除するには、ログのルーティング元の Google Cloud プロジェクトに対して、次のいずれかの Identity and Access Management ロールが必要です。
- ログ構成書き込み（roles/logging.configWriter）
- Logging 管理者（roles/logging.admin）
- オーナー（roles/owner）
IAM ロールの付与については、Logging のアクセス制御ガイドをご覧ください。
サポート対象の宛先にリソースがあるか、作成できる。

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

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

シンクを作成する

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

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

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

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

Console

Google Cloud コンソールのナビゲーションメニューで [ロギング] を選択し、[ログルーター] をクリックします。
[ログルーター] に移動
既存の Google Cloud プロジェクトを選択します。
[シンクを作成] を選択します。
[シンクの詳細] パネルで、次の詳細を入力します。
- シンク名: シンクの識別子を指定します。シンクを作成した後は、シンクの名前は変更できませんが、シンクを削除して新しいシンクを作成することはできます。
- シンクの説明（省略可）: シンクの目的またはユースケースについて説明します。
[シンクの宛先] パネルで、[シンクサービスを選択] メニューを使用して、シンクのサービスと宛先を選択します。
1. 同じ Google Cloud プロジェクトにあるサービスにログをルーティングするには、次のいずれかのオプションを選択します。
  - Cloud Logging バケット: Logging バケットを選択または作成します。
  - BigQuery テーブル: エクスポートされたログを受信する特定のデータセットを選択または作成します。パーティション分割テーブルを使用することもできます。
  - Cloud Storage バケット: エクスポートされたログを受信する特定の Cloud Storage バケットを選択または作成します。
  - Pub/Sub トピック: エクスポートされたログを受信する特定のトピックを選択または作成します。
  - Splunk: Splunk サービスの Pub/Sub トピックを選択します。
  - （プレビュー）その他のプロジェクト: 宛先パスの形式で説明されているとおりに、[シンクの宛先] フィールドに入力します。
[シンクに含めるログの選択] パネルで、次のようにします。
1. [包含フィルタの作成] フィールドに、含めるログエントリに一致するフィルタ式を入力します。フィルタを作成する構文の詳細については、Logging のクエリ言語をご覧ください。
  
  フィルタを設定しない場合は、選択したリソースのすべてのログが宛先に転送されます。
  
  たとえば、すべてのデータアクセスログを 1 つの Logging バケットにルーティングするようにフィルタを作成できます。このフィルタは次のようになります。
```
LOG_ID("cloudaudit.googleapis.com/data_access") OR LOG_ID("externalaudit.googleapis.com/data_access")
```
  フィルタの長さは 20,000 文字までです。
2. 正しいフィルタを入力したことを確認するには、[ログをプレビュー] を選択します。フィルタが事前に入力された状態で、ログエクスプローラが新しいタブで開きます。
（省略可）[シンクに含めないログの選択] パネルで、次の操作を行います。
1. [除外フィルタの名前] フィールドに名前を入力します。
2. [除外フィルタの作成] セクションで、除外するログエントリに一致するフィルタ式を入力します。sample 関数を使用して、除外するログエントリの一部を選択することもできます。
  
  重要なポイント: シンクの作成時に除外フィルタを無効にする場合は、フィルタ式を入力した後 [無効にする] を選択します。除外フィルタは、後でシンクを更新して有効にできます。
シンクごとに最大 50 個の除外フィルタを作成できます。フィルタの長さは 20,000 文字までです。
[シンクを作成] を選択します。

API

Google Cloud プロジェクトにログシンクを作成するには、Logging API の projects.sinks.create を使用します。LogSink オブジェクトで、メソッドリクエストの本文に必要な適切な値を指定します。
- name: シンクの識別子。シンクを作成した後は、シンクの名前は変更できませんが、シンクを削除して新しいシンクを作成することはできます。
- destination: ログの転送先となるサービスと宛先。ログを異なるプロジェクト、または別のプロジェクトの宛先にルーティングするには、宛先パスの形式で説明されているとおりに、destination フィールドに適切なパスを設定します。
  
  たとえば、シンクの宛先が BigQuery データセットの場合、destination は次のようになります。
```
bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID
```
LogSink オブジェクトで、適切なオプション情報を入力します。
- filter: シンクに含めるログエントリに一致するように filter プロパティを設定します。フィルタを設定しない場合、Google Cloud プロジェクトからのログはすべて宛先に転送されます。フィルタの長さは 20,000 文字までです。
- exclusions: シンクから除外するログエントリに一致するようにこのプロパティを設定します。sample 関数を使用して、除外するログエントリの一部を選択することもできます。シンクごとに最大 50 個の除外フィルタを作成できます。
- description: このプロパティは、シンクの目的やユースケースを説明するために設定します。
projects.sinks.create を呼び出してシンクを作成します。
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
```
ログエントリを別の 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
```
ログエントリを 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 プロジェクトではなく、請求先アカウント、フォルダ、または組織も指定できます。

コンソール

Google Cloud コンソールのナビゲーションメニューで [ロギング] を選択し、[ログルーター] をクリックします。
[ログルーター] に移動
Google Cloud コンソールの任意の場所からリソースセレクタを使用して、シンクを含む Google Cloud プロジェクトを選択します。
集約シンクを表示するには、シンクを含む組織、フォルダ、または請求先アカウントを選択します。

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

有効: シンクの状態が有効か無効かを示します。
タイプ: シンクの宛先サービス（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 シンクを無効にすることはできません。取り込み料金もストレージ料金も、_Required ログバケットに保存されたログデータには適用されません。_Default シンクを無効にすると、_Default バケットへのログの取り込みを停止できます。任意のユーザー定義のシンクを無効にすることもできます。

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

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

コンソール

Google Cloud コンソールのナビゲーションメニューで [ロギング] を選択し、[ログルーター] をクリックします。
[ログルーター] に移動
ログを _Default バケットにルーティングするすべてのシンクを見つけるには、エクスポート先でシンクをフィルタし、「_Default」と入力します。
各シンクで、[メニュー] を選択し、[シンクを無効にする] を選択します。

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

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

Google Cloud コンソールのナビゲーションメニューで [ロギング] を選択し、[ログルーター] をクリックします。
[ログルーター] に移動
ログを _Default バケットに転送するように構成済みの無効なシンクをすべて検索するには、シンクを宛先でフィルタしてから、「_Default」と入力します。
各シンクで、[メニュー] を選択し、[シンクを有効にする] を選択します。

API

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

_Default バケットに転送されているシンクを特定します。
たとえば、_Default シンクを無効にするには、projects.sink.update を呼び出し、disabled プロパティを true に設定します。

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

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

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

gcloud

Google Cloud プロジェクトのシンクのリストを表示するには、gcloud logging sinks listコマンド。Logging API メソッドに対応しています。projects.sinks.list:
```
gcloud logging sinks list
```
_Default バケットに転送されているシンクを特定します。宛先の名前を表示する場合などに、シンクを記述するには、Logging API のメソッド projects.sinks.get に対応する gcloud logging sinks describe コマンドを使用します。
```
gcloud logging sinks describe SINK_NAME
```
たとえば、_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 プロジェクトではなく、請求先アカウント、フォルダ、または組織も指定できます。

コンソール

シンクの書き込み ID（メールアドレス）を新しいシンクから取得するには、次の手順を行います。
1. Google Cloud コンソールのナビゲーションメニューで [ロギング] を選択し、[ログルーター] をクリックします。
  [ログルーター] に移動
2. メニュー、 [シンクの詳細を表示する] の順に選択します。書き込み ID が [シンクの詳細] パネルに表示されます。
writerIdentity フィールドの値にメールアドレスが含まれている場合は、次の手順に進みます。値が None の場合、シンクのエクスポート先権限を構成する必要はありません。
[コピー] をクリックして、シンクの書き込み ID をクリップボードにコピーします。
エクスポート先へのオーナー アクセス権がある場合は、サービスアカウントをエクスポート先プロジェクトの 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

API メソッド projects.sinks.list を呼び出して、Google Cloud プロジェクトのシンクを一覧表示します。
権限を変更するシンクを見つけます。シンクの詳細に "writerIdentity" というラベルの JSON キーが含まれている場合は、次の手順に進みます。詳細に "writerIdentity" フィールドが含まれていない場合は、シンクのエクスポート先権限を構成する必要はありません。
エクスポート先へのオーナー アクセス権がある場合は、次のようにしてエクスポート先にサービスアカウントを追加します。
- 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

シンク内の writerIdentity フィールドからサービスアカウントを取得します。
```
gcloud logging sinks describe SINK_NAME
```
権限を変更するシンクを見つけます。シンクの詳細に writerIdentity を含む行が含まれている場合は、次の手順に進みます。詳細に writerIdentity フィールドが含まれていない場合は、シンクの宛先権限を構成する必要はありません。

次のステップで SERVICE_ACCOUNT フィールドの値は書き込み ID であり、次のようになります。
```
serviceAccount:service-p-123456789012@gcp-sa-logging.iam.gserviceaccount.com
```
エクスポート先へのオーナー アクセス権がある場合は、次のようにしてエクスポート先にサービスアカウントを追加します。
- 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 をプリンシパルとして追加するようにプロジェクトオーナーに依頼します。
たとえば、異なる Google Cloud プロジェクトの Logging バケット間でログを転送する場合は、次のように roles/logging.bucketWriter をサービスアカウントに追加します。
1. 宛先 Google Cloud プロジェクトの 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
}
```
  注: ポリシーで IAM Conditions をまだ使用していない場合は、バージョンを変更する必要があります。必ずバージョン 33 を指定してください。ポリシーバージョンの詳細については、IAM ドキュメントのポリシーについてをご覧ください。
3. IAM ポリシーを更新します。
```
gcloud projects set-iam-policy DESTINATION_PROJECT_ID output.json
```

宛先の制限

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

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

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

異なるプロジェクトに保存されているログバケットにログをルーティングすると、Error Reporting はそれらのログを分析できません。
Error Reporting は、顧客管理の暗号鍵を使用するログバケットに保存されているログに対して無効になります。

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

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

異なるプロジェクトにログをルーティングすると、Error Reporting はそれらのログを分析できません。
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")

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

次のステップ

シンクを使用してログを転送する際に問題が発生した場合について、ルーティングログのトラブルシューティングをご覧ください。
エクスポート先でルーティングされたログを表示する方法と、ログをフォーマットして整理する方法については、シンクの宛先でログを表示するをご覧ください。
Logging クエリ言語を使用したクエリとフィルタの詳細については、Logging クエリ言語をご覧ください。

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

概要

始める前に

シンクを作成する

Console

API

gcloud

宛先のパスの形式

シンクを管理する

コンソール

API

gcloud

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

コンソール

API

gcloud

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

コンソール

API

gcloud

宛先の制限

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

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

コードサンプル

フィルタの例

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

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

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

サポート性

次のステップ

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