転送とストレージの概要

このページでは、Cloud Logging がログエントリを処理する方法について説明し、Logging の転送とストレージの主なコンポーネントについて詳述します。

全体的には、Cloud Logging のログエントリの転送と保存は、次のようになります。

Cloud Logging がログエントリをルーティングする方法を示す図。

ログルーターを使用したログの取り込みと転送

以降のセクションでは、ログが Logging によって取り込まれ、シンクを使用してログルーター経由で転送される方法について説明します。

ログルーター

ログエントリが、entries.write の呼び出し中に logName フィールドで指定された Google Cloud リソース に送信されます。

Cloud Logging は Cloud Logging API を介してログエントリを受信し、その過程でログエントリはログルーターを通過します。ログルーターのシンクは、Cloud Logging バケットなど、ログエントリの送信先として設定する必要がある宛先を判別する既存の包含フィルタと除外フィルタと照合して、各ログエントリを確認します。シンクの組み合わせを使用して、複数の宛先にログを転送できます。

ログを確実に転送するため、ログルーターはログを一時的に保存（画像には示されていません）する処理も行い、シンクの一時的な中断から保護します。なお、ログルーターの一時ストレージは、Logging バケットによって提供される長期ストレージとは区別されます。

シンク

シンクは、Cloud Logging がログをルーティングする方法を制御します。シンクを使用すると、ログの一部またはすべてをサポートされている宛先に転送できます。ログの転送方法を制御する理由には、次のようなものがあります。

  • 読み取る可能性は低いものの、コンプライアンスを目的にログを保持するため。
  • バケット内のログを有用な形式で整理する。
  • ログに対してビッグデータ分析ツールを使用するため。
  • 他のアプリケーション、他のリポジトリ、またはサードパーティにログをストリーミングするため。

シンクは、特定の Google Cloud リソース（Cloud プロジェクト、請求先アカウント、フォルダ、組織）に属します。リソースは、ログエントリを受信すると、リソースに含まれるシンクと、有効になっている場合は、リソース階層に属する祖先シンクに従ってログエントリを転送します。ログエントリは、一致する各シンクに関連付けられている宛先に送信されます。

Cloud Logging には、Cloud プロジェクト、請求先アカウント、フォルダ、組織ごとに 2 つのシンク（_Required と _Default）が事前定義されています。リソースで生成されたすべてのログは、これら 2 つのシンクによって自動的に処理され、対応する名前の _Required または _Default バケットに保存されます。

シンクは別々に動作します。事前定義されたシンクがログエントリをどのように処理するかにかかわらず、独自のシンクを作成して、ログの一部またはすべてを選択できる宛先に転送するか、Cloud Logging で保存されないようにログを除外できます。

各シンクを転送する際の動作は、シンクの包含フィルタと除外フィルタを構成することによって制御されます。シンクの構成に応じて、Cloud Logging が受信するすべてのログエントリは、次のカテゴリの 1 つまたは複数に分類されます。

  • Cloud Logging に保存され、他の場所には転送されない

  • Cloud Logging に保存され、さらに、サポートされている宛先へ転送される

  • Cloud Logging には保存されず、サポートされている宛先に転送される

  • Cloud Logging には保存されず、他の場所にも転送されません。

通常は Cloud プロジェクト レベルでシンクを作成しますが、Google Cloud 組織またはフォルダに含まれているリソースからログを組み合わせて転送する場合は、集約シンクを作成します。

ログは Logging API を通過して転送され、新しい転送ルールはそれらのルールが作成された後に書き込まれたログにのみ適用されるため、シンクが作成される前に Logging が受信したログエントリを転送することはできません。ログエントリをさかのぼって転送する必要がある場合は、ログのコピーをご覧ください。

包含フィルタ

新しいシンクの場合、フィルタを指定しないと、すべてのログが一致し、シンクの宛先に転送されます。包含フィルタを設定すると、特定のログを選択するようにシンクを構成できます。1 つ以上の除外フィルタを設定して、シンクの宛先からログを除外することもできます。

シンクを構成する場合、Logging のクエリ言語を使用して包含フィルタを作成します。シンクには複数の除外フィルタを含めることもできます。

Logging が受信したすべてのログエントリは、次のフィルタリング ルールに基づいて転送されます。

  • シンクの除外フィルタは、定義された包含フィルタをすべてオーバーライドします。ログがシンク内の除外フィルタと一致する場合は、定義された包含フィルタに関係なく、シンクと一致しません。ログエントリは、シンクの宛先に転送されません。

  • シンクに包含フィルタが含まれていない場合は、次のように処理されます。

    • ログエントリが除外フィルタと一致する場合は、シンクの宛先に転送されません。
    • ログエントリが除外フィルタと一致しない場合、シンクの宛先に転送されます。空の包含フィルタは、すべてのログを選択します。

  • シンクに包含フィルタが含まれている場合は、次のように処理されます。

    • ログエントリが包含フィルタと一致する場合は、シンクの宛先に転送されます。
    • ログエントリが包含フィルタと一致しない場合は、シンクの宛先に転送されません。

除外フィルタ

シンクを作成するときに、複数の除外フィルタを設定して、一致するログエントリをシンクの宛先へのルーティングや Cloud Logging による取り込みから除外できます。除外フィルタは、Logging クエリ言語を使用して作成します。

ログは、Logging API によって受信された後に除外されます。したがって、ログを除外しても、entries.write API 呼び出しの回数は減りません。

除外されたログエントリは、Logs Explorer や Cloud デバッガでは使用できません。

除外フィルタを使用して明示的に除外されているログエントリ、または Logging のストレージ シンクを持つシンクと一致しないために少なくとも 1 つのログバケットに転送されていないログエントリも、Error Reporting から除外されます。

ユーザー定義のログベースの指標は、含まれるログと除外されたログの両方のログエントリから計算されます。詳細については、ログのモニタリングをご覧ください。

選択できる宛先

ログルーターを使用することによって、特定のログを任意の Cloud プロジェクトのサポートされている宛先に転送できます。Logging でサポートされているシンクの宛先は、次のとおりです。

  • Cloud Storage: Cloud Storage バケットに JSON ファイルで保存。低価格の長期ストレージを提供します。
  • BigQuery: BigQuery データセットにテーブルを作成。ビッグデータ分析機能を提供します。
  • Pub/Sub: Pub/Sub トピックに JSON 形式のメッセージで配信。Splunk などのサードパーティとの Logging の統合がサポートされます。
  • Cloud Logging: ログバケットにログエントリで保持。カスタマイズ可能な保持期間を持つ Cloud Logging のストレージが提供されます。

サポートされている宛先へのログ転送の詳細については、シンクの構成をご覧ください。

ログの保存、表示、管理

次のセクションでは、Cloud Logging でのログの保存方法と、ログを表示して管理する方法について説明します。

ログバケット

Cloud Logging では、Google Cloud プロジェクト、請求先アカウント、フォルダ、組織でログデータを保存して整理するためのコンテナとしてログバケットを使用し、ログデータを保存、整理します。Cloud Logging に保存したログはインデックスに登録されて最適化され、ログをリアルタイムで分析できるように配信されます。Cloud Logging バケットは、似たような名前を持つ Cloud Storage バケットとは異なるストレージ エンティティです。

Logging では、Cloud プロジェクト、請求先アカウント、フォルダ、組織ごとに、_Required と _Default という 2 つのログバケットが自動的に作成されます。Logging は、_Required と _Default という名前のシンクを自動的に作成します。デフォルトの構成では、対応する名前のバケットにログが転送されます。

_Default ログバケットに転送されるログを無効にできます。_Required バケットの転送ルールは変更できません。

また、Cloud プロジェクトに対してユーザー定義バケットを作成できます。

シンクを作成して、ログのすべてまたは一部を任意のログバケットに転送します。この柔軟性により、ログを保存する Cloud プロジェクトと、それらのログとともに保存する他の Cloud プロジェクトを選択できます。

詳細については、ログバケットを構成するをご覧ください。

_Required ログバケット

Cloud Logging は、次の種類のログを自動的に _Required バケットに転送します。

Cloud Logging は、このバケットのログを 400 日間保持します。この保持期間は変更できません。

_Required バケットの変更や削除はできません。_Required シンクを無効にすることはできません。このシンクはログを _Required バケットに転送します。

取り込み料金とストレージ料金は、_Required ログバケットに保存されたログデータには適用されません。

_Default ログバケット

_Required バケットによって取り込まれなかったログエントリは、_Default シンクを無効にするか編集しない限り、_Default シンクによって _Default バケットに転送されます。シンクを変更する手順については、シンクの管理をご覧ください。

_Default バケットは削除できません。

バケットのカスタム保持を設定しない限り、_Default バケットのログは 30 日間保持されます。

Cloud Logging の料金は、_Default バケット内のログデータに適用されます。

ユーザー定義のログバケット

任意の Cloud プロジェクトでユーザー定義のログバケットを作成することもできます。ユーザー定義のログバケットにシンクを適用すると、ログの任意のサブセットを任意のログバケットに転送でき、ログを保存する Cloud プロジェクトと、それらのログとともに保存するその他のログを選択できます。

たとえば、Project-A で生成されたログに関して、そのログを Project-A または Project-B のユーザー定義のバケットに転送するようにシンクを構成できます。

Cloud Logging の料金は、ログの種類に関係なく、このバケットに保持されているログデータに適用されます。

バケットのカスタム保持を構成できます。

ユーザー定義のログバケットの管理（削除や更新など）については、ログバケットの構成と管理をご覧ください。

リージョン指定

ログバケットはリージョン リソースです。ログの保存、インデックス登録、検索を行うインフラストラクチャは、特定の地理的ロケーションにあります。Google はそのインフラストラクチャを管理して、アプリケーションがそのリージョン内のゾーン全体で冗長的に利用できるようにします。

ログデータの場所の詳細については、Cloud Logging のデータ リージョンをご覧ください。

ログバケットを作成する際に、次のいずれかのリージョンにログを保存することを選択できます。

大陸 地域
アジア 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-west1
europe-west2
europe-west3
europe-west4
europe-west6
北アメリカ northamerica-northeast1
northamerica-northeast2
us-central1
us-east1
us-east4
us-west1
us-west2
us-west3
us-west4
南アメリカ southamerica-east1

これらのリージョンに加えて、ロケーションを global に設定することもできます。この場合、ログが物理的に保存される場所を指定する必要はありません。

組織ポリシー

組織のポリシーを作成して、組織でコンプライアンスと規制のニーズを満たせるようにできます。組織のポリシーを使用すると、組織が新しいログバケットを作成できるリージョンを指定できます。特定のリージョンで新しいログバケットを作成できないように組織を制限することもできます。

Cloud Logging では、既存のログバケットに対して新しく作成した組織のポリシーが適用されません。新しいログバケットにのみ、このポリシーが適用されます。

ロケーション ベースの組織ポリシーの作成については、リソース ロケーションの制限をご覧ください。

ユーザーの維持

Cloud Logging は、ログが保持されるログバケット タイプに適用される保持ルールに従って、ログを保持します。

1～3,650 日の範囲でログを保持するように Cloud Logging を構成できます。カスタム保持ルールは、ログの種類やログが別の場所からコピーされたかどうかに関わらず、バケット内のすべてのログに適用されます。

ログバケットの保持ルールの設定については、カスタム保持の構成をご覧ください。

ログビュー

ログビューを使用すると、ログバケット内のログにアクセスできるユーザーを制御できます。

Cloud Logging は、すべてのログを表示するすべてのバケットに _AllLogs ビューを自動的に作成します。また、Cloud Logging は、_Default という _Default バケットを作成します。このバケットでは、データアクセス監査ログ以外のすべてのログが表示されます。

ログバケットには複数の Cloud プロジェクトのログを格納できるため、それぞれのユーザーがログを表示できる Cloud プロジェクトを制御することをおすすめします。そうしたバケットへのアクセスは、カスタム ログビューを作成することでより細かく制御できます。

詳細については、ログビューの管理をご覧ください。

Google Cloud エコシステムでのログの使用

次のセクションでは、より広範な Google Cloud でログを使用する場合について説明します。

ログベースの指標

ログベースの指標は、ログエントリの内容に基づく Cloud Monitoring 指標です。Cloud Logging によって受信された Cloud プロジェクトに対するログエントリが、Cloud プロジェクトのいずれかの指標のフィルタに一致すると、そのログエントリは指標データに反映されます。

シンク除外フィルタは、Cloud プロジェクトによって取り込まれるログのみをカウントするシステム定義のユーザー指標に適用されます。

シンク除外フィルタは、ユーザー定義のログベースの指標には適用されません。Cloud Logging API による取り込みからログを除外し、そのログが Logging バケットに保存されていない場合でも、ログベースの指標にそのようなログがカウントされる場合があります。

ログベースの指標は、Cloud プロジェクト レベルで適用されます。これらの指標はログルーターによって計算され、受信した Cloud プロジェクトのログにのみ適用されます。

詳細については、ログベースの指標の概要をご覧ください。

サポートされている宛先でのログの検索

転送されるログエントリの形式と、ログを宛先で整理する方法については、シンクの宛先でログを表示するをご覧ください。

一般的なユースケース

ログの転送と保存に関する一般的なユースケースに対処するには、次のドキュメントとチュートリアルをご覧ください。

コンプライアンスのニーズ

データ ガバナンスのために転送を使用する際のベスト プラクティスについては、次のドキュメントをご覧ください。

IAM を使用したアクセス制御

Identity and Access Management（IAM）のロールと権限を使用して Cloud Logging データへのアクセスを制御する方法については、IAM を使用したアクセス制御をご覧ください。

料金

取り込みとストレージの料金について詳しくは、Cloud Logging の料金情報をご覧ください。

Cloud Logging ではログの転送は課金されませんが、転送先での請求が適用されることがあります。詳細については、該当するサービスの料金詳細をご覧ください。

Cloud Logging から Virtual Private Cloud フローログを送信して除外した場合は、エクスポート先料金に加え VPC フローログの生成料金が適用されることにもご注意ください。

次のステップ

Cloud Logging データのルーティングと保存については、次のドキュメントをご覧ください。