このドキュメントでは、集約されたシンクを作成する方法について説明します。集約シンクを使用すると、組織またはフォルダ内の Google Cloud リソースによって生成されたログを組み合わせて、一元化されたロケーションに転送できます。
概要
集約シンクは、組織またはフォルダに含まれるリソースのログを組み合わせて、宛先に転送します。
これらのリソースでクエリできるログエントリ、またはこれらのリソースでシンクを介してルーティングできるログエントリを制御する場合は、集約シンクをインターセプトまたはインターセプトしないように構成できます。
非インターセプト集約シンクは、子リソースのシンクを介してログエントリをルーティングします。このシンクを使用すると、ログエントリが生成されたリソースでログエントリの可視性を維持できます。非インターセプト シンクは、子リソースに表示されません。
たとえば、組織に含まれているフォルダから生成されたすべてのログエントリを一元化されたログバケットにルーティングする非インターセプト 集約シンクを作成できます。ログエントリは、中央のログバケットと、ログエントリが生成されたリソースに保存されます。
インターセプト 集約シンクにより、
_Requiredシンクを除き、子リソースのシンクを介してログエントリがルーティングされなくなります。このシンクは、ログエントリの重複コピーが複数の場所に保存されるのを防ぐ場合に役立ちます。たとえば、データアクセス監査ログは、サイズが大きく、複数のコピーを保存すると費用がかさむ場合があります。データアクセス監査ログを有効にしている場合は、すべてのデータアクセス監査ログを分析用の一元化されたプロジェクトにルーティングするフォルダレベルのインターセプト シンクを作成できます。このインターセプト シンクを使用すると、子リソースのシンクがログのコピーを他の場所にルーティングすることもできなくなります。
インターセプト シンクを使用すると、ログが
_Requiredシンクにも一致しない限り、子リソースのログルーターを通過するログがブロックされます。ログがインターセプトされるため、ログは子リソースのログベースの指標またはログベースのアラート ポリシーにはカウントされません。インターセプト シンクは、子リソースの [ログルーター] ページで確認できます。
シンクの管理については、サポートされている宛先にログを転送する: シンクを管理するをご覧ください。
フォルダまたは組織ごとに最大 200 個のシンクを作成できます。
選択できる宛先
非インターセプト 集約シンクを使用して、同じ組織内またはフォルダ間で次の宛先にログをルーティングできます。
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 プロジェクトにルーティングします。この構成では、宛先プロジェクトのシンクによってログエントリが処理されます。
インターセプト シンクに関するベスト プラクティス
インターセプト シンクを作成する場合は、次のことをおすすめします。
子リソースがログエントリのルーティングを独立して制御する必要があるかどうかを検討します。子リソースが特定のログエントリの独立した制御を必要とする場合は、インターセプト シンクがそれらのログエントリをルーティングしないようにします。
インターセプト シンクの説明に連絡先情報を追加します。これは、インターセプト シンクを管理するユーザーが、ログエントリがインターセプトされるプロジェクトを管理するユーザーと異なる場合に役立ちます。
まず、非インターセプト 集約シンクを作成して、シンクの構成をテストし、正しいログがルーティングされていることを確認します。
集約シンクと VPC Service Controls
集約シンクと VPC Service Controls を使用する場合、次の制限が適用されます。
集約シンクは、サービス境界内にあるプロジェクトのデータにアクセスできます。集約シンクが境界内のデータにアクセスするのを制限するには、IAM を使用して Logging 権限を管理することをおすすめします。
VPC Service Controls では、フォルダまたは組織のリソースをサービス境界に追加できません。したがって、VPC Service Controls を使用して、フォルダレベルと組織レベルのログ（集約ログを含む）を保護することはできません。フォルダレベルまたは組織レベルで Logging 権限を管理するには、IAM を使用することをおすすめします。
フォルダレベルまたは組織レベルのシンクを使用して、サービス境界で保護されるリソースにログをルーティングする場合は、サービス境界に上り（内向き）ルールを追加する必要があります。上り（内向き）ルールで、集約シンクが使用するサービス アカウントからリソースへのアクセスを許可する必要があります。詳しくは、以下のページをご覧ください。
サービス境界に上り（内向き）ポリシーまたは下り（外向き）ポリシーを指定すると、ログシンクを使用して Cloud Storage リソースにログを転送するときに
ANY_SERVICE_ACCOUNTとANY_USER_ACCOUNTを ID タイプとして使用することはできません。ただし、ID タイプとしてANY_IDENTITYを使用できます。
準備
シンクを作成する前に、次のことを確認します。
ログ エクスプローラに表示できるログエントリを含む Google Cloud フォルダまたは組織がある。
ログのルーティング元の Google Cloud の組織またはフォルダに対して、次のいずれかの IAM ロールを付与されている。
- オーナー（
roles/owner） - Logging 管理者（
roles/logging.admin） - ログ構成書き込み（
roles/logging.configWriter）
これらのロールに含まれる権限を使用して、シンクの作成、削除、変更ができます。IAM ロールの設定については、Logging のアクセス制御ガイドをご覧ください。
- オーナー（
サポート対象の宛先にリソースがあるか、作成できる。
シンクの前に、Google Cloud CLI、Google Cloud コンソール、または Google Cloud APIs を使用して宛先を作成する必要があります。転送先はどの組織のどの Google Cloud プロジェクトにも作成できますが、シンクのサービス アカウントに、転送先への書き込み権限があることを確認する必要があります。
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.
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 を使用して認証するをご覧ください。
集約シンクの作成
Console
フォルダまたは組織の集約シンクを作成する手順は次のとおりです。
-
Google Cloud コンソールで、[ログルーター] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。
既存のフォルダまたは組織を選択します。
[シンクを作成] を選択します。
[シンクの詳細] パネルで、次の詳細を入力します。
シンク名: シンクの識別子を指定します。シンクを作成した後は、シンクの名前は変更できませんが、シンクを削除して新しいシンクを作成することはできます。
シンクの説明（省略可）: シンクの目的またはユースケースについて説明します。
次のいずれかを行います。
インターセプト シンクを作成するには、[シンク サービスを選択] メニューで [Google Cloud プロジェクト] を選択し、宛先の完全修飾名を入力します。構文については、宛先パスの形式をご覧ください。
非インターセプト シンクを作成するには、[シンク サービスを選択] メニューに移動して、次のいずれかを行います。
ログエントリを別の Google Cloud プロジェクトにルーティングするには、[Google Cloud プロジェクト] を選択し、宛先の完全修飾名を入力します。構文については、宛先パスの形式をご覧ください。
ログエントリを同じ Google Cloud プロジェクト内のサービスにルーティングするには、次のいずれかのオプションを選択します。
- Cloud Logging バケット: Logging バケットを選択または作成します。
- BigQuery データセット: ルーティングされたログエントリを受信する特定のデータセットを選択または作成します。パーティション分割テーブルを使用することもできます。
- Cloud Storage バケット: ルーティングされたログエントリを受信する特定の Cloud Storage バケットを選択または作成します。
- Pub/Sub トピック: ルーティングされたログエントリを受信する特定のトピックを選択または作成します。
- Splunk: Splunk サービスの Pub/Sub トピックを選択します。
ログエントリを別の Google Cloud プロジェクトのサービスにルーティングするには、次の操作を行います。
- [その他のリソース]を選択します。
宛先の完全修飾名を入力します。構文については、宛先パスの形式をご覧ください。
たとえば、シンクの宛先が Pub/Sub トピックの場合、
destinationは次のようになります。pubsub.googleapis.com/projects/PROJECT_ID/topics/TOPIC_ID
[シンクに含めるログの選択] パネルで、次のいずれかを行います。
インターセプト シンクを作成するには、[この組織とすべての子リソースによって取り込まれたログをインターセプトする] を選択します。
非インターセプト集約シンクを作成するには、[このリソースとすべての子リソースによって取り込まれたログを含める] を選択します。
[包含フィルタの作成] フィールドに、含めるログエントリに一致するフィルタ式を入力して、ダイアログを完了します。フィルタを設定しない場合は、選択したリソースのすべてのログエントリが宛先に転送されます。
たとえば、すべてのデータアクセスの監査 ログを 1 つの Logging バケットにルーティングするようにフィルタを作成できます。このフィルタは次のようになります。
LOG_ID("cloudaudit.googleapis.com/data_access") OR LOG_ID("externalaudit.googleapis.com/data_access")フィルタの例については、集約シンク用のフィルタの作成をご覧ください。
フィルタの長さは 20,000 文字までです。
（省略可）正しいフィルタを入力したことを確認するには、[ログをプレビュー] を選択します。これにより、フィルタが事前に入力された状態で、ログ エクスプローラが新しいタブで開きます。
（省略可）[シンクから除外するログを選択] パネルで、次の操作を行います。
[除外フィルタの名前] フィールドに名前を入力します。
[除外フィルタの作成] セクションで、除外するログエントリに一致するフィルタ式を入力します。
sample関数を使用して、除外するログエントリの一部を選択することもできます。たとえば、特定のプロジェクトのログエントリを宛先にルーティングしない場合は、次の除外フィルタを追加します。
logName:projects/PROJECT_ID
複数のプロジェクトからログエントリを除外するには、論理 OR 演算子を使用して
logName句を結合します。
シンクごとに最大 50 個の除外フィルタを作成できます。フィルタの長さは 20,000 文字までです。
[シンクを作成] を選択します。
シンクのサービス アカウントに、シンクの宛先にログエントリを書き込む権限を付与します。詳細については、宛先の権限を設定するをご覧ください。
gcloud
集約シンクを作成するには、
logging sinks createコマンドを使用します。シンクを作成するには、
gcloud logging sinks createコマンドを呼び出し、--include-childrenオプションを含めます。次のコマンドを実行する前に、次のように置き換えます。
- SINK_NAME: ログシンクの名前。シンクの作成後に名前を変更することはできません。
- SINK_DESTINATION: ログエントリのルーティング先となるサービスまたはプロジェクト。
- INCLUSION_FILTER: シンクの包含フィルタ。フィルタの例については、集約シンク用のフィルタの作成をご覧ください。
- FOLDER_ID: フォルダの ID。シンクを組織レベルで作成する場合は、
--folder=FOLDER_IDを-- organization=ORGANIZATION_IDに置き換えます。
gcloud logging sinks createコマンドを実行します。gcloud logging sinks create SINK_NAME \ SINK_DESTINATION --include-children \ --folder=FOLDER_ID --log-filter="INCLUSION_FILTER"
また、次のオプションも指定できます。
- インターセプト シンクを作成するには、
--intercept-childrenオプションを含めます。
たとえば、フォルダレベルで集約シンクを作成し、宛先が Pub/Sub トピックの場合は、コマンドは次のようになります。
gcloud logging sinks create SINK_NAME \ pubsub.googleapis.com/projects/PROJECT_ID/topics/TOPIC_ID --include-children \ --folder=FOLDER_ID --log-filter="logName:activity"
シンクのシ宛先への書き込み権限をシンクのサービス アカウントに付与します。詳細については、宛先の権限を設定するをご覧ください。
REST
集約シンクを作成するには、Logging API メソッド
organizations.sinks.createまたはfolders.sinks.createを使用します。次のように、メソッドの引数を準備します。parentフィールドを、シンクを作成する Google Cloud 組織またはフォルダに設定します。親は次のいずれかにする必要があります。organizations/ORGANIZATION_IDfolders/FOLDER_ID
メソッドのリクエスト本文の
LogSinkオブジェクトで、次のいずれかを行います。includeChildrenをTrueに設定する。インターセプト シンクを作成するには、
interceptChildrenフィールドもTrueに設定します。
含めるログエントリに一致するように
filterフィールドを設定します。フィルタの例については、集約シンク用のフィルタの作成をご覧ください。
フィルタの長さは 20,000 文字以下にする必要があります。
残りの
LogSinkフィールドを他のシンクの場合と同様に設定します。詳細については、サポートされている宛先にログをルーティングするをご覧ください。organizations.sinks.createまたはfolders.sinks.createを呼び出してシンクを作成します。シンクのシ宛先への書き込み権限をシンクのサービス アカウントに付与します。詳細については、宛先の権限を設定するをご覧ください。
シンクに加えたどの変更も、適用されるまで数分かかることがあります。
集約シンクのフィルタを作成する
他のシンクと同様に、集約シンクにも個々のログエントリを選択するフィルタが含まれます。 集約シンクの作成に使用できるフィルタの例については、ログ エクスプローラを使用したサンプルクエリをご覧ください。
以下に、集約シンク機能を使用するときに役立つフィルタの比較例を示します。一部の例で次の表記を使用しています。
:は部分文字列演算子です。=演算子を代わりに使用しないでください。...はさらにフィルタ比較が続くことを表します。- 変数は色付きのテキストで示されます。これらは有効な値に置き換えてください。
フィルタの長さは 20,000 文字までです。
フィルタリング構文の詳細については、Logging のクエリ言語をご覧ください。
ログソースを選択する
集約シンクでは、組織またはフォルダの子リソースごとに、子リソースに送信される各ログエントリにシンクの包含フィルタと除外フィルタが適用されます。包含フィルタに一致し、除外されていないログエントリがルーティングされます。
シンクがすべての子リソースからログエントリをルーティングするようにする場合は、シンクの包含フィルタと除外フィルタでプロジェクト、フォルダ、または組織を指定しないでください。たとえば、次のようなフィルタを使用して組織の集約シンクを構成するとします。
resource.type="gce_instance"
前に示すフィルタでは、その組織の子に書き込まれたリソースタイプの Compute Engine インスタンスのログエントリが、集約シンクによって宛先にルーティングされます。
しかし、集約シンクを使用して特定の子リソースからのログエントリのみをルーティングしたい場合もありえます。たとえば、コンプライアンス上の理由から、特定のフォルダやプロジェクトの監査ログを、自身の Cloud Storage バケットに格納したい場合などです。このような状況では、包含フィルタを構成して、ログエントリをルーティングする各子リソースを指定します。フォルダとそのフォルダ内のすべてのプロジェクトからログエントリをルーティングする場合、フィルタでフォルダとそのフォルダに含まれる各プロジェクトの一覧を表示し、さらにステートメントを
OR句で結合する必要があります。次のフィルタは、ログエントリを特定の Google Cloud プロジェクト、フォルダ、または組織に制限します。
logName:"projects/PROJECT_ID/logs/" AND ...
logName:("projects/PROJECT_A_ID/logs/" OR "projects/PROJECT_B_ID/logs/") AND ...
logName:"folders/FOLDER_ID/logs/" AND ...
logName:"organizations/ORGANIZATION_ID/logs/" AND ...
たとえば、フォルダ
my-folderに書き込まれた Compute Engine インスタンスに書き込まれたログエントリのみをルーティングするには、次のフィルタを使用します。logName:"folders/my-folder/logs/" AND resource.type="gce_instance"
前のフィルタでは、
my-folder以外のリソースに書き込まれたログエントリ（my-folderの子である Google Cloud プロジェクトに書き込まれたログエントリを含む）は、宛先にルーティングされません。モニタリング対象リソースを選択する
Google Cloud プロジェクトの特定のモニタリング対象リソースだけからログエントリをルーティングするには、複数の比較演算子を使用してリソースを厳密に指定します。
logName:"projects/PROJECT_ID/logs" AND resource.type=RESOURCE_TYPE AND resource.labels.instance_id=INSTANCE_ID
リソースタイプの一覧については、モニタリング対象リソースタイプをご覧ください。
ログエントリのサンプルを選択する
ログエントリのランダムなサンプルを転送するには、
sample組み込み関数を追加します。たとえば、現在のフィルタに一致するログエントリの 10% だけを転送するには、次の記述を追加します。sample(insertId, 0.10) AND ...詳細については、
sample関数をご覧ください。Cloud Logging のフィルタの詳細については、Logging のクエリ言語をご覧ください。
エクスポート先の権限を設定する
このセクションでは、シンクの宛先にログエントリを書き込むための Identity and Access Management 権限を Logging に付与する方法について説明します。Logging のロールと権限の完全なリストについては、アクセス制御をご覧ください。
ログエントリを現在のプロジェクトのログバケット以外の宛先に転送するシンクを作成または更新する場合は、そのシンクのサービス アカウントが必要です。Logging は、サービス アカウントを自動的に作成して管理します。
- 2023 年 5 月 22 日以降、シンクを作成し、基盤となるリソースのサービス アカウントが存在しない場合は、Logging によってサービス アカウントが作成されます。Logging では、基盤となるリソース内のすべてのシンクに同じサービス アカウントが使用されます。リソースには、Google Cloud プロジェクト、組織、フォルダ、請求先アカウントがあります。
- 2023 年 5 月 22 日より前には、Logging は各シンクのサービス アカウントを作成していました。2023 年 5 月 22 日現在、Logging では基盤となるリソース内のすべてのシンクに共有サービス アカウントを使用しています。
シンクの書き込み ID は、そのシンクに関連付けられているサービス アカウントの識別子です。現在の Google Cloud プロジェクトのログバケットに書き込むシンクを除き、すべてのシンクには書き込み ID があります。
サービス境界で保護されたリソースにログエントリを転送するには、シンクのサービス アカウントをアクセスレベルに追加し、宛先サービス境界に割り当てる必要があります。この操作は、集約されていないシンクには必要ありません。詳細については、VPC Service Controls: Cloud Logging をご覧ください。
シンクをエクスポート先にルーティングするための権限を設定するには、次の手順を行います。
Console
シンクのサービス アカウントに関する情報を取得する手順は次のとおりです。
-
Google Cloud コンソールで、[ログルーター] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。
[more_vert メニュー]、 [シンクの詳細を表示] の順に選択します。 書き込み ID が [シンクの詳細] パネルに表示されます。
writerIdentityフィールドの値にメールアドレスが含まれている場合は、次のステップに進みます。値がNoneの場合、宛先の権限を構成する必要はありません。シンクの書き込み ID をクリップボードにコピーします。
serviceAccount:文字列はサービス アカウント ID の一部です。例:serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.com
サービス アカウントを宛先プロジェクトの IAM プリンシパルとして追加します。
-
Google Cloud コンソールの [IAM] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが [IAM と管理者] である結果を選択します。
宛先プロジェクトを選択します。
[ アクセスを許可] をクリックします。
サービス アカウントに必要な 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権限が必要です。
- Cloud Storage のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、ストレージ オブジェクト作成者のロール（
-
-
gcloud
宛先を含む Google Cloud プロジェクトに対するオーナー アクセス権があることを確認します。シンクの宛先へのオーナー アクセス権がない場合は、書き込み ID をプリンシパルとして追加するようにプロジェクト オーナーに依頼します。
シンクのサービス アカウントに関する情報を取得するには、
gcloud logging sinks describeメソッドを呼び出します。次のコマンドを実行する前に、次のように置き換えます。
- SINK_NAME: ログシンクの名前。シンクの作成後に名前を変更することはできません。
gcloud logging sinks describeコマンドを実行します。gcloud logging sinks describe SINK_NAMEシンクの詳細に
writerIdentityというラベルのフィールドが含まれている場合は、次のステップに進みます。詳細にwriterIdentityフィールドが含まれていない場合、シンクの宛先権限を構成する必要はありません。シンクの書き込み ID をクリップボードにコピーします。
serviceAccount:文字列はサービス アカウント ID の一部です。サービス アカウントの書き込み者 ID は次のようになります。
serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.comサービス アカウントを宛先プロジェクトの IAM プリンシパルとして追加するには、
gcloud projects add-iam-policy-bindingコマンドを呼び出します。次のコマンドを実行する前に、次のように置き換えます。
- 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権限が必要です。
- Cloud Storage のエクスポート先の場合は、IAM を使用してシンクの書き込み ID をプリンシパルとして追加してから、ストレージ オブジェクト作成者のロール（
gcloud projects add-iam-policy-bindingコマンドを実行します。gcloud projects add-iam-policy-binding PROJECT_ID --member=PRINCIPAL --role=ROLE
REST
サービス アカウントにロールを付与するには、Google Cloud コンソールまたは Google Cloud CLI を使用することをおすすめします。
次のステップ
ログバケットにログビューを作成する方法を確認する。ログビューを使用すると、ログバケットに保存されているログエントリのサブセットに対する読み取りアクセス権をプリンシパルに付与できます。
既存のシンクの管理については、サポートされている宛先にログを転送する: シンクを管理するをご覧ください。
シンクを使用してログを転送する際に問題が発生した場合について、ルーティングとシンクのトラブルシューティングで確認する。
宛先でログを表示する方法と、ログをフォーマットして整理する方法について、シンクの宛先でログを表示するで確認する。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2024-12-22 UTC。
-