ログ分析を使用してログボリュームを分析する

このドキュメントでは、ログ分析を使用してログエントリの課金対象のデータ量を見積もる方法について説明します。リソースタイプやアプリケーション名などのさまざまなディメンション別に課金対象のデータ量をレポートして集計するクエリを作成して、クエリ結果をグラフに表示できます。

課金対象のデータ量をクエリする方法

ログエントリの課金対象のデータ量（Cloud Billing に報告されるサイズ）は、storage_bytes フィールドを介して確認できます。クエリでは、データ型が INTEGER のスキーマフィールドと同じように storage_bytes フィールドを使用できます。たとえば、SELECT 句、CASE ステートメント、共通テーブル式に含めることができます。ログのクエリの詳細については、次のドキュメントをご覧ください。

Cloud Billing では、費用の決定時に課金対象のデータ量が使用されるため、費用のソースの把握に役立つクエリを作成できます。たとえば、最も多くのログエントリを書き込んでいるアプリケーションの特定に役立つクエリを作成できます。課金対象のデータ量を費用に関連付ける方法については、Google Cloud Observability の料金ページの Cloud Logging セクションをご覧ください。

ログエントリの課金対象のデータ量は、Cloud Logging API に送信された LogEntry オブジェクトのサイズではありません。課金対象のデータ量には、シリアル化とメタデータに必要なバイトが含まれます。

始める前に

このセクションでは、ログ分析を使用する前に完了しておく必要のある手順について説明します。

ログバケットを構成する

ログ分析を使用できるようにログバケットがアップグレードされていることを確認します。

Google Cloud コンソールで、[ログストレージ] ページに移動します。
[ログストレージ] に移動

このページを検索バーで検索する場合は、小見出しが「Logging」の結果を選択します。
クエリを実行するログビューを含む各ログバケットで、[Log Analytics を使用可能] 列に [開く] が表示されていることを確認します。[アップグレード] が表示されている場合は、[アップグレード] をクリックしてダイアログを完了します。

IAM のロールと権限を構成する

このセクションでは、ログ分析の使用に必要な IAM ロールまたは権限について説明します。

ログ分析の使用とログビューへのクエリ実行に必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。
- _Required および _Default のログバケットに対してクエリを実行する: ログ閲覧者（roles/logging.viewer）
- プロジェクトのすべてのログビューに対してクエリを実行する: ログ表示アクセス者（roles/logging.viewAccessor）
プリンシパルを特定のログビューに制限するには、プロジェクトレベルで付与されたログ表示アクセス者ロールに IAM 条件を追加するか、ログビューのポリシーファイルに IAM バインディングを追加します。詳細については、ログビューへのアクセスを制御するをご覧ください。

これらの権限は、[ログエクスプローラ] ページでログエントリを表示するために必要な権限と同じです。ユーザー定義バケットでのビューに対するクエリ実行、または _Default ログバケットの _AllLogs ビューに対するクエリ実行に必要な追加ロールについて詳しくは、Cloud Logging のロールをご覧ください。
分析ビューへのクエリ実行に必要な権限を取得するには、プロジェクトに対する Observability Analytics ユーザー（roles/observability.analyticsUser）IAM ロールを付与するよう管理者に依頼してください。

サンプルクエリ

このセクションでは、単一のログビューからデータを分析するクエリの例を示します。複数のログビューにデータを保存し、それらのビューに保存されているデータの集計値を計算する場合は、UNION ステートメントを使用する必要があります。

ログエントリをクエリするには、[ログ分析] ページを使用するか、BigQuery データセットをクエリできる場所（[BigQuery Studio] ページ、[Looker Studio] ページを含む）、bq コマンドラインツールを使用します。

サンプルクエリを使用するには、次のようにします。

[ログ分析] ページ: VIEW は、ログビューの名前に置き換えます。形式は project_ID.region.bucket_ID.view_ID です。

[ログ分析] に移動
BigQuery データセット: VIEW は、リンクされたデータセットのテーブルへのパスに置き換えます。

[BigQuery Studio] に移動

アプリ別のログボリュームのクエリ

Google Kubernetes Engine リソースに対して書き込まれ、JSON ペイロードを含むログエントリの 1 日あたりの合計バイト数をアプリごとに計算するには、次のクエリを使用します。

SELECT
  timestamp_trunc(timestamp,DAY) as day,
  JSON_VALUE(labels["k8s-pod/app"]) as app_id,
  SUM(storage_bytes) as total_bytes
FROM
  `VIEW`
WHERE
  json_payload IS NOT NULL
  AND resource.type="k8s_container"
GROUP BY ALL

データを可視化するには、グラフを作成できます。

次の例では、データが積み上げ棒グラフとして表示されます。グラフの各バーには、保存されている合計バイト数がアプリ別に整理されて表示されます。この例では、frontend アプリがログデータを最も多く生成しています。

アプリごとのログボリュームをクエリした結果を示すグラフの例。

ログ名でログボリュームをクエリする

Google Kubernetes Engine リソースに対して書き込まれた、JSON ペイロードを持つ各ログエントリの保存されているバイト数とログ名を一覧表示するには、次のクエリを使用します。

SELECT
  log_id AS log_name,
  storage_bytes
FROM
  `VIEW`
WHERE
  json_payload IS NOT NULL
  AND resource.type="k8s_container"

前のクエリでは結果が集計されません。代わりに、ログエントリごとに 1 つの行があり、その行にはログ名と保存されたバイト数が含まれます。このデータをグラフにすると、さまざまなログに書き込まれたログデータの部分を可視化できます。

ログ名でログのボリュームをクエリした結果を示すグラフの例。

上のグラフは、ほとんどのログデータが stdout という名前のログに書き込まれていることを示しています。

bq コマンドラインツールを使用してログ名でログボリュームをクエリする

[BigQuery Studio] ページを介して、または bq コマンドラインツールを使用して、実行するクエリに storage_bytes フィールドを含めることができます。

次のクエリは、各ログエントリのログ名と保存されているバイト数を報告します。

bq query --use_legacy_sql=false  'SELECT log_id as log_name,
  storage_bytes FROM `VIEW`'

このクエリの結果は次のようになります。

+----------+---------------+
| log_name | storage_bytes |
+----------+---------------+
| stdout   |           716 |
| stdout   |           699 |
| stdout   |           917 |
| stdout   |           704 |

各行は 1 つのログエントリに対応します。storage_bytes 列の値は、そのログエントリの課金対象のデータ量です。

制限事項

storage_bytes フィールドは、次の条件を満たしている場合にのみ使用できます。

ログバケットが、ログ分析を使用するようにアップグレードされている。
クエリが、[ログ分析] ページ、または BigQuery データセットをクエリできる場所（[BigQuery Studio] ページ、[Looker Studio] ページを含む）、bq コマンドラインツールで実行されている。
ログエントリが 2024 年 1 月 1 日以降に書き込まれている。