サンプル SQL クエリ

このドキュメントでは、ログ分析を使用するようにアップグレードされたログバケットに保存されているログエントリに対するサンプルクエリについて説明します。これらのバケットでは、Google Cloud コンソールの [Log Analytics] ページから SQL クエリを実行できます。その他のサンプルについては、logging-analytics-samples と security-analytics GitHub リポジトリをご覧ください。

このドキュメントでは、SQL やログエントリの転送と保存の方法については説明しません。これらのトピックについては、次のステップをご覧ください。

ヒント: クエリの WHERE 句に timestamp フィールドを含めないでください。 代わりに、期間選択ツールを使用して期間を設定します。

始める前に

このセクションでは、Log Analytics を使用する前に完了する必要がある手順について説明します。

ログバケットを構成する

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

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

   [ログストレージ] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] の結果を選択します。

2. クエリを実行するログビューを含むログバケットごとに、[ログ分析を使用可能] 列に [開く] が表示されていることを確認します。[アップグレード] が表示されたら、[アップグレード] をクリックしてダイアログを完了します。

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

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

• Log Analytics の使用とログビューのクエリ実行に必要な権限を取得するには、プロジェクトに対する次の IAM ロールの付与を管理者に依頼してください。

  • _Required および _Default のログバケットに対してクエリを実行するには: 　　ログ閲覧者（roles/logging.viewer）
  • プロジェクト内のすべてのログビューをクエリするには: ログビューアクセサー （roles/logging.viewAccessor）

  プリンシパルを特定のログビューに制限するには、プロジェクト レベルで行われたログビュー アクセサー ロールの付与に IAM 条件を追加するか、ログビューのポリシー ファイルに IAM バインディングを追加します。詳細については、ログビューへのアクセスを制御するをご覧ください。

  これらの権限は、[ログ エクスプローラ] ページでログエントリを表示するために必要な権限と同じです。ユーザー定義バケットに対するビューのクエリ実行、または _Default ログバケットの _AllLogs ビューのクエリ実行のために必要な追加のロールについて詳しくは、Cloud Logging のロールをご覧ください。

これらのクエリの使用方法

[Log Analytics] ページで、このドキュメントに示すクエリを使用するには、TABLE_NAME_OF_LOG_VIEW を、クエリを実行するログビューのテーブル名に置き換えます。

ログビューをクエリするには、FROM 句で次の形式を使用します。

FROM `PROJECT_ID.LOCATION.BUCKET_ID.VIEW_ID`

上記の式のフィールドの意味は次のとおりです。

• PROJECT_ID: プロジェクトの ID。
• LOCATION: ログビューのロケーション。
• BUCKET_ID: ログバケットの名前または ID。
• VIEW_ID: ログビューの ID。

リンクされた BigQuery データセットを作成した場合は、[BigQuery Studio] ページからリンクされたデータセットをクエリできます。このページで、TABLE_NAME_OF_LOG_VIEW はリンクされたデータセットのテーブルへのパスに置き換えます。たとえば、プロジェクト myproject にあるリンクされたデータセット mydataset でビュー _AllLogs をクエリするには、このフィールドを myproject.mydataset._AllLogs に設定します。

[ログ分析] ページに移動します。

[Log Analytics] ページを開くには、次の手順を行います。

1. Google Cloud コンソールで、[ログ分析] ページに移動します。

   [ログ分析] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] の結果を選択します。

2. 省略可: ログビューのスキーマを特定するには、[ログビュー] リストでビューを見つけて、ビューの名前を選択します。

   スキーマが表示されます。[フィルタ] フィールドを使用して、特定のフィールドを見つけることができます。スキーマは変更できません。

ログビューのデフォルト クエリにアクセスする方法については、ログ分析でログをクエリして分析するをご覧ください。

ログをフィルタする

SQL クエリは、処理するログビュー内のエントリを決定してから、これらのエントリをグループ化し、集計オペレーションを実行します。グループ化オペレーションと集計オペレーションが記載されていない場合、クエリの結果には、フィルタ オペレーションによって選択された行が含まれます。このセクションのサンプルでは、フィルタについて説明します。

時間でフィルタする

クエリの期間を設定するには、期間セレクタを使用することをおすすめします。このセレクタは、クエリで WHERE 句に timestamp フィールドが指定されていない場合に自動的に使用されます。 たとえば、過去 1 週間のデータを表示するには、期間セレクタで [過去 7 日間] を選択します。また、期間セレクタを使用して、開始時刻と終了時刻の指定、表示時間の指定、タイムゾーンの変更を行うこともできます。

WHERE 句に timestamp フィールドを含めると、期間セレクタの設定は使用されません。次の例では、TIMESTAMP_SUB 関数を使用してデータをフィルタリングします。この関数を使用すると、現在の時刻から遡る期間を指定できます。

WHERE
  timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)

時間でフィルタする方法の詳細については、時間関数とタイムスタンプ関数をご覧ください。

リソースでフィルタする

リソースでフィルタリングするには、resource.type の制限を追加します。

たとえば、次のクエリは、直近 1 時間のデータを読み取り、リソースタイプが gce_instance と一致する行を保持してから、最大 100 個のエントリを並べ替えて表示します。

SELECT
  timestamp, log_name, severity, json_payload, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  resource.type = "gce_instance"
ORDER BY timestamp ASC
LIMIT 100

重大度でフィルタする

severity = 'ERROR' などの制限を使用して、特定の重大度でフィルタできます。別の方法は、IN ステートメントを使用して、有効な値のセットを指定することです。

たとえば、次のクエリは、直近 1 時間のデータを読み取り、値が 'INFO' または 'ERROR' の severity フィールドを含む行のみを保持します。

SELECT
  timestamp, log_name, severity, json_payload, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  severity IS NOT NULL AND
  severity IN ('INFO', 'ERROR')
ORDER BY timestamp ASC
LIMIT 100

上記のクエリは、severity フィールドの値でフィルタします。ログの重大度の数値でフィルタするクエリを作成することもできます。たとえば、severity 行を次の行に置き換えると、重大度が NOTICE 以上のログエントリすべてが返されます。

  severity_number IS NOT NULL AND
  severity_number > 200

列挙される値の詳細については、LogSeverity をご覧ください。

ログ名でフィルタする

ログ名でフィルタするには、log_name フィールドか log_id フィールドの値に制限を追加します。log_name フィールドには、リソースパスが入ります。つまり、このフィールドは、projects/myproject/logs/mylog のような値になります。log_id フィールドには、mylog などのログ名のみが保存されます。

たとえば、次のクエリでは、直近 1 時間のデータを読み取り、log_id フィールドの値が cloudaudit.googleapis.com/data_access の行を保持してから、結果を並べ替えて表示します。

SELECT
  timestamp, log_id, severity, json_payload, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  log_id = "cloudaudit.googleapis.com/data_access"
ORDER BY timestamp ASC
LIMIT 100

リソースラベルでフィルタする

モニタリング対象リソース記述子のほとんどは、特定のリソースの識別に使用されるラベルを定義します。たとえば、Compute Engine インスタンスの記述子には、ゾーン、プロジェクト ID、インスタンス ID のラベルがあります。ログエントリが書き込まれると、各フィールドに値が割り当てられます。そのような例を次に示します。

{
   type: "gce_instance"
   labels: {
      instance_id: "1234512345123451"
      project_id: "my-project"
      zone: "us-central1-f"
   }
}

labels フィールドのデータ型は JSON であるため、クエリに resource.labels.zone = "us-centra1-f" などの制限を含めると、構文エラーが発生します。データ型が JSON のフィールド値を取得するには、関数 JSON_VALUE を使用します。

たとえば、次のクエリは、最新のデータを読み取り、リソースが us-central1-f ゾーンにある Compute Engine インスタンスの行を保持します。

SELECT
  timestamp, log_name, severity, JSON_VALUE(resource.labels.zone) AS zone, json_payload, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  resource.type = "gce_instance" AND
  JSON_VALUE(resource.labels.zone) = "us-central1-f"
ORDER BY timestamp ASC
LIMIT 100

JSON データを取得して変換できるすべての関数の詳細については、JSON 関数をご覧ください。

HTTP リクエストでフィルタする

HTTP リクエストまたはレスポンスに対応するログエントリのみが含まれるようにログビューをフィルタするには、http_request IS NOT NULL 制限を追加します。

SELECT
  timestamp, log_name, severity, http_request, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  http_request IS NOT NULL
ORDER BY timestamp
LIMIT 100

次のクエリには、GET や POST リクエストに対応する行のみが含まれています。

SELECT
  timestamp, log_name, severity, http_request, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  http_request IS NOT NULL AND
  http_request.request_method IN ('GET', 'POST')
ORDER BY timestamp ASC
LIMIT 100

HTTP ステータスでフィルタする

HTTP ステータスでフィルタリングするには、http_request.status フィールドを定義するように WHERE 句を変更します。

SELECT
  timestamp, log_name, http_request.status, http_request, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  http_request IS NOT NULL AND
  http_request.status IS NOT NULL
ORDER BY timestamp ASC
LIMIT 100

フィールドに格納されているデータの種類を見極めるには、スキーマを確認するか、フィールドを表示します。上記のクエリの結果は、http_request.status フィールドに整数値が格納されていることを示しています。

JSON 型のフィールドでフィルタする

データ型が JSON の列から値を抽出するには、関数 JSON_VALUE を使用します。

次のクエリについて考えてみましょう。

SELECT
  json_payload
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  json_payload.status IS NOT NULL

そして

SELECT
  json_payload
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  JSON_VALUE(json_payload.status) IS NOT NULL

上記のクエリは、ログエントリの json_payload フィールドの値をテストします。どちらのクエリでも、json_payload というラベルの付いたフィールドがないログエントリは破棄されます。これら 2 つのクエリは、NULL に対してテストされる内容を定義する最後の行に違いがあります。次に、2 つのログエントリを含むログビューについて考えてみましょう。1 つのログエントリの場合、json_payload フィールドの形式は次のとおりです。

{
    status: {
        measureTime: "1661517845"
    }
}

他のログエントリでは、json_payload フィールドの構造が異なります。

{
    @type: "type.googleapis.com/google.cloud.scheduler.logging.AttemptFinished"
    jobName: "projects/my-project/locations/us-central1/jobs/test1"
    relativeUrl: "/food=cake"
    status: "NOT_FOUND"
    targetType: "APP_ENGINE_HTTP"
}

上記のログエントリはどちらも制限 json_payload.status IS NOT NULL を満たしています。つまり、最初のクエリの結果には、両方のログエントリが含まれます。ただし、制限が JSON_VALUE(json_payload.status) IS NOT NULL の場合、クエリ結果には 2 番目のログエントリのみが含まれます。

正規表現でフィルタする

正規表現と一致する部分文字列を返すには、関数　REGEXP_EXTRACT を使用します。この関数の戻り値の型は、STRING か BYTES のいずれかです。

次のクエリは、受信した最新のログエントリを表示し、それらのエントリを json_payload.jobName フィールドで保持して、test で始まる名前の一部分を表示しています。

SELECT
  timestamp, REGEXP_EXTRACT(JSON_VALUE(json_payload.jobName), r".*(test.*)$") AS name,
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  json_payload.jobName IS NOT NULL
ORDER BY timestamp DESC
LIMIT 20

他の例については、REGEXP_EXTRACT のドキュメントをご覧ください。使用できる他の正規表現の例については、関数、演算子、条件をご覧ください。

この例に示すクエリは、効率的ではありません。図に示すような部分文字列の一致の場合は、CONTAINS_SUBSTR 関数を使用します。

ログエントリをグループ化して集計する

このセクションでは、前述のサンプルに基づき、ログエントリをグループ化して集計する方法について説明します。グループ化を指定しなかったが集計を指定した場合は、SQL が WHERE 句を満たすすべての行を単一のグループとして扱うため、単一の結果が印刷されます。

すべての SELECT 式は、グループ フィールドに含めるか、集計する必要があります。

時間ごとにグループ化する

データを時間でグループ化するには、関数 TIMESTAMP_TRUNC を使用します。この関数は、MINUTE のような指定した粒度までタイムスタンプを切り詰めます。たとえば、粒度が MINUTE に設定されている場合、15:30:11 のタイムスタンプ（hours:minutes:seconds 形式）は、15:30:00 になります。

注: クエリでタイムスタンプを指定すると、そのタイムスタンプにより期間セレクタで選択された期間がオーバーライドされます。期間セレクタを使用するには、クエリからタイムスタンプ式を削除してください

次のクエリは、期間選択ツールで指定された間隔で受信したデータを読み取り、json_payload.status フィールドの値が NULL ではない行を保持します。 クエリは、1 時間ごとの各行のタイムスタンプを切り詰め、切り詰められたタイムスタンプとステータスで行をグループ化します。

SELECT
  TIMESTAMP_TRUNC(timestamp, HOUR) AS hour,
  JSON_VALUE(json_payload.status) AS status,
  COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  json_payload IS NOT NULL AND
  JSON_VALUE(json_payload.status) IS NOT NULL
GROUP BY hour,status
ORDER BY hour ASC

他の例については、TIMESTAMP_TRUNC のドキュメントをご覧ください。他の時間ベースの関数については、日時関数をご覧ください。

リソースごとにグループ化する

次のクエリは、直近 1 時間のデータを読み取り、リソースタイプ別にログエントリをグループ化します。次に、各リソースタイプの行数をカウントし、2 つの列を持つテーブルを返します。最初の列にはリソースタイプを列挙し、2 番目の列にはそのリソースタイプの行数が入ります。

SELECT
   resource.type, COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
GROUP BY resource.type
LIMIT 100

重大度でグループ化する

次のクエリは、直近 1 時間のデータを読み取り、重大度フィールドを持つ行を保持します。次に、このクエリは、重大度で行をグループ化し、各グループの行数をカウントします。

SELECT
  severity, COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  severity IS NOT NULL
GROUP BY severity
ORDER BY severity
LIMIT 100

log_id でグループ化

次のクエリ結果は 2 つの列を持つテーブルです。最初の列にはログ名が表示され、2 番目の列にはそのログに書き込まれたログエントリの数が表示されます。このクエリは、エントリ数で結果を並べ替えます。

SELECT
  log_id, COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
GROUP BY log_id
ORDER BY count DESC
LIMIT 100

HTTP リクエストの平均レイテンシを計算する

次のクエリでは、複数の列でのグループ化と平均値の計算を示します。クエリは、HTTP リクエストに含まれる URL と、labels.checker_location フィールドの値で行をグループ化します。行をグループ化した後、クエリは各グループの平均レイテンシを計算します。

SELECT
  JSON_VALUE(labels.checker_location) AS location,
  AVG(http_request.latency.seconds) AS secs, http_request.request_url
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  http_request IS NOT NULL AND
  http_request.request_method IN ('GET')
GROUP BY http_request.request_url, location
ORDER BY location
LIMIT 100

上記の式では、labels のデータ型が JSON であるため、labels.checker_location フィールドの値を抽出するために JSON_VALUE が必要です。ただし、http_request.latency.seconds フィールドからの値の抽出には、この関数を使用しません。後者のフィールドのデータ型は整数です。

サブネットワーク テストの平均送信バイト数を計算する

次のクエリは、場所ごとに送信された平均バイト数を表示する方法を示しています。

このクエリは、直近 1 時間のデータを読み取り、リソースタイプの列が gce_subnetwork で、json_payload 列が NULL ではない行のみを保持します。次に、このクエリによって、リソースのロケーション別に行がグループ化されます。データが数値として保存されている前述の例とは異なり、bytes_sent フィールドの値は文字列であるため、平均を計算する前に値を FLOAT64 に変換する必要があります。

SELECT JSON_VALUE(resource.labels.location) AS location,
   AVG(CAST(JSON_VALUE(json_payload.bytes_sent) AS FLOAT64)) AS bytes
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  resource.type = "gce_subnetwork" AND
  json_payload IS NOT NULL
GROUP BY location
LIMIT 100

上記のクエリの結果は、各行にロケーションと、そのロケーションに送信された平均バイト数が記載されたテーブルになります。

JSON データを取得して変換できるすべての関数の詳細については、JSON 関数をご覧ください。

CAST などの変換関数の詳細については、変換関数をご覧ください。

パターンに一致するフィールドがあるログエントリをカウントする

正規表現と一致する部分文字列を返すには、関数　REGEXP_EXTRACT を使用します。この関数の戻り値の型は、STRING か BYTES のいずれかです。

次のクエリは、json_payload.jobName フィールドの値が NULL ではないログエントリを保持します。 次に、test で始まる名前の接尾辞でエントリをグループ化します。最後に、クエリは各グループのエントリ数をカウントします。

SELECT
  REGEXP_EXTRACT(JSON_VALUE(json_payload.jobName), r".*(test.*)$") AS name,
  COUNT(*) AS count
FROM
  `TABLE_NAME_OF_LOG_VIEW`
WHERE
  json_payload.jobName IS NOT NULL
GROUP BY name
ORDER BY count
LIMIT 20

他の例については、REGEXP_EXTRACT のドキュメントをご覧ください。使用できる他の正規表現の例については、関数、演算子、条件をご覧ください。

クロスカラム検索

このセクションでは、テーブルの複数の列を検索するために使用できる 2 つの方法について説明します。

トークンベースの検索

一連の検索キーワードに一致するエントリのログビューを検索するには、関数 SEARCH を使用します。この関数では、検索する場所と検索クエリの 2 つのパラメータが必要です。SEARCH 関数にはデータの検索方法に関する特定のルールがあるため、SEARCH のドキュメントを一読することをおすすめします。

次のクエリは、「35.193.12.15」に完全に一致するフィールドを持つ行のみを保持します。

SELECT
  timestamp, log_id, proto_payload, severity, resource.type, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW` AS t
WHERE
  proto_payload IS NOT NULL AND
  log_id = "cloudaudit.googleapis.com/data_access" AND
  SEARCH(t,"`35.193.12.15`")
ORDER BY timestamp ASC
LIMIT 20

上記のクエリでは、バッククォートが検索対象の値をラップしています。これにより、SEARCH 関数はフィールド値とバッククォート間の値との完全一致を検索します。

クエリ文字列でバッククォートが省略されている場合、クエリ文字列は SEARCH のドキュメントで定義されているルールに基づいて分割されます。たとえば、次のステートメントを実行すると、クエリ文字列は「35」、「193」、「12」、「15」の 4 つのトークンに分割されます。

  SEARCH(t,"35.193.12.15")

上記の SEARCH ステートメントでは、1 つのフィールドが 4 つのトークンすべてに一致する場合、行と一致します。トークンの順序は関係ありません。

クエリには、複数の SEARCH ステートメントを含めることができます。たとえば、上記のクエリでは、ログ ID のフィルタを次のようなステートメントに置き換えることができます。

  SEARCH(t,"`cloudaudit.googleapis.com/data_access`")

上記のステートメントはログビューのログエントリのすべてのフィールドを検索しますが、元のステートメントはログエントリの log_id フィールドのみを検索します。

複数のフィールドで複数の検索を実行するには、個々の文字列をスペースで区切ります。たとえば、次のステートメントは、フィールドに「Hello World」、「happy」、「days」が含まれている行に一致します。

  SEARCH(t,"`Hello World` happy days")

最後に、テーブル全体ではなく、特定のフィールドを検索することもできます。たとえば、次のステートメントは、text_payload と json_payload という名前の列のみを検索します。

   SEARCH((text_payload, json_payload) ,"`35.222.132.245`")

SEARCH 関数のパラメータの処理方法については、BigQuery リファレンス ページの検索関数をご覧ください。

部分文字列の検索

式に値が存在するかどうかを判断するために大文字と小文字を区別しないテストを実行するには、関数 CONTAINS_SUBSTR を使用します。 この関数は、値が存在する場合は TRUE、存在しない場合は FALSE を返します。検索値は STRING リテラルである必要があり、リテラル NULL ではありません。

たとえば、次のクエリは、タイムスタンプが特定の時間範囲内にある特定の IP アドレスを持つすべてのデータアクセス監査ログエントリを取得します。最後に、クエリ結果を並べ替えて、古いものから 20 件の結果を表示します。

SELECT
  timestamp, log_id, proto_payload, severity, resource.type, resource, labels
FROM
  `TABLE_NAME_OF_LOG_VIEW` AS t
WHERE
  proto_payload IS NOT NULL AND
  log_id = "cloudaudit.googleapis.com/data_access" AND
  CONTAINS_SUBSTR(t,"35.193.12.15")
ORDER BY timestamp ASC
LIMIT 20

上記のクエリでは、部分文字列テストが実行されます。したがって、「35.193.12.152」を含む行は CONTAINS_SUBSTR ステートメントと一致します。

複数のソースのデータを統合

クエリ ステートメントは、1 つ以上のテーブルまたは式をスキャンし、計算結果の行を返します。たとえば、クエリ ステートメントを使用して、さまざまなテーブルやデータセットの SELECT ステートメントの結果をマージし、結合データから列を選択できます。

2 つのテーブルのデータを結合で結合

2 つのテーブルの情報を組み合わせるには、いずれかの JOIN 演算子を使用します。使用する結合の種類と条件句によって、行の結合方法と破棄方法が決まります。

次のクエリは、同じトレーススパンによって書き込まれた 2 つの異なるテーブルの行から json_payload フィールドを取得します。クエリは、両方のテーブルの span_id 列と trace 列の値が一致する行の 2 つのテーブルに対して内部 JOIN を実行します。この結果により、TABLE_NAME_OF_LOG_VIEW_1 から取得した timestamp、severity、json_payload の各フィールドがクエリから選択されます。json_payload フィールドは TABLE_NAME_OF_LOG_VIEW_2 と、2 つのテーブルが結合された span_id フィールドと trace フィールドの値は、最大 100 行を返します。

SELECT
  a.timestamp, a.severity, a.json_payload, b.json_payload, a.span_id, a.trace
FROM `TABLE_NAME_OF_LOG_VIEW_1` a
JOIN `TABLE_NAME_OF_LOG_VIEW_2` b
ON
  a.span_id = b.span_id AND
  a.trace = b.trace
LIMIT 100

複数の選択を union で結合

2 つ以上の SELECT ステートメントの結果を結合して重複行を破棄するには、UNION 演算子を使用します。重複した行を保持するには、UNION ALL 演算子を使用します。

次のクエリは、TABLE_NAME_OF_LOG_VIEW_1 から直近の 1 時間のデータを読み取り、その結果を TABLE_NAME_OF_LOG_VIEW_2 から直近の 1 時間のデータとマージし、タイムスタンプを昇順で並べ替えて、古い順に 100 個のエントリを表示します。

SELECT
  timestamp, log_name, severity, json_payload, resource, labels
FROM(
  SELECT * FROM `TABLE_NAME_OF_LOG_VIEW_1`
  UNION ALL
  SELECT * FROM `TABLE_NAME_OF_LOG_VIEW_2`
)
ORDER BY timestamp ASC
LIMIT 100

重複するログエントリを削除する

ログ分析では、クエリの実行前に重複するログエントリが削除されることはありません。これは、ログ エクスプローラを使用してログエントリをクエリする場合とは異なります。ログ エクスプローラでは、ログ名、タイムスタンプ、挿入 ID フィールドを比較して重複エントリが削除されます。

行レベルの検証を使用して、重複するログエントリを削除できます。

注: 行検証を実行するクエリは、行検証を実行しないクエリよりも時間がかかります。クエリが重複するログエントリに敏感である場合、またはクエリ結果に重複するエントリを含めない場合を除き、ログエントリの重複除去は行わないでください。

詳細については、トラブルシューティング: ログ分析の結果に重複するログエントリがあるをご覧ください。

制限事項

[ログ分析] ページで使用されるクエリは、一部の例外を除き、GoogleSQL 関数をサポートしています。

[Log Analytics] ページを使用して発行された SQL クエリでは、次の SQL コマンドはサポートされていません。

• DDL コマンドと DML コマンド
• JavaScript ユーザー定義関数
• BigQuery ML 関数
• SQL 変数

以下は、BigQuery Studio ページ、Looker Studio ページ、bq コマンドライン ツールを使用してリンク済みデータセットをクエリする場合にのみサポートされます。

• JavaScript ユーザー定義関数
• BigQuery ML 関数
• SQL 変数

次のステップ

ログエントリを転送して保存する方法については、次のドキュメントをご覧ください。

• ログバケットの作成
• ログ分析を使用するためにログバケットをアップグレードする
• ログバケットを BigQuery データセットにリンクする
• シンクの構成と管理

SQL リファレンス ドキュメントについては、次のドキュメントをご覧ください。

• 関数、演算子、条件
• 検索関数
• クエリ構文