Google Cloud のオペレーション スイートの費用の最適化

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

料金

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

費用には、Cloud LoggingCloud MonitoringCloud Trace の料金が含まれます。Error Reporting ロギング プロダクトは、ベータ版の間は別途費用がかかることがありませんCloud デバッガ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 Console で利用可能な請求レポートを表示することです。

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

ログ

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

プロジェクトで取り込まれたログ容量は、Logging の [ログの取り込み] セクションで確認できます。ログビューアには、ログの一覧、前月の取り込みログ容量、今月初めからの取り込みログ容量量、除外された取り込みログ容量、月末(EOM)までの予想ログ容量が表示されます。次の図では、各ログが Monitoring にリンクされています。Monitoring には、一定期間のログのボリュームのグラフが表示されます。

ログリンクを伴うログビューア

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

Monitoring

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

複数のプロジェクトを伴うワークスペース

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

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

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

Trace

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

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

Logging エクスポート

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

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

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

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

ログシンクを探す

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

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

使用量の詳細を確認する

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

クラウド ストレージ

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

Metrics Explorer を使用してモニタリング対象リソースの指標を表示する方法は次のとおりです。

  1. Google Cloud Console で [Monitoring] を選択するか、次のボタンを使用します。
    [Monitoring] に移動
  2. [Monitoring] のナビゲーション パネルで、 [Metrics Explorer] をクリックします。
  3. [Metric] タブが選択されていることを確認します。
  4. [Find resource type and metric] のボックスをクリックして、リソースと指標をメニューから選択するか、リソースと指標の名前を入力します。次の情報を使用して、このテキスト ボックスのフィールドに入力します。
    1. [リソース] に「gcs_bucket」と入力します。
    2. [Metric] に「storage.googleapis.com/storage/total_bytes」と入力します。
    3. 次のフィルタを追加します。
      • project_id をクリックしてから、Google Cloud プロジェクト ID を選択します。
      • dataset_name をクリックしてから、Cloud Storage エクスポート バケット名を選択します。
  5. [Filter]、[Group By]、[Aggregator] の各メニューを使用して、データの表示方法を変更します。たとえば、リソースラベルや指標ラベルごとにグループ化できます。詳しくは、指標の選択をご覧ください。
Cloud Storage バケットのストレージ サイズ

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

BigQuery

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

  1. Google Cloud Console で [Monitoring] を選択するか、次のボタンを使用します。
    [Monitoring] に移動
  2. ナビゲーション パネルに Metrics Explorer が表示されている場合は、 [Metrics Explorer] をクリックします。それ以外の場合は、 [Resources] を選択して [Metrics Explorer] を選択します。
  3. [指標] タブが選択されていることを確認します。
  4. [Find resource type and metric] のボックスをクリックして、リソースと指標をメニューから選択するか、リソースと指標の名前を入力します。次の情報を使用して、このテキスト ボックスのフィールドに入力します。
    1. [Resource Type] に「bigquery_dataset」と入力します。
    2. [Metric] に「bigquery.googleapis.com/storage/stored_bytes」と入力します。

  5. 次のフィルタを追加します。
    • project_id をクリックしてから、Google Cloud プロジェクト ID を選択します。
    • dataset_id をクリックしてから、BigQuery エクスポート データセット名を選択します。
  6. [Group By] に「dataset_id」と入力します。 BigQuery データセットのストレージ サイズ

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

Pub/Sub

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

  1. Google Cloud Console で [Monitoring] を選択するか、次のボタンを使用します。
    [Monitoring] に移動
  2. ナビゲーション パネルに Metrics Explorer が表示されている場合は、 [Metrics Explorer] をクリックします。それ以外の場合は、 [Resources] を選択して [Metrics Explorer] を選択します。
  3. [指標] タブが選択されていることを確認します。
  4. [Find resource type and metric] のボックスをクリックして、リソースと指標をメニューから選択するか、リソースと指標の名前を入力します。次の情報を使用して、このテキスト ボックスのフィールドに入力します。
    1. [Resource Type] に「pubsub_topic」と入力します。
    2. [Metric] に「pubsub.googleapis.com/topic/byte_cost」と入力します。

  5. 次のフィルタを追加します。
    • project_id をクリックしてから、Google Cloud プロジェクト ID を選択します。
    • topic_id をクリックしてから、Pub/Sub エクスポート トピック名を選択します。

Pub/Sub トピックのストレージ サイズ

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

コスト管理の実装

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

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

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

Monitoring のコスト管理

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

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

Google Cloud コンポーネントにラベルを使用する方法は、Monitoring で指標に対して生成される時系列の使用量に影響を与える可能性があります。

たとえば、次の図に示すように、VM 上のラベルを使用して、Google Cloud 請求書上のコストセンターに指標を適切に報告し、特定の Google Cloud 環境が本番か開発かを示すことができます。

Google Kubernetes Engine クラスタ上のラベル

これらのラベルの追加は、Monitoring で新しい時系列が生成されることを意味します。仮想マシンに cost_centerenv の値でラベルを付けると、両方のラベルのカーディナリティを掛けて時系列の総数を計算できます。

total_num_time_series = cost_center_cardinality * env_cardinality

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

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

  • 可能な限り、ラベルの数を制限します。
  • 高いカーディナリティのラベル値を避けるようにラベル値を慎重に選択します。たとえば、IP アドレスをラベルとして使用すると、IP アドレスごとに 1 つずつの時系列が作成されます。そのため、VM の数が多ければ、大量の時系列が生成されます。

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 のサンプリング機能を使用して、取り込まれるトレースの数を減らすことができます。

たとえば、5000 クエリ/秒を誇る人気のウェブアプリがある場合は、アプリ トラフィックの 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 の使用量とコストを制限できます。Cloud Console の API 固有の割り当てページでスパン割り当てを適用できます。

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

API 固有の割り当てページのモニタリング

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

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

  1. Google Cloud Console で [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 つの解決策は、ログフィルタを使用して、エクスポートするログの数を減らすようにログシンクを更新することです。不要なログをエクスポートから除外できます。

たとえば、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 のオペレーション スイートでは、プロダクトの使用状況データを表示できるため、プロダクトの使用状況を詳しく把握できます。この使用量データを使用すれば、使用量とコストを適切に最適化するようにプロダクトを構成できます。

次のステップ