このドキュメントでは、Cloud Logging がログエントリを処理する方法について説明し、Logging の転送とストレージの主なコンポーネントについて詳述します。 転送とは、新しく到着したログエントリの処理方法を決定するために Cloud Logging が使用するプロセスのことです。ログエントリを、Logging のようなログエントリを保存する宛先や、Pub/Sub に転送できます。ログをサードパーティの宛先にエクスポートするには、ログを Pub/Sub トピックに転送してから、サードパーティの宛先を承認して Pub/Sub トピックへ登録します。
全体的には、Cloud Logging のログエントリの転送と保存は、次のようになります。
ログルーターを使用してログを転送する
以下のセクションでは、Logging がシンクを使用してログルーターでログをルーティングする方法について説明します。
ログルーター
ログエントリが、entries.write の呼び出し中に logName フィールドで指定された Google Cloud リソース に送信されます。
Cloud Logging は Cloud Logging API でログエントリを受信し、その過程でログエントリはログルーターを通過します。ログルーターのシンクは、各ログエントリを包含フィルタと除外フィルタと照合し、ログエントリの送信先として設定する必要がある宛先（Cloud Logging バケットなど）を決定します。シンクを組み合わせて、ログエントリを複数の宛先に転送できます。
ログルーターはログエントリを一時的に保存します。この動作により、シンクがログエントリを宛先に転送する際に発生する可能性のある一時的な中断や停止をバッファできます。このバッファリングは、シンク構成のエラーを保護するものではありません。シンクが正しく構成されていない場合、ログエントリは転送されず、エラーログが生成され、シンク構成エラーを通知するメールが送信されます。ログエントリを転送できない場合は、破棄されます。
ログルーターの一時ストレージは、Logging バケットによって提供される長期ストレージとは区別されます。
ログ保持期間より古い過去のタイムスタンプが付いた受信ログエントリや、24 時間を超える未来のタイムスタンプが付いた受信ログエントリは破棄されます。
シンク
シンクは、Cloud Logging がログをルーティングする方法を制御します。シンクを使用すると、ログの一部またはすべてをサポートされている宛先に転送できます。ログの転送方法を制御する理由には、次のようなものがあります。
- 読み取る可能性は低いものの、コンプライアンスを目的にログを保持するため。
- バケット内のログを有用な形式で整理する。
- ログに対してビッグデータ分析ツールを使用するため。
- 他のアプリケーション、他のリポジトリ、またはサードパーティにログをストリーミングするため。たとえば、サードパーティのプラットフォームでログを表示できるように Google Cloud からログをエクスポートする場合は、ログエントリを Pub/Sub に転送するようにシンクを構成します。
シンクは、特定の Google Cloud リソース（Google Cloud プロジェクト、請求先アカウント、フォルダ、組織）に属します。リソースは、ログエントリを受信すると、リソースに含まれるシンクと、有効になっている場合は、リソース階層に属する祖先シンクに従ってログエントリを転送します。ログエントリは、一致する各シンクに関連付けられている宛先に送信されます。
Cloud Logging には、Google Cloud プロジェクト、請求先アカウント、フォルダ、組織ごとに 2 つのシンク（_Required と _Default）が事前定義されています。リソースで生成されたすべてのログは、これら 2 つのシンクによって自動的に処理され、対応する名前の _Required または _Default バケットに保存されます。
シンクは別々に動作します。事前定義されたシンクがログエントリをどのように処理するかにかかわらず、独自のシンクを作成して、ログの一部またはすべてを選択できる宛先に転送するか、Cloud Logging で保存されないようにログを除外できます。
シンクによって転送されるログエントリは、シンクの包含フィルタと除外フィルタを構成することで制御されます。シンクの構成に応じて、Cloud Logging が受信するすべてのログエントリは、次のカテゴリの 1 つまたは複数に分類されます。
Cloud Logging に保存され、他の場所には転送されない
Cloud Logging に保存され、さらに、サポートされている宛先へ転送される
Cloud Logging には保存されず、サポートされている宛先に転送される
Cloud Logging には保存されず、他の場所にも転送されません。
通常は Google Cloud プロジェクト レベルでシンクを作成しますが、Google Cloud 組織またはフォルダに含まれているリソースからログを組み合わせて転送する場合は、集約シンクを作成します。
ログは Logging API を通過して転送されるため、シンクはシンクの作成後に到着したログエントリのみを転送します。ログエントリをさかのぼって転送する必要がある場合は、ログのコピーをご覧ください。包含フィルタ
シンクでフィルタを指定しない場合、すべてのログエントリが一致し、シンクの宛先に転送されます。包含フィルタを設定することで、特定のログエントリを選択するようにシンクを構成できます。1 つ以上の除外フィルタを設定して、ログエントリの転送を除外することもできます。
シンクを構成する場合は、Logging のクエリ言語を使用してフィルタを指定します。
ログエントリは、次のルールに基づいてシンクによって転送されます。
ログエントリが包含フィルタと一致しない場合、転送されません。シンクに包含フィルタが指定されていない場合、すべてのログエントリがそのフィルタと一致します。
ログエントリが包含フィルタと少なくとも 1 つの除外フィルタと一致する場合、そのエントリは転送されません。
ログエントリが包含フィルタと一致し、除外フィルタと一致しない場合は、シンクの宛先に転送されます。
除外フィルタ
シンクを作成するときに、複数の除外フィルタを設定できます。除外フィルタを使用すると、包含フィルタに一致するログエントリをシンクの宛先に転送したり、ログバケットに保存したりしないようにできます。除外フィルタは、Logging クエリ言語を使用して定義します。
除外されたログエントリは、Logging API によって受信された後に除外されるため、entries.write API 割り当てを消費します。ログエントリを除外して entries.write API 呼び出しの数を減らすことはできません。
除外されたログエントリはログ エクスプローラでは使用できません。
除外フィルタで明示的に、または、Logging 保存先を持つどのシンクにも一致しないために、少なくとも 1 つのログバケットに転送されないログエントリも、Error Reporting から除外されます。したがって、これらのログエントリは障害のトラブルシューティングに使用できません。 ユーザー定義のログベースの指標は、含まれるログエントリと除外されたログエントリの両方のログエントリから計算されます。詳細については、ログのモニタリングをご覧ください。選択できる宛先
ログルーターを使用して、特定のログエントリを任意の Google Cloud プロジェクトのサポートされている宛先に転送できます。Logging でサポートされているシンクのエクスポート先は、次のとおりです。
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 プロジェクトにルーティングします。この構成では、宛先プロジェクトのシンクによってログエントリが処理されます。
詳細については、サポートされている宛先にログをルーティングするをご覧ください。
ログの保存、表示、管理
次のセクションでは、Cloud Logging でログの保存、表示、管理を行う方法について詳しく説明します。
ログバケット
Cloud Logging では、Google Cloud プロジェクト、請求先アカウント、フォルダ、組織でログデータを保存して整理するためのコンテナとしてログバケットを使用し、ログデータを保存、整理します。Cloud Logging に保存したログエントリはインデックスに登録されて最適化され、ログをリアルタイムで分析できるように配信されます。Cloud Logging バケットは、似たような名前を持つ Cloud Storage バケットとは異なるストレージ エンティティです。
Logging では、Google Cloud プロジェクト、請求先アカウント、フォルダ、組織ごとに、_Required と _Default という 2 つのログバケットが自動的に作成されます。Logging は、_Required と _Default という名前のシンクを自動的に作成します。デフォルトの構成では、対応する名前のバケットにログエントリが転送されます。
_Default シンクを無効にできます。このシンクはログエントリを _Default ログバケットに転送します。新しい Google Cloud プロジェクトまたはフォルダ用に作成された _Default シンクの動作を変更することもできます。詳細については、組織とフォルダのデフォルト設定を構成するをご覧ください。
_Required バケットの転送ルールは変更できません。
また、すべての Google Cloud プロジェクトに対してユーザー定義バケットを作成できます。
シンクを作成して、ログエントリのすべてまたは一部を任意のログバケットに転送します。この柔軟性により、ログエントリを保存する Google Cloud プロジェクトを選択できます。また、複数のリソースのログエントリを 1 か所に保存することもできます。
詳細については、ログバケットを構成するをご覧ください。
_Required ログバケット
Cloud Logging は、次の種類のログエントリを自動的に _Required バケットに転送します。
- 管理アクティビティ監査ログ
- システム イベント監査ログ
- Google Workspace 管理者監査ログ
- Enterprise グループ監査ログ
- ログインの監査ログ
- アクセスの透明性ログ。アクセスの透明性ログを有効にする方法については、アクセスの透明性ログのドキュメントをご覧ください。
Cloud Logging は、_Required バケットのログを 400 日間保持します。この保持期間は変更できません。
_Required バケットの変更や削除はできません。_Required シンクを無効にすることはできません。このシンクはログエントリを _Required バケットに転送します。
_Default ログバケット
_Required バケットに保存されなかったログエントリは、_Default シンクを無効にするか編集しない限り、_Default シンクによって _Default バケットに転送されます。シンクを変更する手順については、シンクの管理をご覧ください。
たとえば、Cloud Logging は、次の種類のログエントリを自動的に _Default バケットに転送します。
バケットのカスタム保持を設定しない限り、Cloud Logging は _Default バケットのログエントリを 30 日間保持します。
_Default バケットは削除できません。
ユーザー定義のログバケット
任意の Google Cloud プロジェクトでユーザー定義のログバケットを作成することもできます。ユーザー定義のログバケットにシンクを適用すると、ログエントリの任意のサブセットを任意のログバケットに転送でき、ログエントリを保存する Google Cloud プロジェクトを選択できます。また、複数のリソースのログエントリを 1 か所に保存できます。
たとえば、プロジェクト A で生成されたログに関して、そのログエントリをプロジェクト A のユーザー定義バケットまたはプロジェクト B のログバケットに転送するようにシンクを構成できます。
ユーザー定義のログバケットの管理（削除や更新など）については、ログバケットの構成と管理をご覧ください。
リージョン指定
ログバケットは、リージョン リソースです。ログエントリの保存、インデックス登録、検索を行うインフラストラクチャは特定の地理的な場所にあります。Google Cloud はそのインフラストラクチャを管理して、アプリケーションがそのリージョン内のゾーン全体で冗長的に利用できるようにします。
ログバケットを作成するとき、または組織レベルのリージョン ポリシーを設定するときに、ログの保存先を選択できます。
Cloud Logging でサポートされているリージョンは次のとおりです。
グローバル
| リージョン名 | リージョンの説明 |
|---|---|
global |
世界中の任意のデータセンターに保存されているログ。ログが別のデータセンターに移動される場合があります。追加の冗長性の保証はありません。 |
マルチリージョン: EU と米国
| リージョン名 | リージョンの説明 |
|---|---|
eu |
欧州連合内の任意のデータセンターに保存されているログ。ログが別のデータセンターに移動される場合があります。追加の冗長性の保証はありません。 |
us |
米国内の任意のデータセンターに保存されているログ。ログが別のデータセンターに移動される場合があります。追加の冗長性の保証はありません。 |
アフリカ
| リージョン名 | リージョンの説明 |
|---|---|
africa-south1 |
ヨハネスブルグ |
南北アメリカ
| リージョン名 | リージョンの説明 |
|---|---|
northamerica-northeast1 |
モントリオール |
northamerica-northeast2 |
トロント |
southamerica-east1 |
サンパウロ |
southamerica-west1 |
サンチアゴ |
us-central1 |
アイオワ |
us-east1 |
サウスカロライナ |
us-east4 |
北バージニア |
us-east5 |
コロンバス |
us-south1 |
Dallas |
us-west1 |
Oregon |
us-west2 |
ロサンゼルス |
us-west3 |
ソルトレイクシティ |
us-west4 |
ラスベガス |
アジア太平洋
| リージョン名 | リージョンの説明 |
|---|---|
asia-east1 |
台湾 |
asia-east2 |
香港 |
asia-northeast1 |
東京 |
asia-northeast2 |
大阪 |
asia-northeast3 |
ソウル |
asia-south1 |
ムンバイ |
asia-south2 |
デリー |
asia-southeast1 |
シンガポール |
asia-southeast2 |
ジャカルタ |
australia-southeast1 |
シドニー |
australia-southeast2 |
メルボルン |
ヨーロッパ
| リージョン名 | リージョンの説明 |
|---|---|
europe-central2 |
ワルシャワ |
europe-north1 |
フィンランド |
europe-southwest1 |
マドリッド |
europe-west1 |
ベルギー |
europe-west2 |
ロンドン |
europe-west3 |
フランクフルト |
europe-west4 |
オランダ |
europe-west6 |
チューリッヒ |
europe-west8 |
ミラノ |
europe-west9 |
パリ |
europe-west10 |
ベルリン |
europe-west12 |
トリノ |
中東
| リージョン名 | リージョンの説明 |
|---|---|
me-central1 |
ドーハ |
me-central2 |
Dammam |
me-west1 |
テルアビブ |
ロケーションを global に設定すると、ログエントリが物理的に保存される場所を指定する必要はありません。
特定のストレージ リージョンを、組織またはフォルダで作成された _Default バケットと _Required バケットに自動的に適用できます。詳細については、組織とフォルダのデフォルト設定を構成するをご覧ください。
組織のポリシー
組織のポリシーを作成して、組織でコンプライアンスと規制のニーズを満たせるようにできます。組織のポリシーを使用すると、組織が新しいログバケットを作成できるリージョンを指定できます。特定のリージョンで新しいログバケットを作成できないように組織を制限することもできます。
Cloud Logging では、既存のログバケットに対して新しく作成した組織のポリシーが適用されません。新しいログバケットにのみ、このポリシーが適用されます。
ロケーション ベースの組織のポリシーの作成については、リソース ロケーションを制限するをご覧ください。
また、組織またはフォルダ内の _Default バケットと _Required バケットのデフォルトのストレージ ロケーションを構成することもできます。データの保存先を制限する組織のポリシーを構成する場合は、指定するデフォルトのストレージ ロケーションがその制約と一致するようにする必要があります。詳細については、組織とフォルダのデフォルト設定を構成するをご覧ください。
保持
Cloud Logging は、ログが保持されるログバケット タイプに適用される保持ルールに従って、ログを保持します。 さまざまなタイプのログの保持期間については、割り当てと上限をご覧ください。
1～3,650 日の範囲でログを保持するように Cloud Logging を構成できます。カスタム保持ルールは、ログの種類やログが別の場所からコピーされたかどうかに関わらず、バケット内のすべてのログに適用されます。
ログバケットの保持ルールの設定については、カスタム保持の構成をご覧ください。
ログビュー
ログビューを使用すると、ログバケットに保存されているログエントリのサブセットに対してのみユーザーにアクセス権を付与できます。ログビューの構成方法と、特定のログビューへのアクセス権を付与する方法については、ログバケットのログビューを構成するをご覧ください。
Cloud Logging は、すべてのログバケットに _AllLogs ビューを自動的に作成します。これにより、そのバケットに保存されているすべてのログが表示されます。また、Cloud Logging は、_Default という _Default バケットのビューも作成します。_Default バケットの _Default ビューには、データアクセスの監査ログを除くすべてのログが表示されます。_AllLogs ビューと _Default ビューは編集できません。また、_Default ログビューは削除できません。
カスタム ログビューでは、ログデータへのアクセスを制御する高度で詳細な方法を提供します。たとえば、一元管理された Google Cloud プロジェクトに、組織のすべてのログを保存するシナリオを考えてみます。ログバケットには複数の Google Cloud プロジェクトのログを格納できるため、それぞれのユーザーがログを表示できる Google Cloud プロジェクトを制御する必要がある場合があります。カスタム ログビューを使用すると、あるユーザーに 1 つの Google Cloud プロジェクトのログへのアクセス権のみを付与しつつ、別のユーザーにはすべての Google Cloud プロジェクトのログへのアクセス権を付与できます。
Google Cloud エコシステムでのログの使用
次のセクションでは、より広範な Google Cloud でログを使用する方法について説明します。
ログベースの指標
ログベースの指標は、ログエントリの内容から派生した Cloud Monitoring 指標です。たとえば、Cloud Logging によって受信された Google Cloud プロジェクトに対するログエントリが、Google Cloud プロジェクトのいずれかの指標のフィルタに一致すると、そのログエントリは指標データでカウントされます。
ログベースの指標は、ログベースの指標がシステムで定義されているか、ユーザーによって定義されるかに応じて異なる処理を行います。以降のセクションでは、これらの違いについて説明します。
ログベースの指標と除外フィルタ
シンク除外フィルタは、システム定義のログベースの指標に適用されます。この指標は、ログバケットに保存されているログのみをカウントします。
シンク除外フィルタは、ユーザー定義のログベースの指標には適用されません。Logging バケットに保存されないようにログを除外した場合でも、これらの指標にはそうしたログもカウントされます。
ログベースの指標のスコープ
システム定義のログベースの指標は、Google Cloud プロジェクト レベルで適用されます。 これらの指標は、ログルーターによって計算され、受信した Google Cloud プロジェクトのログにのみ適用されます。
ユーザー定義のログベースの指標は、Google Cloud プロジェクト レベルか、特定のログバケット レベルで適用できます。
- プロジェクト レベルの指標は、システム定義のログベースの指標と同様に計算されます。これらのユーザー定義のログベースの指標は、受信先である Google Cloud プロジェクトのログにのみ適用されます。
バケットレベルの指標は、ログエントリの発生元の Google Cloud プロジェクトに関係なく、受信したログバケット内のログに適用されます。
バケットスコープのログベースの指標によって、以下の場合にログを評価できるログベースの指標を作成できます。
- あるプロジェクトから別のプロジェクトのバケットに転送されるログ。
- 集約シンクを介してバケットに転送されるログ。
詳しくは、ログベースの指標の概要をご覧ください。
サポートされている宛先でのログの検索
転送されるログエントリの形式と、ログを宛先で整理する方法については、シンクの宛先でログを表示するをご覧ください。
一般的なユースケース
ログの転送と保存に関する一般的なユースケースに対処するには、次のドキュメントとチュートリアルをご覧ください。
コンプライアンスのニーズ
データ ガバナンスのために転送を使用する際のベスト プラクティスについては、次のドキュメントをご覧ください。
IAM を使用したアクセス制御
Identity and Access Management（IAM）のロールと権限を使用して Cloud Logging データへのアクセスを制御する方法については、IAM を使用したアクセス制御をご覧ください。
料金
Cloud Logging では、サポートされている宛先へのログの転送で料金を請求されることはありませんが、宛先での料金が発生する場合があります。_Required ログバケットを除き、Cloud Logging では、ログバケットへのログのストリーミングと、ログバケットのデフォルト保持期間よりも長いストレージの料金が請求されます。
Cloud Logging では、ログのコピー、ログスコープの定義、またはログ エクスプローラまたは [ログ分析] ページを介して発行されたクエリには課金されません。
詳細については、次のドキュメントをご覧ください。
- Cloud Logging の料金概要
宛先の費用:
- VPC フローログの生成料金は、Cloud Logging から Virtual Private Cloud フローログを送信して除外した後に適用されます。
次のステップ
Cloud Logging データのルーティングと保存については、次のドキュメントをご覧ください。
サポートされている宛先にログエントリを転送するシンクを作成するには、サポートされている宛先にログを転送するをご覧ください。
フォルダまたは組織のリソースからログエントリを転送できる集約シンクの作成方法については、組織レベルとフォルダレベルのログを照合してサポートされている宛先に転送するをご覧ください。
ログバケットに保存されているログエントリのサブセットへのアクセス権を付与する方法については、ログバケットのログビューを構成するをご覧ください。
- Error Reporting は、ログエントリを分析してエラーを報告できます。ログエントリを分析できるタイミングなど、このサービスの詳細については、Error Reporting の概要をご覧ください。