このドキュメントでは、 Google Cloudが受信したログエントリを Cloud Logging が転送する仕組みについて説明します。転送先にはいくつかの種類があります。たとえば、ログエントリは、ログエントリを保存するログバケットのような宛先に転送できます。ログデータをサードパーティの宛先にエクスポートする場合は、ログエントリを Pub/Sub に転送できます。また、ログエントリを複数の宛先に転送することも可能です。
全体的には、Cloud Logging のログエントリのルーティングと保存は、次のようになります。
ログルーターについて
各 Google Cloud プロジェクト、請求先アカウント、フォルダ、組織には、リソースレベルのシンクを通るログエントリのフローを管理するログルーターがあります。ログルーターは、エントリのリソース階層にあるシンクを通るログエントリのフローも管理します。シンクは、ログエントリがどのように宛先に転送されるかを制御します。
ログルーターはログエントリを一時的に保存します。この動作により、ログエントリがシンクを通過する際に発生する可能性がある一時的な中断や停止をバッファできます。一時ストレージは、構成エラーを防ぐものではありません。
Logging バケットが提供するログルーターの一時ストレージは、長期ストレージと区別されます。
ログ保持期間より古い過去のタイムスタンプが付いた受信ログエントリや、24 時間を超える未来のタイムスタンプが付いた受信ログエントリは破棄されます。
ログシンクについて
ログシンクはログエントリを受信すると、ログエントリを無視するか転送するかを決定します。この決定は、ログエントリをログシンクのフィルタと比較することで行われます。ログエントリが転送されると、ログシンクはログシンクで指定された宛先にログエントリを送信します。その宛先は、プロジェクト、ストレージ ロケーション、サービスなどです。
ログシンクは、特定の Google Cloud リソース（ Google Cloud プロジェクト、請求先アカウント、フォルダ、組織）に属します。これらのリソースには複数のログシンクも含まれています。リソースがログエントリを受信すると、そのリソース内のすべてのログシンクがログエントリを個別に評価します。その結果、複数のログシンクが同じログエントリを転送できます。
デフォルトでは、ログデータはデータの元のプロジェクトに保存されます。ただし、この構成を変更する理由はいくつかあります。
- ログデータの保存を一元化するため。
- ログデータを他のビジネスデータと結合するため。
- ログデータを有用な方法で整理するため。
- 他のアプリケーション、他のリポジトリ、またはサードパーティにログをストリーミングするため。たとえば、サードパーティのプラットフォームでログを表示できるように Google Cloud からログをエクスポートできます。ログエントリをエクスポートするには、ログエントリを Pub/Sub に転送するログシンクを作成します。
ログシンクが正しく構成されていないと、ログエントリは転送されません。シンクが正しく構成されていない場合、エラーの詳細を報告するログエントリが書き込まれます。また、リソースの重要な連絡先にメールが送信されます。詳細については、トラブルシューティング: エラーを表示するをご覧ください。
ログシンクでは、過去に遡ってログエントリを転送できません。つまり、ログシンクは、シンクが作成される前に受信したログエントリを転送できません。同様に、シンクが正しく構成されていない場合、シンクは構成エラーが解決された後に到着したログエントリのみを転送します。ただし、ログデータはログバケットから Cloud Storage に遡ってコピーできます。詳細については、ログのコピーをご覧ください。
組織とフォルダのサポート
組織またはフォルダのログデータを管理するには、次の操作を行います。
組織またはフォルダとその子に対するログエントリを、シンクで指定された宛先に転送する集約シンクを作成できます。集約シンクには次の 2 種類があります。
- 非インターセプト集約シンク
- インターセプト集約シンク
この 2 つのシンクタイプの違いは、リソース階層のあるレベルでシンクをインターセプトすると、階層内の下位リソースの転送に影響する可能性がある点です。非インターセプト シンクは、他のリソースの転送には影響しません。リソース内のインターセプト シンクがログエントリと一致すると、ログエントリは子リソース内のシンクに送信されません。ただし、ログエントリの発生元のリソース内の
_Requiredログシンクには常に送信されます。デフォルトのリソース設定を構成して、組織またはフォルダ内の新しいリソース用にシステム作成の
_Defaultシンクの構成を指定できます。たとえば、これらの設定を使用して_Defaultシンクを無効にすることや、そのシンクにフィルタを指定することが可能です。
ルーティングの例
このセクションでは、プロジェクトで発生したログエントリがリソース階層内のシンクをどのように通過するかについて説明します。
例: 集約シンクが存在しない場合
ログエントリのリソース階層に集約シンクが存在しない場合、ログエントリはログエントリの元のプロジェクトのログシンクに送信されます。プロジェクト レベルのシンクでは、ログエントリがシンクの包含フィルタと一致し、シンクの除外フィルタと一致しない場合、ログエントリはシンクの宛先に転送されます。
例: 非インターセプト集約シンクが存在する場合
ログエントリのリソース階層に非インターセプト集約シンクが存在する場合を考えます。ログルーターがログエントリを非インターセプト集約シンクに送信すると、次のことが行われます。
非インターセプト集約シンクは、ログエントリが包含フィルタと一致し、除外フィルタと一致しない場合、ログエントリをシンクの宛先に転送します。
ログルーターは、ログエントリの元のプロジェクトのログシンクにログエントリを送信します。
プロジェクト レベルのシンクでは、ログエントリがシンクの包含フィルタと一致し、シンクの除外フィルタと一致しない場合、ログエントリはシンクの宛先に転送されます。
例: インターセプト集約シンクが存在する場合
ログエントリのリソース階層にインターセプト集約シンクが存在する場合を考えます。ログルーターがログエントリをインターセプト集約シンクに送信すると、次のいずれかが行われます。
ログエントリが包含フィルタと一致するが、除外フィルタと一致しない場合:
- ログエントリは、インターセプト集約シンクの宛先に転送されます。
- ログエントリは、ログエントリの発生元のプロジェクトの
_Requiredシンクに送信されます。
ログエントリが包含フィルタと一致しない場合、または少なくとも 1 つの除外フィルタと一致する場合:
- ログエントリは、インターセプト集約シンクによって転送されません。
ログルーターは、ログエントリの元のプロジェクトのログシンクにログエントリを送信します。
プロジェクト レベルのシンクでは、ログエントリがシンクの包含フィルタと一致し、シンクの除外フィルタと一致しない場合、ログエントリはシンクの宛先に転送されます。
ログシンク フィルタ
各ログシンクには 1 つの包含フィルタが含まれており、複数の除外フィルタを含めることができます。これらのフィルタは、ログシンクがログエントリをシンクの宛先に転送するかどうかを決定します。フィルタを指定しない場合、すべてのログエントリがシンクの宛先に転送されます。
ログエントリは、次のルールに基づいてログシンクが転送します。
ログエントリが包含フィルタと一致しない場合、ルーティングされません。シンクに包含フィルタが指定されていない場合、すべてのログエントリがそのフィルタと一致します。
ログエントリが包含フィルタと少なくとも 1 つの除外フィルタと一致する場合、そのエントリはルーティングされません。
ログエントリが包含フィルタと一致し、除外フィルタと一致しない場合は、シンクの宛先にルーティングされます。
ログシンクのフィルタは、Logging クエリ言語を使用して指定します。
entries.write API の割り当ての使用量や entries.write API 呼び出しの数を、除外フィルタで減らすことはできません。除外フィルタは、Logging API がログエントリを受信した後に適用されます。
システムによって作成されたログシンク
Google Cloud プロジェクト、請求先アカウント、フォルダ、組織ごとに、Cloud Logging は 2 つのログシンクを作成します。1 つは _Required、もう 1 つは _Default という名前です。これらのシンクの包含フィルタと除外フィルタにより、リソースに到達するすべてのログエントリが、シンクのいずれかによって転送されます。どちらのシンクも、ログシンクと同じリソースにあるログバケットにログデータを転送します。
このセクションの残りの部分では、システムによって作成されたログシンクのフィルタと宛先について説明します。
_Required ログシンク
リソースの _Required ログシンクは、監査ログのサブセットをリソースの _Required ログバケットに転送します。このシンクには除外フィルタは指定されておらず、包含フィルタは次のとおりです。
LOG_ID("cloudaudit.googleapis.com/activity") OR
LOG_ID("externalaudit.googleapis.com/activity") OR
LOG_ID("cloudaudit.googleapis.com/system_event") OR
LOG_ID("externalaudit.googleapis.com/system_event") OR
LOG_ID("cloudaudit.googleapis.com/access_transparency") OR
LOG_ID("externalaudit.googleapis.com/access_transparency")
_Required ログシンクは、_Required ログシンクが定義されているリソースで発生したログエントリのみと一致します。たとえば、ログシンクがアクティビティ ログエントリをプロジェクト A からプロジェクト B に転送するとします。ログエントリはプロジェクト B で生成されていないため、プロジェクト B の _Required ログシンクは、このログエントリを _Required ログバケットに転送しません。
_Required ログシンクを変更や削除することはできません。
_Default ログシンク
リソースの _Default ログシンクは、_Required ログシンクのフィルタに一致するものを除くすべてのログエントリを、リソースの _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")
_Default ログシンクは変更して無効にできます。たとえば、_Default ログシンクを編集して宛先を変更できます。既存のフィルタを変更することや、除外フィルタを追加することも可能です。
シンクの宛先
シンクの宛先は、シンクとは異なるリソースに配置できます。たとえば、ログシンクを使用して、あるプロジェクトのログを別のプロジェクトに保存されているログバケットに転送できます。
次の宛先がサポートされています。
- Google Cloud プロジェクト
宛先プロジェクトのログシンクでログエントリを再転送する場合、またはインターセプト集約シンクを作成した場合は、この宛先を選択します。シンクの宛先であるプロジェクトのログシンクは、プロジェクトを除くサポートされている任意の宛先にログエントリを再転送できます。
- ログバケット
Cloud Logging によって管理されるリソースにログデータを保存する場合は、この宛先を選択します。ログバケットに保存されているログデータは、ログ エクスプローラやログ分析などのサービスを使用して表示および分析できます。
ログデータを他のビジネスデータと結合する場合は、ログデータをログバケットに保存し、リンクされた BigQuery データセットを作成できます。リンクされたデータセットは読み取り専用のデータセットで、他の BigQuery データセットと同様にクエリできます。
- BigQuery データセット
- ログデータを他のビジネスデータと結合する場合は、この宛先を選択します。指定するデータセットは書き込み可能でなければなりません。シンクの宛先をリンクされた BigQuery データセットに設定しないでください。リンクされたデータセットは読み取り専用です。
- Cloud Storage バケット
- ログデータを長期保存する場合は、この宛先を選択します。Cloud Storage バケットは、ログエントリの発生元のプロジェクトに配置することも、別のプロジェクトに配置することもできます。ログエントリは、JSON ファイルとして保存されます。
- Pub/Sub トピック
- Google Cloud からログデータをエクスポートし、Splunk や Datadog などのサードパーティ統合を使用する場合は、この宛先を選択します。ログエントリは JSON 形式にフォーマットされ、Pub/Sub トピックに転送されます。
宛先の制限事項
このセクションでは、宛先固有の制限事項について説明します。
- ログエントリを別の Google Cloud プロジェクトのログバケットに転送する場合、Error Reporting はそれらのログエントリを分析しません。詳細については、Error Reporting の概要をご覧ください。
- ログエントリを BigQuery データセットに転送する場合は、BigQuery データセットで書き込みが有効になっている必要があります。リンクされたデータセットは読み取り専用のため、ログエントリを転送することはできません。
- ログデータを Cloud Storage バケットに転送する新しいシンクを作成した場合は、ログエントリの転送が開始されるまで数時間かかることがあります。これらのシンクは 1 時間ごとに処理されます。
ログシンクの宛先が Google Cloud プロジェクトの場合、次の制限が適用されます。
- 1 ホップの上限があります。
_Requiredログシンクのフィルタに一致するログエントリは、宛先プロジェクトで生成された場合にのみ、宛先プロジェクトの_Requiredログバケットに転送されます。- ログエントリのリソース階層にある集約シンクのみがログエントリを処理します。
たとえば、プロジェクト
Aのログシンクの宛先がプロジェクトBであるとします。次のようになります。- 1 ホップの制限により、プロジェクト
Bのログシンクはログエントリをプロジェクト Google Cloud に再転送できません。 - プロジェクト
Bの_Requiredログバケットには、プロジェクトBで発生したログエントリのみが保存されます。このログバケットには、プロジェクトAで発生したログエントリなど、他のリソースで発生したログエントリは保存されません。 - プロジェクト
AとプロジェクトBのリソース階層が異なる場合、プロジェクトAのログシンクがプロジェクトBに転送するログエントリは、プロジェクトBのリソース階層の集約シンクに送信されません。 - プロジェクト
AとプロジェクトBに同じリソース階層がある場合、ログエントリはその階層の集約シンクに送信されます。ログエントリが集約シンクによってインターセプトされなかった場合、ログルーターでログエントリがプロジェクトAのシンクに送信されます。
転送ログエントリがログベースの指標に与える影響
ログベースの指標は、ログエントリの内容から派生した Cloud Monitoring 指標です。この指標を使用すると、特定のメッセージを含むログエントリの数をカウントしたり、ログエントリに記録されたレイテンシ情報を抽出したりできます。ログベースの指標は Cloud Monitoring のグラフに表示でき、アラート ポリシーでモニタリングできます。
システム定義のログベースの指標はプロジェクト レベルで適用されます。ユーザー定義のログベースの指標は、プロジェクト レベルまたはログバケット レベルで適用できます。バケットをスコープとするログベースの指標は、集約シンクを使用してログエントリをログバケットに転送する場合や、あるプロジェクトから別のプロジェクトのログバケットにログエントリを転送する場合に便利です。
- システム定義のログベースの指標
-
ログルーターは、次のすべての条件が満たされる場合にログエントリをカウントします。
- ログエントリが、ログベースの指標が定義されているプロジェクトのログシンクを通過した。
ログエントリがログバケットに保存された。これはどのプロジェクトのログバケットでもかまいません。
たとえば、プロジェクト
Aのログシンクで、宛先がプロジェクトBになっているとします。また、プロジェクトBのログシンクがログエントリをログバケットに転送するとします。このシナリオでは、プロジェクトAからプロジェクトBに転送されたログエントリは、プロジェクトAのシステム定義のログベースの指標に加え、プロジェクトBのシステム定義のログベースの指標でもモニタリングされます。
- ユーザー定義のログベースの指標
-
ログルーターは、次のすべての条件が満たされる場合にログエントリをカウントします。
- ログベースの指標が定義されているプロジェクトで課金が有効になっている。
- （バケット スコープの指標の場合）ログエントリが、ログベースの指標が定義されているログバケットに保存された。
- （プロジェクト スコープの指標の場合）ログエントリが、ログベースの指標が定義されているプロジェクトのログシンクを通過した。
詳しくは、ログベースの指標の概要をご覧ください。
ベスト プラクティス
データ ガバナンスまたは一般的なユースケースで転送を使用する際のベスト プラクティスについては、次のドキュメントをご覧ください。
例: ログストレージを一元化する
このセクションでは、一元化されたストレージを構成する方法について概説します。一元的なストレージでは、ログデータを 1 か所でクエリできるため、傾向検索や問題調査時のクエリを簡素化できます。セキュリティの観点からみると、ストレージ ロケーションが 1 つになるため、セキュリティ アナリストのタスクも簡素化されます。
プロジェクトのログストレージをフォルダで一元管理する
フォルダを管理している際に、ログエントリのストレージを一元化する必要があると想定します。このユースケースでは、次のように対応します。
- フォルダ内に、
CentralStorageという名前のプロジェクトを作成します。 - フォルダのインターセプト集約シンクを作成し、すべてのログエントリを転送するように構成します。シンクの宛先を
CentralStorageという名前のプロジェクトに設定します。
フォルダまたはその子リソースのいずれかで発生したログエントリが到着すると、そのログエントリは、作成したインターセプト集約シンクに送信されます。このシンクは、ログエントリを CentralStorage という名前のプロジェクトに転送します。このプロジェクトのログシンクがログエントリを処理します。
_Defaultログシンクは、シンクのフィルタに一致するすべてのログエントリを_Defaultログバケットに転送します。このログバケットが、一元化されたストレージ ロケーションになります。_Requiredログシンクは、シンクのフィルタと一致し、CentralStorageプロジェクトで発生したログエントリを_Requiredログバケットに転送します。このログバケットは、一元化されたストレージ ロケーションではありません。ただし、すべてのログデータを一元的に保存できます。例については、監査ログを一元管理された場所に保存するをご覧ください。
集約シンクの処理が完了すると、ログエントリはログエントリの発生元のリソースの _Required ログシンクに送信されます。ログエントリが _Required ログシンクのフィルタと一致すると、ログエントリはリソースの _Required ログバケットに転送されます。したがって、フォルダ内の各 Google Cloud プロジェクトは、ログエントリを _Required ログバケットに保存します。
一連のプロジェクトのログストレージを一元化する
組織やフォルダがない場合は、ログエントリを 1 か所に保存することもできます。たとえば、次のことを行います。
CentralStorageという名前のプロジェクトを作成します。CentralStorage以外のプロジェクトごとに、_Defaultログシンクを編集し、宛先をCentralStorageという名前のプロジェクトに設定します。
上記の例では、_Default ログシンクの宛先が、そのプロジェクトの _Default ログバケットではなくプロジェクトに設定されている理由について説明します。主な理由は、シンプルさと一貫性です。ログエントリをプロジェクトに転送すると、宛先プロジェクトのログシンクが、保存するログエントリと保存場所を制御します。つまり、フィルタと宛先の機能を一元化します。保存するログエントリまたは保存場所を変更する場合は、1 つのプロジェクトのログシンクを変更するだけで済みます。
監査ログのログストレージを一元化する
_Required ログシンクに一致するログエントリを一元的に保存できます。これらのログエントリを一元的に保存する場合は、次のいずれかを行います。
_Requiredログシンクに一致するログエントリを一元化されたログバケットに転送するログシンクを作成します。前述の 2 つの例と同様にログシンクを構成し、宛先プロジェクトにログシンクを追加して、
_Requiredログシンクに一致するログエントリをログバケットに転送します。_Defaultログシンクでフィルタを編集することもできます。
このような戦略を実装する前に、料金に関するガイドラインを確認してください。
料金
Cloud Logging の料金については、Google Cloud Observability の料金をご覧ください。
次のステップ
Cloud Logging データのルーティングと保存については、次のドキュメントをご覧ください。
サポートされている宛先にログエントリをルーティングするシンクを作成するには、サポートされている宛先にログをルーティングするをご覧ください。
フォルダまたは組織のリソースからログエントリを転送できる集約シンクを作成する方法については、集約シンクの概要をご覧ください。
転送されるログエントリの形式と、転送先でログを整理する方法については、次のドキュメントをご覧ください。