Google Cloud Observability の費用の最適化

Google Cloud Observability は、アプリとインフラストラクチャ サービスに対する詳細なオブザーバビリティを提供するように設計されたクラウドベースのマネージド サービスのコレクションで構成されています。Google Cloud 上のマネージド サービスの利点の 1 つは、サービスが使用量に基づいていることです。つまり、使用した分に対してのみ料金が発生します。この料金設定モデルは、標準のソフトウェア ライセンスと比較してコストメリットがありますが、コストを予測するのは難しくなります。このソリューションでは、マネージド サービスの使用状況を理解してコストを最適化する方法について説明します。

料金

Google Cloud Observability サービスはマネージド サービスであるため、このサービスを利用するために必要なインフラストラクチャではなく、サービスから得られる分析情報を重視できます。このサービスを使用する場合、仮想マシン、ソフトウェア ライセンス、セキュリティ スキャン、ハードウェア メンテナンス、データセンター内のスペースの料金を個別に支払う必要はありません。このサービスはシンプルな従量課金制です。

費用には、Cloud Logging、Cloud Monitoring、Cloud Trace の料金が含まれます。Error Reporting ロギング プロダクトはまだベータ版のため、別途費用はかかりません。Cloud Profiler は無料で使用できます。Error Reporting では、Logging にエラーが取り込まれると小額の費用が発生することがあります。

すべての料金情報の概要もご覧ください。

Logging と Error Reporting のコスト

Logging 料金は、取り込まれた課金対象ログのボリュームに基づきます。このプロダクトの料金設定はシンプルな GiB あたりの従量制課金です。毎月の無料割り当て量があり、Cloud Audit Logs などの特定のログは課金対象外です。

追加のログボリュームを通してコストが発生するプロダクトの使用例を以下に示します。

• Cloud Load Balancing
• Compute Engine 上の Logging エージェント
• Amazon Web Services（AWS）上の Logging エージェント
• Cloud Logging API での書き込み操作

Monitoring のコスト

Monitoring 料金は、課金対象指標の取り込み量と課金対象 API の呼び出し回数に基づきます。たとえば、エージェント、カスタム、外部、AWS 指標などの Google Cloud 以外の指標は課金対象です。Cloud Monitoring API の projects.timeSeries.list メソッドは、API 呼び出しによって課金されますが、残りの API の使用は無料です。これは毎月の無料指標割り当て数であり、すべての Google Cloud 指標を含む、多くの指標が課金対象外です。課金対象の指標に関する詳細については、Monitoring の料金をご覧ください。

指標の数と API 呼び出しによるコストが発生するプロダクトの使用例を以下に示します。

• Monitoring カスタム指標
• Compute Engine 上の Monitoring エージェント
• AWS 上の Monitoring エージェント
• Monitoring API での読み取り操作

Trace のコスト

Trace の料金は、取り込まれたスパンと最終的にスキャンされたスパンの数に基づきます。App Engine スタンダード環境などの一部の Google Cloud サービスでは、課金対象外のスパンが自動的に生成されます。Trace には毎月の無料割り当て量があります。

取り込まれたスパン数によって費用が発生するプロダクト使用状況の例として、以下を計測対象に追加することがあります。

• デフォルト スパン以外の App Engine アプリ用のスパン
• Cloud Load Balancing
• カスタムアプリ

使用量

使用量を把握することで、どのコンポーネントでコストが発生しているかに関する分析情報を得ることができます。これは、最適化に適した領域の特定に役立ちます。

Google Cloud 請求書分析

使用量を把握するための最初のステップは、Google Cloud 請求書を確認して、コストを把握することです。分析情報を得るための 1 つの方法は、Google Cloud コンソールで利用可能な請求レポートを表示することです。

レポートのページには、時間、プロジェクト、プロダクト、SKU、ラベルで結果を絞り込むための便利なフィルタが用意されています。プロダクト フィルタを使用すると、課金データをモニタリングとロギングの費用に絞り込むことが可能です。

Logging

Logging は、ログの詳細なリスト、今月の現在までの使用量、今月の予想使用量をプロジェクトごとに提供します。プロジェクトごとにこれらの詳細を確認しながら、Google Cloud 請求書上の Logging 料金を確認できます。これにより、使用量が最高（コストが最大）のログを簡単に確認できます。

プロジェクトで取り込まれたログ容量は、[ログストレージ] ページで確認できます。[ログストレージ] ページには、前月と今月のログとそのボリューム、月末の予想ボリュームが表示されます。

この分析を使用すれば、特定のプロジェクトでのログの使用量と使用量の経時変化に関する情報を得ることができます。この分析を使用して、最適化を検討する必要のあるログを特定できます。

Monitoring

Monitoring により、プロジェクトの詳細なリストと、先月の取り込み量、今月初めからの取り込み量、月末までの予想取り込み量が指標スコープに整理して表示されます。次の図に示すように、指標スコープには複数のプロジェクトが含まれていることもあるため、ボリュームはプロジェクトごとに表示されます。

Monitoring の使用量の詳細を検索する方法を学びます。

Monitoring の Metrics Explorer で各プロジェクトの指標ボリューム指標の詳細なグラフを表示できます。これにより、一定期間にわたって指標の取り込み量に関する分析情報が得られます。

この分析では、特定した各プロジェクトの Monitoring 指標取り込み量を確認しながら、Google Cloud 請求書上の Monitoring 料金を確認できます。その後で、特定の指標取り込み量を確認して、取り込み量とコストが最大のコンポーネントを把握できます。

Trace

Trace は、今月と先月に取り込まれたスパンの詳細なビューを提供します。Google Cloud コンソールで特定したプロジェクトごとにこの詳細を確認しながら、Google Cloud 請求書上の Trace 料金を確認できます。

この分析は、ワークスペース内の特定したプロジェクトごとに取り込まれたスパン数だけでなく、Google Cloud 請求書上の Trace 料金も提供します。この分析を使用すれば、取り込まれた特定のスパン数を確認して、スパンとコストが最大のプロジェクトとサービスを把握できます。

Logging エクスポート

Logging には、Cloud Storage、BigQuery、Pub/Sub にログをエクスポートするためのログシンクがあります。

たとえば、長期保存と分析のためにすべてのログを Logging から BigQuery にエクスポートする場合は、GiB 単位のストレージ、ストリーミング挿入、クエリのコストなど、BigQuery のコストが発生します。

エクスポートで発生するコストを把握するには、次のステップを考慮してください。

1. ログシンクを探す。有効にしたログシンクがある場合は検索します。たとえば、プロジェクトには、セキュリティ運用のためや規制要件を満たすためなどのさまざまな目的で作成されたログシンクがすでに存在している場合があります。
2. 使用量の詳細を確認する。エクスポート先の使用量を確認します。たとえば、BigQuery エクスポート用の BigQuery テーブルサイズや Cloud Storage エクスポート用のバケットサイズを確認します。

ログシンクを探す

ログシンクは、プロジェクト レベルで存在する（プロジェクトごとに 1 つ以上のシンク）場合もあれば、Google Cloud 組織レベルで存在する（集約エクスポートと呼ばれる）場合もあります。シンクに同じ Google Cloud 組織内の複数のプロジェクトのログが含まれていることもあります。

特定のプロジェクトを調査することで、ログシンクを確認できます。Google Cloud コンソールには、シンクと宛先のリストが表示されます。組織の集約エクスポートを表示するには、gcloud logging sinks list --organization ORGANIZATION_ID コマンドラインを使用します。

使用量の詳細を確認する

Monitoring は、アプリだけでなく Google Cloud プロダクトの使用量についても豊富な指標を提供します。Metrics Explorer で使用量指標を表示することにより、Cloud Storage、BigQuery、Pub/Sub の詳細な使用量指標を取得できます。

注: ワークスペースに、複数のプロジェクトが含まれている場合があります。使用量を確認する際は、エクスポートに使用した Cloud Storage バケット、BigQuery データセット、Pub/Sub トピックを含むワークスペースを使用してください。

Cloud Storage

Monitoring の Metrics Explorer を使用することにより、Cloud Storage バケットのストレージ サイズを確認できます。Metrics Explorer 内の次の値を使用して、ログシンクに使用された Cloud Storage バケットのストレージ サイズを確認します。

Metrics Explorer を使用してモニタリング対象リソースの指標を表示するには、次の操作を行います。

1. Google Cloud コンソールのナビゲーション パネルで [Monitoring] を選択し、次に [ Metrics Explorer] を選択します。

   Metrics Explorer に移動

2. [指標] 要素の [指標の選択] メニューを開き、フィルタバーに「Total bytes」と入力し、サブメニューを使用して特定のリソースタイプと指標を選択します。
   1. [有効なリソース] メニューで、[GCS バケット] を選択します。
   2. [有効な指標カテゴリ] メニューで、[Storage] を選択します。
   3. [有効な指標] メニューで [Total bytes] を選択します。
   4. [適用] をクリックします。
   この指標の完全修飾名は storage.googleapis.com/storage/total_bytes です。
3. データの表示方法を構成します。
   • [フィルタ] 要素で [フィルタを追加] をクリックし、[project_id] を選択します。値として、実際の Google Cloud プロジェクト ID を選択します。
   • [フィルタ] 要素で [フィルタを追加] をクリックし、[bucket_name] を選択します。値として、実際の Cloud Storage エクスポート バケット名を選択します。
   • [集計] エントリで、最初のメニューを [未集計] に設定します。

   グラフの構成の詳細については、Metrics Explorer 使用時の指標の選択をご覧ください。

前のグラフは、一定期間にエクスポートされたデータのサイズを TB 単位で示しています。ここから、Cloud Storage へのロギングのエクスポートの使用量に関する分析情報が得られます。

BigQuery

Monitoring の Metrics Explorer を使用することにより、BigQuery データセットのストレージ サイズを表示できます。Metrics Explorer 内の次の値を使用して、ログシンクに使用された BigQuery データセットのストレージ サイズを確認します。

Metrics Explorer を使用してモニタリング対象リソースの指標を表示するには、次の操作を行います。

1. Google Cloud コンソールのナビゲーション パネルで [Monitoring] を選択し、次に [ Metrics Explorer] を選択します。

   Metrics Explorer に移動

2. [指標] 要素の [指標を選択] メニューを展開してフィルタバーに「Stored bytes」と入力し、サブメニューを使用して特定のリソースタイプと指標を選択します。
   1. [アクティブなリソース] メニューで、[BigQuery データセット] を選択します。
   2. [有効な指標カテゴリ] メニューで、[Storage] を選択します。
   3. [アクティブな指標] メニューで、[保存されたバイト数] を選択します。
   4. [適用] をクリックします。
   この指標の完全修飾名は bigquery.googleapis.com/storage/stored_bytes です。
3. データの表示方法を構成します。
   • [フィルタ] 要素で [フィルタを追加] をクリックし、[project_id] を選択します。値として、実際の Google Cloud プロジェクト ID を選択します。
   • [フィルタ] 要素で [フィルタを追加] をクリックし、[dataset_id] を選択します。値として、実際の BigQuery エクスポート データセット名を選択します。
   • [集計] エントリで、最初のメニューを [平均] に設定し、2 番目のメニューを [dataset_id] に設定します。
   • [表示] ペインで、[ウィジェット タイプ] を [積み上げ棒グラフ] に設定します。
   • 時間枠を 1 日以上に設定します。

   グラフの構成の詳細については、Metrics Explorer 使用時の指標の選択をご覧ください。

前のグラフは、一定期間のエクスポート データセットのサイズを TB 単位で示しています。ここから、BigQuery へのロギングのエクスポートの使用量に関する分析情報が得られます。

Pub/Sub

Monitoring の Metrics Explorer を使用することにより、Pub/Sub にエクスポートされたメッセージの数とサイズを表示できます。Metrics Explorer 内の次の値を使用して、ログシンクに使用された Pub/Sub トピックのストレージ サイズを確認します。

Metrics Explorer を使用してモニタリング対象リソースの指標を表示するには、次の操作を行います。

1. Google Cloud コンソールのナビゲーション パネルで [Monitoring] を選択し、次に [ Metrics Explorer] を選択します。

   Metrics Explorer に移動

2. [指標] 要素の [指標を選択] メニューを展開してフィルタバーに「Byte cost」と入力し、サブメニューを使用して特定のリソースタイプと指標を選択します。
   1. [有効なリソース] メニューで、[Cloud Pub/Sub トピック] を選択します。
   2. [有効な指標カテゴリ] メニューで、[Topic] を選択します。
   3. [有効な指標] メニューで、[Topic byte cost] を選択します。
   4. [適用] をクリックします。
   この指標の完全修飾名は pubsub.googleapis.com/topic/byte_cost です。
3. データの表示方法を構成します。
   • [フィルタ] 要素で [フィルタを追加] をクリックし、[project_id] を選択します。値として、実際の Google Cloud プロジェクト ID を選択します。
   • [フィルタ] 要素で [フィルタを追加] をクリックし、[topic_id] を選択します。値として、Pub/Sub エクスポート トピック名を選択します。
   • [集計] エントリで、最初のメニューを [未集計] に設定します。

   グラフの構成の詳細については、Metrics Explorer 使用時の指標の選択をご覧ください。

前のグラフは、一定期間にエクスポートされたデータのサイズを KB 単位で示しています。ここから、Pub/Sub へのロギングのエクスポートの使用量に関する分析情報が得られます。

コスト管理の実装

以下のオプションは、コストを削減する可能性のある方法を示しています。各オプションでは、アプリやインフラストラクチャに関して限られた分析情報しか得られません。オブザーバビリティとコストのバランスが最もよいオプションを選択してください。

Logging のコスト管理

Logging の使用量を最適化するには、Logging に取り込まれるログの数を減らします。デベロッパーやオペレーターに必要なログを維持しながら、ログ数を減らすのに役立ついくつかの戦略があります。

ログを除外する

デベロッパーやオペレーション チームに必要のないログのほとんどを Logging や Error Reporting から除外できます。

ログの除外は、ログが Logging UI や Error Reporting UI に表示されないことを意味します。ロギング フィルタを使用すると、除外する特定のログエントリまたはログ全体を選択できます。サンプリング除外ルールを使用して、一定の割合のログエントリを除外することもできます。たとえば、ボリュームの多さや実用的価値のなさに基づいて特定のログを除外するように選択できます。

一般的な除外例を以下に示します。

• Cloud Load Balancing からのログを除外する。ロードバランサは、トラフィックの多いアプリの場合に大量のログを生成する可能性があります。たとえば、ログフィルタを使用して、Cloud Load Balancing からのメッセージの 90% を除外するように設定できます。

• Virtual Private Cloud（VPC Service Controls）フローログを除外する。フローログには、VPC Service Controls ネットワーク内の仮想マシン間の通信ごとのログが書き込まれます。そのため、大量のログが生成される可能性があります。ログ数を減らすには次の 2 つの方法があります。これらを一緒に使用することも別々に使用することもできます。

  • ログエントリの内容によって除外する。役に立つかもしれない特定のログメッセージだけを残し、ほとんどの VPC フローログを除外します。たとえば、外部ソースからの着信トラフィックを受信する必要のないプライベート VPC がある場合は、外部 IP アドレスからのソース フィールドを含むフローログだけを保持します。
  • 割合によって除外する。もう 1 つの方法は、フィルタによって特定された一定の割合のログだけをサンプリングすることです。たとえば、フローログの 95% を除外し、5% だけを保持します。

• リクエストログから HTTP 200 OK レスポンスを除外する。アプリでは、HTTP 200 OK メッセージからあまり多くの分析情報を得られない場合があります。しかも、トラフィックの多いアプリの場合は大量のログが生成される可能性があります。

ロギング除外を実装するには、ログの除外をご覧ください。

ログをエクスポートする

ログをエクスポートすることで、それを Logging への取り込みから除外できます。この方法を使用すれば、Logging からログを除外しながら、Cloud Storage と BigQuery でログを保持するか、Pub/Sub を使用してログを処理できます。これにより、コストが削減されます。つまり、ログは Logging に表示されずに、エクスポートされます。

この方法は、Logging への取り込みのコストをかけずに長期分析用にログを保持するために使用します。除外とエクスポートの相互作用の詳細については、ログのエクスポートの概要図（Life of a log）をご覧ください。この図は、エクスポートされたログエントリが Logging でどのように処理されるかを示しています。

Logging エージェントの使用量を減らす

Logging エージェントによって生成された追加のログを Logging に送信しないことにより、ログボリュームを減らすことができます。Logging エージェントは、Apache、Mongodb、MySQL などの一般的なサードパーティ アプリからログをストリーミングします。

たとえば、開発環境やその他の Logging に必要のない環境内の仮想マシンに Logging エージェントを追加しないことを選択することにより、ログ数を減らすことができます。仮想マシンは、引き続き、標準ログを Logging に報告しますが、サードパーティ アプリや syslog からのログは報告しません。

Monitoring のコスト管理

Monitoring の使用量を最適化するには、Monitoring に取り込まれる課金対象指標の数と Monitoring API への読み取り呼び出しの回数を減らします。デベロッパーやオペレーターに必要な指標を維持しながら、指標ボリュームを減らすことのできる戦略がいくつかあります。

指標とラベルの使用量を最適化する

モニタリング カスタム指標でラベルを使用する方法は、生成される時系列の使用量に影響を与える可能性があります。

2 つのラベル（cost_center と env の値など）があるカスタム指標がある場合、両方のラベルのカーディナリティを掛けて時系列の最大数を計算できます。

total_num_time_series = cost_center_cardinality * env_cardinality

11 個の cost_center 値と 5 個の env 値がある場合、最大 55 個の時系列を生成できます。これが、指標ラベルを追加すると指標ボリュームが大幅に増え、コストが増大する理由です。指標カーディナリティの詳細については、Cloud Monitoring のヒントとコツ: 指標の詳細とチャートの作成についてに関するブログ投稿をご覧ください。

時系列の数を最小限に抑えるために、次のことをおすすめします。

• 可能な限り、カスタム指標のラベルの数を制限してください。
• カーディナリティの高いラベル値を避けるため、ラベルは慎重に選択してください。たとえば、user_id をラベルとして使用すると、ユーザーごとに少なくとも 1 つの時系列が作成されますが、トラフィックが多い場合は時系列が非常に増える可能性があります。

Monitoring エージェントの使用量を減らす

Monitoring エージェントから送信される指標は課金対象指標です。Monitoring エージェントは、Apache、MySQL、Nginx などの一般的なサードパーティ アプリからのアプリ指標とシステム指標の他に、追加の Google Cloud VM レベルの指標もストリーミングします。詳細なシステム指標やサードパーティ アプリからの特定の VM に関する指標が必要ない場合は、このような指標を送信しないことにより、使用量を減らすことができます。Monitoring エージェントを使用する VM の数を少なくすることで指標数を減らすこともできます。

たとえば、開発環境やその他の Monitoring に必要のない環境内の Google Cloud プロジェクトを追加しないことを選択することにより、指標数を減らすことができます。さらに、開発環境やその他の必要のない環境内の VM に Monitoring エージェントを含めないように選択することもできます。

カスタム指標の使用量を減らす

カスタム指標は、Monitoring API を使用して、ユーザーがインストゥルメント化した指標を監視することによって作成される課金対象指標です。この指標は、Monitoring API を使用するか、統合されたツールを使用することにより、作成できます。

そのようなツールの 1 つが OpenCensus です。OpenCensus は単一配布のライブラリで、アプリから指標と分散トレースを収集します。OpenCensus でインストゥルメント化されたアプリは、カスタム指標を使用することにより、Monitoring を含む複数のバックエンドに指標を報告できます。これらの指標は、Monitoring の custom.googleapis.com/opencensus 接頭辞リソースタイプに表示されます。たとえば、OpenCensus から報告されたクライアントの往復レイテンシは、Monitoring の custom.googleapis.com/opencensus/grpc.io/client/roundtrip_latency リソースタイプに表示されます。

指標を送信するためにインストゥルメント化されたアプリが多いほど、より多くのカスタム モニタリング指標が生成されます。指標ボリュームを減らすには、アプリから送信されるカスタム モニタリング指標の数を減らします。

Trace のコスト管理

Trace の使用量を最適化するには、取り込まれるスパン数とスキャンされるスパン数を減らします。スパンを Trace に報告するようにアプリをインストゥルメント化した場合は、サンプリングを使用してトラフィックの一部を取り込みます。サンプリングは、RPC 呼び出しなどのアプリ コンポーネントによって引き起こされるレイテンシの内訳に関する分析情報が得られるため、トレース システムの重要な部分です。これは Trace を使用するためのベスト プラクティスであるだけでなく、コスト削減の目的でスパン数を減らすことにもなります。

OpenCensus サンプリングを使用する

OpenCensus トレース用のエクスポート先として Trace を使用する場合は、OpenCensus のサンプリング機能を使用して、取り込まれるトレースの数を減らすことができます。

たとえば、5,000 クエリ/秒を誇る人気のウェブアプリがある場合は、アプリ トラフィックの 20% ではなく 5% のサンプリングで十分な分析情報を得ることができます。これにより、Trace に取り込まれるスパンの数が 4 分の 1 に減少します。

Trace 用の OpenCensus Python ライブラリを使用することにより、インストルメンテーション構成でサンプリングを指定できます。例として、OpenCensus Python エクスポータは、サンプリング レートの指定に使用可能な ProbabilitySampler を提供します。

from opencensus.trace.samplers import probability
from opencensus.trace import tracer as tracer_module

# Sampling the requests at the rate equals 0.05
sampler = probability.ProbabilitySampler(rate=0.05)
tracer = tracer_module.Tracer(sampler=sampler)

Cloud Trace API スパン割り当てを使用する

割り当てを使用して、Trace の使用量とコストを制限できます。Google Cloud コンソールの API 固有の割り当てページでスパン割り当てを適用できます。

特定の割り当てをデフォルトのプロダクト割り当てよりも低く設定すると、プロジェクトで特定の割り当て制限を超えないようにすることができます。この方法でコストを確実に想定内に抑えることが可能になります。この割り当ては、次の図に示すように、API 固有の割り当てページからモニタリングできます。

スパン割り当てを減らす場合は、Monitoring でのスパン割り当ての指標のモニタリングとアラート ポリシーの設定を検討し、使用量が割り当てに近づいたときにアラートを送信するようにする必要もあります。このアラートは、使用量を調べて、大量のスパンを生成しているアプリとデベロッパーを特定するように促します。設定したスパン割り当てを超えた場合は、割り当てを調整するまでスパンがドロップされます。

たとえば、スパン割り当てが取り込みスパン 50 M の場合は、API 割り当ての 80%（40 M）のスパンを使用したときにアラートを送信するように設定できます。以下に示すアラート ポリシーの管理手順に沿ってアラート ポリシーを作成します。

1. Google Cloud コンソールで [Monitoring] を選択するか、次のボタンを使用します。
   [Monitoring] に移動
2. Monitoring のナビゲーション パネルで、 [アラート] を選択し、次に [Create Policy] を選択します。
3. アラート ポリシー名を入力します。
4. [Add Condition] をクリックします。
   1. [Target] ペインの設定で、モニタリングするリソースと指標を指定します。テキスト ボックスをクリックしてメニューを有効にし、リソース [global] を選択します。
   2. テキスト ボックスをクリックしてメニューを有効にし、[cloudtrace.googleapis.com/billing/monthly_spans_ingested] を選択します。
   3. 次の [Filter] 値を追加します。
   • project_id をクリックしてから、Google Cloud プロジェクト ID を選択します。
   • chargeable をクリックしてから、true を選択します。
   4. アラート ポリシーの [Configuration] ペインの設定で、アラートがトリガーされるタイミングを決定します。次のフィールドに値を入力します。
   • [Condition triggers if] には、[Any time series violates] を選択します。
   • [Threshold] に「40000000」と入力します。
   • [For] で、[most recent value] を選択します。
   5. [Save] をクリックします。

5. [Save] をクリックします。

   アラート ポリシーから生成されるアラートは、次のアラートのようになります。アラートでは、プロジェクトに関する詳細、アラートを生成したアラート ポリシー、指標の現在の値を確認できます。

サードパーティの呼び出し元を最適化する

アプリが他のアプリから呼び出される場合があります。アプリがスパンを報告する場合、アプリから報告されるスパンの数はサードパーティ アプリから受信される着信トラフィックによって異なります。たとえば、チェックアウト マイクロサービスを呼び出すフロントエンド マイクロサービスがあり、その両方が OpenCensus でインストゥルメント化されている場合は、トラフィックのサンプリング レートは少なくともフロントエンドのサンプリング レートと同じくらい高くなります。インストゥルメント化されたアプリがどのように相互作用するかを理解することで、取り込まれたスパンの数の影響を評価できます。

Logging エクスポート

Logging エクスポートに関連したコストが懸念される場合の 1 つの解決策は、ログフィルタを使用して、エクスポートするログの数を減らすようにログシンクを更新することです。不要なログをエクスポートから除外できます。

注: Logging からログを除外し、Logging エクスポートからもログを除外すると、それらのログにアクセスできなくなります。

たとえば、Compute Engine 上で実行されるアプリを有し、さらに Cloud SQL、Cloud Storage、BigQuery を使用している環境では、エクスポートするログに含める情報をそれらのプロダクトに関する情報のみに制限することが考えられます。次のフィルタを使用すると、Cloud Audit Logs、Compute Engine、Cloud Storage、Cloud SQL、BigQuery のログのみがエクスポートされます。このフィルタをログシンクとして使用し、選択したログのみを含めることができます。

logName:"/logs/cloudaudit.googleapis.com" AND
(resource.type:gce OR
resource.type=gcs_bucket OR
resource.type=cloudsql_database OR
resource.type=bigquery_resource)

まとめ

Google Cloud Observability はプロダクトの使用量データを表示する機能を備えているため、プロダクトの使用量の詳細を把握できます。この使用量データを使用すれば、使用量とコストを適切に最適化するようにプロダクトを設定できます。

次のステップ

• Logging API の詳細を読む。
• Monitoring API の詳細を読む。
• Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。