このドキュメントでは、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 はログを破棄し、エラーログが生成され、シンク構成のエラーを通知するメールが届きます。
なお、ログルーターの一時ストレージは、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 を通過して転送され、新しい転送ルールはそれらのルールが作成された後に書き込まれたログにのみ適用されるため、シンクが作成される前に Logging が受信したログエントリを転送することはできません。ログエントリをさかのぼって転送する必要がある場合は、ログのコピーをご覧ください。
包含フィルタ
新しいシンクでは、フィルタを指定しないと、すべてのログが一致し、シンクのエクスポート先に転送されます。一致フィルタを設定することで、特定のログを選択するようにシンクを構成できます。1 つ以上の除外フィルタを設定して、シンクの宛先からログを除外することもできます。
シンクを構成する場合は、Logging のクエリ言語を使用して一致フィルタを作成します。シンクには、複数の除外フィルタを含めることもできます。
Logging が受信したすべてのログエントリは、次のフィルタリング ルールに基づいて転送されます。
シンクの除外フィルタは、定義された包含フィルタをすべてオーバーライドします。ログがシンク内の除外フィルタと一致する場合は、定義された包含フィルタに関係なく、シンクと一致しません。ログエントリは、シンクの宛先に転送されません。
シンクに包含フィルタが含まれていない場合は、次のように処理されます。
- ログエントリが除外フィルタと一致する場合は、シンクの宛先に転送されません。
- ログエントリが除外フィルタと一致しない場合は、シンクのエクスポート先に転送されます。空の一致フィルタでは、すべてのログが選択されます。
シンクに包含フィルタが含まれている場合は、次のように処理されます。
- ログエントリが包含フィルタと一致する場合は、シンクの宛先に転送されます。
- ログエントリが包含フィルタと一致しない場合は、シンクの宛先に転送されません。
除外フィルタ
シンクを作成するときに、複数の除外フィルタを設定できます。除外フィルタを使用すると、一致するログエントリをシンクの宛先へのルーティングやログバケットへの保存から除外できます。除外フィルタは、Logging クエリ言語を使用して作成します。
ログエントリは、Logging API によって受信された後に除外されるため、これらのログエントリは entries.write API 割り当てを消費します。ログエントリを除外して entries.write API 呼び出しの数を減らすことはできません。
除外されたログエントリはログ エクスプローラでは使用できません。
除外フィルタを使用して明示的に除外されているログエントリ、または Logging のストレージ シンクを持つシンクと一致しないために少なくとも 1 つのログバケットに転送されていないログエントリも、Error Reporting から除外されます。したがって、これらのログは障害のトラブルシューティングに使用できません。
ユーザー定義のログベースの指標は、含まれるログと除外されたログの両方のログエントリから計算されます。詳細については、ログのモニタリングをご覧ください。
選択できる宛先
ログルーターを使用することによって、特定のログを任意の Google Cloud プロジェクトのサポートされている宛先に転送できます。Logging でサポートされているシンクのエクスポート先は、次のとおりです。
- Cloud Logging バケット: Cloud Logging のストレージが提供されます。ログバケットには、複数の Google Cloud プロジェクトで受信するログエントリを保存できます。Log Analytics を使用するようにログバケットをアップグレードし、リンクされた BigQuery データセットを作成すると、Cloud Logging データを他のデータと結合できます。ログバケットに保存されているログの表示については、ログのクエリと表示の概要と Cloud Logging バケットにルーティングされたログの表示をご覧ください。
- BigQuery データセット: BigQuery データセットにログエントリのストレージを提供します。保存されたログエントリに対して、ビッグデータ分析機能を使用できます。Cloud Logging のデータを他のデータソースと組み合わせるには、Log Analytics を使用するようにログバケットをアップグレードし、リンクされた BigQuery データセットを作成することをおすすめします。BigQuery に転送されたログエントリの表示については、BigQuery に転送されたログを表示するをご覧ください。
- Cloud Storage バケット: Cloud Storage にログエントリを保存します。ログエントリは、JSON ファイルとして保存されます。 Cloud Storage に転送されたログエントリの表示については、Cloud Storage に転送されたログを表示するをご覧ください。
- Pub/Sub トピック: サードパーティ統合をサポートします。ログエントリは JSON 形式にフォーマットされ、Pub/Sub トピックにルーティングされます。Pub/Sub に転送されたログエントリの表示については、Pub/Sub に転送されたログを表示するをご覧ください。
- Splunk: Splunk をサポートします。ログエントリを Pub/Sub トピックにルーティングし、Splunk を使用してそのトピックに登録する必要があります。
- Google Cloud プロジェクト: ログエントリを異なる Google Cloud プロジェクトにルーティングします。ログエントリを別の Google Cloud プロジェクトにルーティングすると、宛先のプロジェクトのログルーターがログエントリを受信し、それらを処理します。宛先プロジェクトのシンクは、受信したログエントリのルーティング方法を決定します。 宛先プロジェクトがログエントリを宛先プロジェクトが所有するログバケットにルーティングすると、Error Reporting によってログエントリを分析できます。
- その他のリソース: 異なるプロジェクトにあるサポートされている宛先にログエントリを転送します。使用するパスについては、宛先パスの形式をご覧ください。
詳細については、サポートされている宛先にログをルーティングするをご覧ください。
ログの保存、表示、管理
次のセクションでは、ログが 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 プロジェクトと、そのログとともに保存するほかのログを選択できます。
詳細については、ログバケットを構成するをご覧ください。
_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 プロジェクトと、それらのログとともに保存するその他のログを選択できます。
たとえば、Project-A で生成されたログに関して、そのログを Project-A または Project-B のユーザー定義のバケットに転送するようにシンクを構成できます。
バケットのカスタム保持を構成できます。
ユーザー定義のログバケットの管理（削除や更新など）については、ログバケットの構成と管理をご覧ください。
リージョン指定
ログバケットは、リージョン リソースです。ログの保存、インデックス登録、検索を行うインフラストラクチャは特定の地理的な場所にあります。Google は、アプリケーションがそのリージョン内のゾーン全体で冗長性が確保されるように、そのインフラストラクチャを管理します。
ログバケットを作成するとき、または組織レベルのリージョン ポリシーを設定するときに、次のいずれかのリージョンにログを保存することを選択できます。
アフリカ
| リージョン名 | リージョンの説明 | Log Analytics のサポート |
|---|---|---|
africa-south1 |
ヨハネスブルグ | ○ |
南北アメリカ
| リージョン名 | リージョンの説明 | Log Analytics のサポート |
|---|---|---|
northamerica-northeast1 |
モントリオール | はい |
northamerica-northeast2 |
トロント | はい |
southamerica-east1 |
サンパウロ | はい |
southamerica-west1 |
サンティアゴ | はい |
us-central1 |
アイオワ | はい |
us-east1 |
サウスカロライナ | はい |
us-east4 |
北バージニア | はい |
us-east5 |
コロンバス | はい |
us-south1 |
ダラス | はい |
us-west1 |
オレゴン | はい |
us-west2 |
ロサンゼルス | はい |
us-west3 |
ソルトレイクシティ | はい |
us-west4 |
ラスベガス | はい |
アジア太平洋
| リージョン名 | リージョンの説明 | Log Analytics のサポート |
|---|---|---|
asia-east1 |
台湾 | はい |
asia-east2 |
香港 | はい |
asia-northeast1 |
東京 | はい |
asia-northeast2 |
大阪 | はい |
asia-northeast3 |
ソウル | はい |
asia-south1 |
ムンバイ | はい |
asia-south2 |
デリー | はい |
asia-southeast1 |
シンガポール | はい |
asia-southeast2 |
ジャカルタ | はい |
australia-southeast1 |
シドニー | はい |
australia-southeast2 |
メルボルン | はい |
ヨーロッパ
| リージョン名 | リージョンの説明 | Log Analytics のサポート |
|---|---|---|
europe-central2 |
ワルシャワ | はい |
europe-north1 |
フィンランド | はい |
europe-southwest1 |
マドリッド | はい |
europe-west1 |
ベルギー | はい |
europe-west2 |
ロンドン | はい |
europe-west3 |
フランクフルト | はい |
europe-west4 |
オランダ | はい |
europe-west6 |
チューリッヒ | はい |
europe-west8 |
ミラノ | はい |
europe-west9 |
パリ | はい |
europe-west10 |
ベルリン | はい |
europe-west12 |
トリノ | はい |
中東
| リージョン名 | リージョンの説明 | Log Analytics のサポート |
|---|---|---|
me-central1 |
ドーハ | はい |
me-central2 |
ダンマーム | はい |
me-west1 |
テルアビブ | はい |
その他
| リージョン名 | リージョンの説明 | Log Analytics のサポート |
|---|---|---|
eu |
欧州連合内のデータセンターに保存されているログ。追加の冗長性は保証されません | はい |
us |
米国内のデータセンターに保存されているログ。追加の冗長性は保証されません | はい |
global |
世界中の任意のデータセンターに保存されているログ。追加の冗長性は保証されません | はい |
ロケーションは、これらのリージョンの他にも、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 データのルーティングと保存については、次のドキュメントをご覧ください。
サポートされている宛先にログを転送するシンクを作成するには、シンクの構成をご覧ください。
転送とシンクのトラブルシューティング情報については、転送とシンクのトラブルシューティングをご覧ください。