このドキュメントでは、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 トピック: Splunk や Datadog などのサードパーティ製品との統合が可能になります。ログエントリは JSON 形式にフォーマットされ、Pub/Sub トピックにルーティングされます。トピックは、ログエントリの発生元のプロジェクトに配置することも、別のプロジェクトに配置することもできます。Pub/Sub にルーティングされたログエントリの表示については、Pub/Sub にルーティングされたログを表示するをご覧ください。
- Google Cloud プロジェクト: ログエントリを別の Google Cloud プロジェクトにルーティングします。この構成では、ルーティング先のプロジェクトのシンクによってログエントリが処理されます。
シンクの作成方法と、 Google Cloud コンソールまたは API の使用時に表示されるオプションの構成方法については、サポートされている宛先にログをルーティングするをご覧ください。
ログの保存、表示、管理
次のセクションでは、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 |
世界中の任意のデータセンターに保存されているログ。ログが別のデータセンターに移動される場合があります。 Google Cloudの他のグローバル リソースとは異なり、Cloud Logging のグローバル ログバケットは、リージョン ログバケットと比較して、追加の冗長性が保証されません。 |
マルチリージョン: EU と米国
| リージョン名 | リージョンの説明 |
|---|---|
eu |
欧州連合内の任意のデータセンターに保存されているログ。ログが別のデータセンターに移動される場合があります。追加の冗長性は保証されません。 |
us |
米国内の任意のデータセンターに保存されているログ。ログが別のデータセンターに移動される場合があります。追加の冗長性は保証されません。 |
アフリカ
| リージョン名 | リージョンの説明 |
|---|---|
africa-south1 |
ヨハネスブルグ |
南北アメリカ
| リージョン名 | リージョンの説明 |
|---|---|
northamerica-northeast1 |
モントリオール |
northamerica-northeast2 |
トロント |
northamerica-south1 |
メキシコ |
southamerica-east1 |
サンパウロ |
southamerica-west1 |
サンティアゴ |
us-central1 |
アイオワ |
us-east1 |
サウスカロライナ州 |
us-east4 |
北バージニア |
us-east5 |
コロンバス |
us-south1 |
ダラス |
us-west1 |
オレゴン |
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-north2 |
ストックホルム |
europe-southwest1 |
マドリード |
europe-west1 |
ベルギー |
europe-west2 |
ロンドン |
europe-west3 |
フランクフルト |
europe-west4 |
オランダ |
europe-west6 |
チューリッヒ |
europe-west8 |
ミラノ |
europe-west9 |
パリ |
europe-west10 |
ベルリン |
europe-west12 |
トリノ |
中東
| リージョン名 | リージョンの説明 |
|---|---|
me-central1 |
ドーハ |
me-central2 |
ダンマーム |
me-west1 |
テルアビブ |
ロケーションを global に設定すると、ログエントリが物理的に保存される場所を指定する必要はありません。
特定のストレージ リージョンを、組織またはフォルダで作成された _Default バケットと _Required バケットに自動的に適用できます。詳しくは、組織とフォルダのデフォルト設定を構成するをご覧ください。
組織のポリシー
組織のポリシーを作成して、組織でコンプライアンスと規制のニーズを満たせるようにできます。組織のポリシーを使用すると、組織が新しいログバケットを作成できるリージョンを指定できます。特定のリージョンで新しいログバケットを作成できないように組織を制限することもできます。
Cloud Logging では、既存のログバケットに対して新しく作成した組織のポリシーが適用されません。新しいログバケットにのみ、このポリシーが適用されます。
ロケーション ベースの組織のポリシーの作成については、リソース ロケーションを制限するをご覧ください。
また、組織またはフォルダ内の _Default バケットと _Required バケットのデフォルトのストレージ ロケーションを構成することもできます。データの保存先を制限する組織のポリシーを構成する場合は、指定するデフォルトのストレージ ロケーションがその制約と一致するようにする必要があります。詳しくは、組織とフォルダのデフォルト設定を構成するをご覧ください。
保持
Cloud Logging は、ログが保持されるログバケット タイプに適用される保持ルールに従ってログを保持します。さまざまなタイプのログの保持期間については、割り当てと上限をご覧ください。
Cloud Logging のログ保持期間は、1～3,650 日の間で構成できます。カスタム保持ルールは、ログの種類やログが別の場所からコピーされたかどうかに関わらず、バケット内のすべてのログに適用されます。
ログバケットの保持ルールの設定については、カスタム保持の構成をご覧ください。
ログビュー
ログビューを使用すると、ログバケットに保存されているログエントリのサブセットに対してのみユーザーにアクセス権を付与できます。ログビューの構成方法と、特定のログビューへのアクセス権を付与する方法については、ログバケットのログビューを構成するをご覧ください。
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 の概要をご覧ください。