このドキュメントでは、Cloud Logging がログエントリを処理する方法について説明し、Logging の転送とストレージの主なコンポーネントについて詳述します。 転送とは、新しく到着したログエントリの処理方法を決定するために Cloud Logging が使用するプロセスのことです。ログエントリを、Logging のようなログエントリを保存する宛先や、Pub/Sub に転送できます。Pub/Sub トピックをサブスクライブすることで、ログエントリを Google Cloud からエクスポートして、サードパーティ プラットフォームなどの別の宛先に転送できます。
全体的には、Cloud Logging のログエントリの転送と保存は、次のようになります。
ログルーターを使用したログの取り込みと転送
以降のセクションでは、ログが Logging によって取り込まれ、シンクを使用してログルーター経由で転送される方法について説明します。
ログルーター
ログエントリが、entries.write の呼び出し中に logName フィールドで指定された Google Cloud リソース に送信されます。
Cloud Logging は Cloud Logging API を介してログエントリを受信し、その過程でログエントリはログルーターを通過します。Log Router のシンクは、ログエントリの送信先として設定する必要がある宛先（Cloud Logging バケットなど）を判別する既存の包含フィルタおよび除外フィルタと照合して各ログエントリを確認します。シンクの組み合わせを使用して、複数の宛先にログを転送できます。
ログを確実に転送するため、ログルーターはログを一時的に保存（画像には示されていません）する処理も行い、シンクの一時的な中断から保護します。なお、ログルーターの一時ストレージは、Logging バケットによって提供される長期ストレージとは区別されます。
タイムスタンプが過去ログの保持期間を超えているか、将来の 24 時間を超えるタイムスタンプがある受信ログエントリは破棄されます。
シンク
シンクは、Cloud Logging がログをルーティングする方法を制御します。シンクを使用すると、ログの一部またはすべてをサポートされている宛先に転送できます。ログの転送方法を制御する理由には、次のようなものがあります。
- 読み取る可能性は低いものの、コンプライアンスを目的にログを保持するため。
- バケット内のログを有用な形式で整理する。
- ログに対してビッグデータ分析ツールを使用するため。
- 他のアプリケーション、他のリポジトリ、またはサードパーティにログをストリーミングするため。 たとえば、サードパーティのプラットフォームでログを表示できるように Google Cloud からログをエクスポートする場合は、ログエントリを Pub/Sub に転送するようにシンクを構成します。
シンクは、特定の 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 が受信したすべてのログエントリは、次のフィルタリング ルールに基づいて転送されます。
シンクの除外フィルタは、定義された包含フィルタをすべてオーバーライドします。ログがシンク内の除外フィルタと一致する場合は、定義された包含フィルタに関係なく、シンクと一致しません。ログエントリは、シンクの宛先に転送されません。
シンクに包含フィルタが含まれていない場合は、次のように処理されます。
- ログエントリが除外フィルタと一致する場合は、シンクの宛先に転送されません。
- ログエントリが除外フィルタと一致しない場合は、シンクのエクスポート先に転送されます。空の包含フィルタは、すべてのログを選択します。
シンクに包含フィルタが含まれている場合は、次のように処理されます。
- ログエントリが包含フィルタと一致する場合は、シンクの宛先に転送されます。
- ログエントリが包含フィルタと一致しない場合は、シンクの宛先に転送されません。
除外フィルタ
シンクを作成するときに、複数の除外フィルタを設定して、一致するログエントリをシンクの宛先へのルーティングや Cloud Logging による取り込みから除外できます。除外フィルタは、Logging クエリ言語を使用して作成します。
ログエントリは Logging API で受信された後に除外されるため、これらのログエントリでは entries.write API の割り当てが消費されます。ログエントリを除外することで、entries.write API 呼び出しの数を減らすことはできません。
除外されたログエントリは、Logs Explorer や Cloud デバッガでは使用できません。
除外フィルタを使用して明示的に除外されているログエントリ、または Logging のストレージ シンクを持つシンクと一致しないために少なくとも 1 つのログバケットに転送されていないログエントリも、Error Reporting から除外されます。 したがって、これらのログは障害のトラブルシューティングに使用できません。
ユーザー定義のログベースの指標は、含まれるログと除外されたログの両方のログエントリから計算されます。詳細については、ログのモニタリングをご覧ください。
除外されていないログエントリでは、料金が発生する可能性があります。詳細については、Cloud Logging の料金をご覧ください。
選択できる宛先
ログルーターを使用することによって、特定のログを任意の 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 ログバケットへのログを転送する _Default シンクは無効にできます。組織で作成した新しい Cloud プロジェクトやフォルダで作成した _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 は、アプリケーションがそのリージョン内のゾーン全体で冗長性が確保されるように、そのインフラストラクチャを管理します。
ログバケットを作成するか、組織レベルのリージョン ポリシーを設定するときに、次のいずれかのリージョンにログを保存できます。
南北アメリカ
| リージョン名 | リージョンの説明 |
|---|---|
northamerica-northeast1 |
モントリオール |
northamerica-northeast2 |
トロント |
southamerica-east1 |
サンパウロ |
southamerica-west1 |
サンティアゴ |
us-central1 |
アイオワ |
us-east1 |
サウスカロライナ |
us-east4 |
北バージニア |
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-southwest1 |
マドリッド |
europe-west1 |
ベルギー |
europe-west2 |
ロンドン |
europe-west3 |
フランクフルト |
europe-west4 |
オランダ |
europe-west6 |
チューリッヒ |
europe-west8 |
ミラノ |
europe-west9 |
パリ |
中東
| リージョン名 | リージョンの説明 |
|---|---|
me-west1 |
テルアビブ |
ロケーションは、これらのリージョンの他にも、global に設定できます。この設定では、ログが物理的に保存される場所を指定する必要がありません。
特定のストレージ リージョンを、組織で作成された新しい _Default バケットと _Required バケットに自動的に適用する場合は、デフォルトのリソース ロケーションを構成できます。
ログデータの場所の詳細については、Cloud Logging のデータ リージョンをご覧ください。
組織ポリシー
組織のポリシーを作成して、組織でコンプライアンスと規制のニーズを満たせるようにできます。組織のポリシーを使用すると、組織が新しいログバケットを作成できるリージョンを指定できます。特定のリージョンで新しいログバケットを作成できないように組織を制限することもできます。
Cloud Logging では、既存のログバケットに対して新しく作成した組織のポリシーが適用されません。新しいログバケットにのみ、このポリシーが適用されます。
ロケーション ベースの組織のポリシーの作成については、リソース ロケーションを制限するをご覧ください。
さらに、デフォルトのリソース ロケーションを構成して、組織で作成された _Default バケットと _Required バケットに適用するストレージ リージョンを選択できます。
維持率
Cloud Logging は、ログが保持されるログバケット タイプに適用される保持ルールに従って、ログを保持します。
1～3,650 日の範囲でログを保持するように Cloud Logging を構成できます。カスタム保持ルールは、ログの種類やログが別の場所からコピーされたかどうかに関わらず、バケット内のすべてのログに適用されます。
ログバケットの保持ルールの設定については、カスタム保持の構成をご覧ください。
ログビュー
ログビューを使用すると、ログバケット内のログにアクセスできるユーザーを制御できます。
ログバケットごとに、Cloud Logging は自動的に _AllLogs ビューを作成します。このビューには、そのバケットに保存されているすべてのログが表示されます。また、Cloud Logging は、_Default という _Default バケットのビューも作成します。_Default バケットの _Default ビューには、データアクセスの監査ログを除くすべてのログが表示されます。_AllLogs ビューと _Default ビューは編集できず、削除できません。
カスタム ログビューでは、ログデータへのアクセスを高度かつきめ細かく制御できます。たとえば、一元管理された Cloud プロジェクトに、組織のすべてのログを保存するシナリオを考えてみます。ログバケットには、複数の Cloud プロジェクトのログを格納できるため、それぞれのユーザーがログを表示できる Cloud プロジェクトを制御することをおすすめします。カスタム ログビューを使用すると、あるユーザーに 1 つの Cloud プロジェクトのログへのアクセス権のみを付与しつつ、別のユーザーにはすべての Cloud プロジェクトのログへのアクセス権を付与できます。
ログビューの構成については、ログバケットへのアクセスを管理するをご覧ください。
Google Cloud エコシステムでのログの使用
次のセクションでは、より広範な Google Cloud でログを使用する場合について説明します。
ログベースの指標
ログベースの指標は、ログエントリの内容から派生する Cloud Monitoring 指標です。たとえば、Cloud Logging によって受信された Cloud プロジェクトに対するログエントリが、Cloud プロジェクトのいずれかの指標のフィルタに一致すると、そのログエントリは指標データでカウントされます。
ログベースの指標は、ログベースの指標がシステムで定義されているか、ユーザーによって定義されるかに応じて異なる処理を行います。以降のセクションでは、これらの違いについて説明します。
ログベースの指標と除外フィルタ
シンク除外フィルタは、Cloud プロジェクトによって取り込まれるログのみをカウントするシステム定義のログベースの指標に適用されます。
シンク除外フィルタは、ユーザー定義のログベースの指標には適用されません。Cloud Logging API が取り込まないようにログを除外し、どの Logging バケットにも保存されないようにした場合でも、これらの指標にはそうしたログもカウントされます。
ログベースの指標のスコープ
システム定義のログベースの指標は、Cloud プロジェクト レベルで適用されます。これらの指標は、ログルーターによって計算され、受信した Cloud プロジェクトのログにのみ適用されます。
ユーザー定義ログベースの指標は、Cloud プロジェクト レベルか、特定のログバケット レベルで適用できます。
- プロジェクト レベルの指標は、システム定義のログベースの指標と同様に計算されます。これらのユーザー定義のログベースの指標は、受信した Cloud プロジェクトのログにのみ適用されます。
プレビュー: バケットレベルの指標は、ログエントリの発生元の Cloud プロジェクトに関係なく、受信したログバケット内のログに適用されます。
バケットレベルのログベースの指標を使用すると、次のような場合にログを評価できるログベースの指標を作成できます。
- あるプロジェクトから別のプロジェクトのバケットに転送されるログ。
- 集約シンクを介してバケットに転送されるログ。
詳細については、ログベースの指標の概要をご覧ください。
サポートされている宛先でのログの検索
転送されるログエントリの形式と、ログを宛先で整理する方法については、シンクの宛先でログを表示するをご覧ください。
一般的なユースケース
ログの転送と保存に関する一般的なユースケースに対処するには、次のドキュメントとチュートリアルをご覧ください。
コンプライアンスの必要性
データ ガバナンスのために転送を使用する際のベスト プラクティスについては、次のドキュメントをご覧ください。
IAM を使用したアクセス制御
Identity and Access Management（IAM）のロールと権限を使用して Cloud Logging データへのアクセスを制御する方法については、IAM を使用したアクセス制御をご覧ください。
料金
取り込みとストレージの料金について詳しくは、Cloud Logging の料金情報をご覧ください。
Cloud Logging ではログの転送は課金されませんが、転送先での請求が適用されることがあります。詳細については、該当するサービスの料金詳細をご覧ください。
Cloud Logging から Virtual Private Cloud フローログを送信して除外した場合は、エクスポート先料金に加え VPC フローログの生成料金が適用されることにもご注意ください。
次のステップ
Cloud Logging データのルーティングと保存については、次のドキュメントをご覧ください。
サポートされている宛先にログを転送するシンクを作成するには、シンクの構成をご覧ください。
転送とシンクのトラブルシューティング情報については、転送とシンクのトラブルシューティングをご覧ください。