このドキュメントでは、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 が受信したすべてのログエントリは、次のフィルタリング ルールに基づいて転送されます。
シンクの除外フィルタは、定義された包含フィルタをすべてオーバーライドします。ログがシンク内の除外フィルタと一致する場合は、定義された包含フィルタに関係なく、シンクと一致しません。ログエントリは、シンクの宛先に転送されません。
シンクに包含フィルタが含まれていない場合は、次のように処理されます。
- ログエントリが除外フィルタと一致する場合は、シンクの宛先に転送されません。
- ログエントリが除外フィルタと一致しない場合は、シンクのエクスポート先に転送されます。空の包含フィルタは、すべてのログを選択します。
シンクに包含フィルタが含まれている場合は、次のように処理されます。
- ログエントリが包含フィルタと一致する場合は、シンクの宛先に転送されます。
- ログエントリが包含フィルタと一致しない場合は、シンクの宛先に転送されません。
除外フィルタ
シンクを作成するときに、複数の除外フィルタを設定できます。除外フィルタを使用すると、一致するログエントリをシンクの宛先へのルーティングや Cloud Logging による取り込みから除外できます。除外フィルタは、Logging クエリ言語を使用して作成します。
ログエントリは、Logging API が受信すると除外されるため、entries.write API 割り当てが消費されます。ログエントリを除外して entries.write API 呼び出しの数を減らすことはできません。
除外されたログエントリはログ エクスプローラでは使用できません。
除外フィルタを使用して明示的に除外されているログエントリ、または Logging のストレージ シンクを持つシンクと一致しないために少なくとも 1 つのログバケットに転送されていないログエントリも、Error Reporting から除外されます。したがって、これらのログは障害のトラブルシューティングに使用できません。
ユーザー定義のログベースの指標は、含まれるログと除外されたログの両方のログエントリから計算されます。詳細については、ログのモニタリングをご覧ください。
除外されていないログエントリでは、料金が発生する可能性があります。詳細については、Cloud Logging の料金情報をご覧ください。
選択できる宛先
ログルーターを使用することによって、特定のログを任意の Google Cloud プロジェクトのサポートされている宛先に転送できます。Logging でサポートされているシンクのエクスポート先は、次のとおりです。
- Cloud Logging ログバケット: Cloud Logging にストレージを提供します。ログバケットには、複数の Google Cloud プロジェクトに取り込まれたログを保存できます。Log Analytics を使用するようにログバケットをアップグレードし、リンクされた BigQuery データセットを作成すると、Cloud Logging データを他のデータと結合できます。ログバケットに保存されているログの表示については、ログのクエリと表示の概要と Cloud Logging バケットにルーティングされたログの表示をご覧ください。
- Google Cloud プロジェクト: ログエントリを異なる Google Cloud プロジェクトにルーティングします。ログを異なる Google Cloud プロジェクトにルーティングすると、宛先のプロジェクトのログルーターがログを受信し、それらを処理します。宛先プロジェクトのシンクは、受信したログエントリ。ルーティング方法を決定します。
- Pub/Sub トピック: Splunk などのサードパーティ統合をサポートします。ログエントリは JSON 形式にフォーマットされ、Pub/Sub トピックにルーティングされます。Pub/Sub にルーティングされたログの表示については、Pub/Sub にルーティングされたログを表示するをご覧ください。
- BigQuery データセット: BigQuery データセットにログエントリのストレージを提供します。保存されたログに対して、ビッグデータ分析機能を使用できます。Cloud Logging のデータを他のデータソースと組み合わせるには、Log Analytics を使用するようにログバケットをアップグレードし、リンクされた BigQuery データセットを作成することをおすすめします。BigQuery に転送されたログの表示については、BigQuery に転送されたログを表示するをご覧ください。
- Cloud Storage バケット: Cloud Storage にログデータを保存します。ログエントリは、JSON ファイルとして保存されます。 Cloud Storage にルーティングされたログの表示については、Cloud Storage にルーティングされたログを表示するをご覧ください。
詳細については、サポートされている宛先にログをルーティングするをご覧ください。
ログの保存、表示、管理
次のセクションでは、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 バケットに転送します。
Cloud Logging は、_Required バケットのログを 400 日間保持します。この保持期間は変更できません。
_Required バケットの変更や削除はできません。_Required シンクを無効にすることはできません。このシンクはログを _Required バケットに転送します。
取り込み料金とストレージ料金は、_Required ログバケットに保存されたログデータには適用されません。
_Default ログバケット
_Required バケットによって取り込まれなかったログエントリは、_Default シンクを無効にするか編集しない限り、_Default シンクによって _Default バケットに転送されます。シンクを変更する手順については、シンクの管理をご覧ください。
Cloud Logging は、次の種類のログを自動的に _Default バケットに転送します。
バケットのカスタム保持を構成しない限り、Cloud Logging は _Default バケットのログを 30 日間保持します。
_Default バケットは削除できません。
Cloud Logging の料金は、_Default バケット内のログデータに適用されます。
ユーザー定義のログバケット
任意の Google Cloud プロジェクトでユーザー定義のログバケットを作成することもできます。ユーザー定義のログバケットにシンクを適用すると、ログの任意のサブセットを任意のログバケットに転送でき、ログを保存する Google Cloud プロジェクトと、それらのログとともに保存するその他のログを選択できます。
たとえば、Project-A で生成されたログに関して、そのログを Project-A または Project-B のユーザー定義のバケットに転送するようにシンクを構成できます。
Cloud Logging の料金は、ログの種類に関係なく、このバケットに保持されているログデータに適用されます。
バケットのカスタム保持を構成できます。
ユーザー定義のログバケットの管理（削除や更新など）については、ログバケットの構成と管理をご覧ください。
リージョン指定
ログバケットは、リージョン リソースです。ログの保存、インデックス登録、検索を行うインフラストラクチャは、特定の地理的なロケーションにあります。Google は、アプリケーションがそのリージョン内のゾーン全体で冗長性が確保されるように、そのインフラストラクチャを管理します。
ログバケットを作成するか、組織レベルのリージョン ポリシーを設定するときに、次のいずれかのリージョンにログを保存できます。
南北アメリカ
| リージョン名 | リージョンの説明 | 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 |
パリ |
中東
| リージョン名 | リージョンの説明 | Log Analytics のサポート |
|---|---|---|
me-central1 |
ドーハ | |
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 ビューは編集できず、削除できません。
カスタム ログビューでは、ログデータへのアクセスを制御する高度で詳細な方法を提供します。たとえば、一元管理された Google Cloud プロジェクトに、組織のすべてのログを保存するシナリオを考えてみます。ログバケットには複数の Google Cloud プロジェクトのログを格納できるため、それぞれのユーザーがログを表示できる Google Cloud プロジェクトを制御する必要がある場合があります。カスタム ログビューを使用すると、あるユーザーに 1 つの Google Cloud プロジェクトのログへのアクセス権のみを付与しつつ、別のユーザーにはすべての Google Cloud プロジェクトのログへのアクセス権を付与できます。
ログビューの構成については、バケットレベルのアクセスを構成するをご覧ください。
Google Cloud エコシステムでのログの使用
次のセクションでは、より広範な Google Cloud でログを使用する方法について説明します。
ログベースの指標
ログベースの指標は、ログエントリの内容から派生した Cloud Monitoring 指標です。たとえば、Cloud Logging によって受信された Google Cloud プロジェクトに対するログエントリが、Google Cloud プロジェクトのいずれかの指標のフィルタに一致すると、そのログエントリは指標データでカウントされます。
ログベースの指標は、ログベースの指標がシステムで定義されているか、ユーザーによって定義されるかに応じて異なる処理を行います。以降のセクションでは、これらの違いについて説明します。
ログベースの指標と除外フィルタ
シンク除外フィルタは、システム定義のログベースの指標に適用されます。この指標は、Google Cloud プロジェクトによる取り込みに含まれるログのみをカウントします。
シンク除外フィルタは、ユーザー定義のログベースの指標には適用されません。Cloud Logging API が取り込まないようにログを除外し、どの Logging バケットにも保存されないようにした場合でも、これらの指標にはそうしたログもカウントされます。
ログベースの指標のスコープ
システム定義のログベースの指標は、Google Cloud プロジェクト レベルで適用されます。 これらの指標は、ログルーターによって計算され、受信した Google Cloud プロジェクトのログにのみ適用されます。
ユーザー定義のログベースの指標は、Google Cloud プロジェクト レベルか、特定のログバケット レベルで適用できます。
- プロジェクト レベルの指標は、システム定義のログベースの指標と同様に計算されます。これらのユーザー定義のログベースの指標は、指標を受信した Google Cloud プロジェクトのログにのみ適用されます。
バケットレベルの指標は、ログエントリの発生元の Google Cloud プロジェクトに関係なく、受信したログバケット内のログに適用されます。
バケットスコープのログベースの指標によって、以下の場合にログを評価できるログベースの指標を作成できます。
- あるプロジェクトから別のプロジェクトのバケットに転送されるログ。
- 集約シンクを介してバケットに転送されるログ。
詳細については、ログベースの指標の概要をご覧ください。
サポートされている宛先でのログの検索
転送されるログエントリの形式と、ログを宛先で整理する方法については、シンクの宛先でログを表示するをご覧ください。
一般的なユースケース
ログの転送と保存に関する一般的なユースケースに対処するには、次のドキュメントとチュートリアルをご覧ください。
コンプライアンスの必要性
データ ガバナンスのために転送を使用する際のベスト プラクティスについては、次のドキュメントをご覧ください。
IAM を使用したアクセス制御
Identity and Access Management（IAM）のロールと権限を使用して Cloud Logging データへのアクセスを制御する方法については、IAM を使用したアクセス制御をご覧ください。
料金
取り込みとストレージの料金について詳しくは、Cloud Logging の料金情報をご覧ください。
Cloud Logging ではログの転送は課金されませんが、転送先での請求が適用されることがあります。詳細については、該当するサービスの料金詳細をご覧ください。
次のステップ
Cloud Logging データのルーティングと保存については、次のドキュメントをご覧ください。
サポートされている宛先にログを転送するシンクを作成するには、シンクの構成をご覧ください。
転送とシンクのトラブルシューティング情報については、転送とシンクのトラブルシューティングをご覧ください。