BigQuery Export ユーザーの Log Analytics への移行

※この投稿は米国時間 2022 年 10 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

ログ分析を BigQuery に一元化して、ログとイベントを一括表示しているお客様は、BigQuery から次のようなメリットをすでに享受しています。

• 費用対効果の高いペタバイト規模の分析

• マルチクラウドおよびハイブリッド環境での異種データの分析

• エンタープライズ クラスのセキュリティ機能を備えた、フルマネージドのサーバーレス データ ウェアハウス上での稼働

• 使い慣れた標準 SQL と拡張機能を使用して、誰でも分析情報を利用可能

Log Analytics（公開プレビュー版）の導入により、良いものがさらに素晴らしいものになりました。Log Analytics を使用すると、BigQuery を活用しながら、BigQuery における Google Cloud のログのエクスポートと分析に関する費用を削減できるほか、価値創出までの時間を短縮することができます。

この投稿は、BigQuery ログシンクから Log Analytics に移行する（または移行を検討している）ユーザーを対象としています。これら 2 つの相違点を説明したあと、BigQuery の既存の SQL クエリを Log Analytics で機能するように調整する簡単な方法をご紹介します。Log Analytics の概要と Cloud Logging への適合については、ユーザー ドキュメントをご覧ください。

比較

Log Analytics と従来の BigQuery へのログシンクとの比較

シンプルなテーブル構成

データに関する最も重要な変更点は、Log Analytics でアップグレードされたログバケット内のすべてのログを、Google Cloud のすべてのログタイプまたはログ形式をサポートする包括的なスキーマ（次のセクションで詳述）を使用して、単一のログビュー _AllLogs で利用できることです。これは、各エントリがログ名に基づいてデータセット内の別の BigQuery テーブルにマッピングされる従来の BigQuery ログシンク（BigQuery のルーティング スキーマで詳述）とは対照的です。次に例を示します。

このテーブルの 2 列目は、BigQuery ログシンクがパーティション分割テーブルを使用するように構成されていることを前提としています。BigQuery ログシンクが日付でシャーディングされたテーブルを使用するように構成されている場合、クエリではテーブル名に追加された接尾辞（ログエントリの日付）も考慮する必要があります（例: cloudaudit_googleapis_com_data_access_09252022）。

上の比較表に示すように、Log Analytics ではすべてのログを同一のビューで利用できるため、特定のログの名前や、そのログの正確なテーブル名を知る必要はありません。そのため、特に複数の異なるログタイプを横断的に検索して関連付けする場合に、クエリが大幅にシンプルになります。

WHERE 句にオプションで log_id または log_name を指定することで、与えられたクエリの範囲を制御できます。たとえば、クエリを data_access のログに制限する場合は、以下を追加します。

WHERE log_id = "cloudaudit.googleapis.com/data_access"

統合型ログスキーマ

Log Analytics には、すべてのログに対応するスキーマが 1 つだけ存在します。そのため、Log Analytics では、スキーマのスーパーセットが 1 つ管理されています。このスキーマは、想定されるすべてのログスキーマを照合したものです。たとえば、このスキーマは LogEntry のペイロード（protoPayload、textPayload、jsonPayload）を一意のフィールド（それぞれ proto_payload、text_payload、json_payload）にマッピングすることで、想定されるさまざまなタイプのペイロードに対応します。

また、ログフィールド名が、全体的にキャメルケース（例: logName）からスネークケース（例: log_name）に変更になりました。さらに、log_id などの新しいフィールドもあります（log_id は各ログエントリの log_id です）。

ユーザー向けのスキーマのもう 1 つの変更点として、Log Analytics では、json_payload や labels など、ネストされたオブジェクトを表す一部のフィールドに、ネイティブ JSON データ型を使用できることが挙げられます。JSON 型の列には任意の JSON オブジェクトを含めることができるため、Log Analytics のスキーマでは、その列に利用可能なフィールドのリストは表示されません。これは、ネストされたフィールドを含むすべてのログタイプに事前定義済みの厳格なスキーマが存在する従来の BigQuery ログシンクとは対照的です。Log Analytics では、JSON フィールドを含むより柔軟なスキーマを使用することで、任意のログを含む半構造化データをサポートしながら、クエリをシンプルにし、場合によって高速化することができます。

スキーマ移行ガイド

スキーマに関するこれらすべての変更を踏まえて、新しい SQL クエリを作成したり、既存の SQL クエリを従来の BigQuery ログシンクから Log Analytics へと変換するには、どうすればよいでしょうか。

次のテーブルは、BigQuery にルーティングする従来のログシンクと新しい Log Analytics のすべてのログフィールドを、対応する列名とタイプをマッピングして並べて表示したものです。このテーブルを移行ガイドとして使用し、破壊的変更の特定、新しいフィールドの適切な参照、既存の SQL クエリの体系的な移行にお役立てください（画像をクリックすると拡大表示されます）。

破壊的変更を伴うフィールドは、変更が必要な部分を視覚的に追跡しやすいように、すべて太字で表記されています。たとえば、監査ログに対してクエリを実行する場合、protopayload_auditlog STRUCT フィールドを参照および解析すると思います。前出のスキーマ移行テーブルを見ると、そのフィールドが Log Analytics では proto_payload.audit_log STRUCT フィールドに対応していることがわかります。

新たに追加されたフィールドは黄色のセル、JSON に変換されたフィールドは赤色のセルで表示されていることに注目してください。

スキーマの変更の概要

先ほどのスキーマ移行ガイドを見ると、全体的に列名がキャメルケースからスネークケースに変更されたこと以外に、5 つの注目すべき破壊的変更があることがわかります。

1）タイプが STRING から JSON に変更されたフィールド（赤色のセル）:

• metadataJson

• requestJson

• responseJson

• resourceOriginalStateJson

2）タイプが STRUCT から JSON に変更されたフィールド（赤色のセル）:

• labels

• resource.labels

• jsonPayload

• jsonpayload_type_loadbalancerlogentry

• protopayload_auditlog.servicedata_v1_bigquery

• protopayload_auditlog.servicedata_v1_iam

• protopayload_auditlog.servicedata_v1_iam_admin

3）さらにネストされているフィールド:

• protopayload_auditlog（Log Analytics では proto_payload.audit_log）

• protopayload_requestlog（Log Analytics では proto_payload.request_log）

4）1 つにまとめられたフィールド:

• jsonPayload（Log Analytics では json_payload）

• jsonpayload_type_loadbalancerlogentry（Log Analytics では json_payload）

• jsonpayload_v1beta1_actionlog（Log Analytics では json_payload）

5）タイプが変更されたその他のフィールド:

• httpRequest.latency（FLOAT から STRUCT に変更）

クエリの移行パターン

これらの各変更について、SQL クエリをどのように変換するかを見ていきましょう。例として、以下にいくつかの SQL を抜粋しました。各 SQL の全体を確認したい場合は、それぞれに記載されている Community Security Analytics（CSA）レポートのリンクをご覧ください。例は次のようになっています。

• 変換前: 従来の BigQuery ログシンクを使用する場合の SQL

• 変換後: Log Analytics を使用する場合の SQL

パターン 1: STRING 列からのネストされたフィールドの参照を JSON に変更: 

これは、スキーマ移行テーブルで赤色で表示されているフィールドの一部が対象となります。次のものがあります。

• metadataJson

• requestJson

• responseJson

• resourceOriginalStateJson

変換前:

JSON_VALUE(protopayload_auditlog.metadataJson, '$.violationReason')

変換後:

JSON_VALUE(proto_payload.audit_log.metadata.violationReason)

抜粋元のクエリ: CSA 1.10

変換前:

JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations[0].targetResource')

変換後:

JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations[0].targetResource)

抜粋元のクエリ: CSA 1.10

パターン 2: STRUCT 列からのネストされたフィールドの参照を JSON に変更: 

これは、スキーマ移行テーブルで赤色で表示されているフィールドの一部が対象となります。次のものがあります。

• labels

• resource.labels

• jsonPayload

• jsonpayload_type_loadbalancerlogentry

• protopayload_auditlog.servicedata*

変換前:

jsonPayload.connection.dest_ip

変換後:

JSON_VALUE(jsonPayload.connection.dest_ip)

抜粋元のクエリ: CSA 6.01

変換前:

resource.labels.backend_service_name

変換後:

JSON_VALUE(resource.labels.backend_service_name)

抜粋元のクエリ: CSA 1.20

変換前:

jsonpayload_type_loadbalancerlogentry.statusdetails

変換後:

JSON_VALUE(json_payload.statusDetails)

抜粋元のクエリ: CSA 1.20

変換前:

protopayload_auditlog.servicedata_v1_iam.policyDelta.bindingDeltas

変換後:

JSON_QUERY_ARRAY(proto_payload.audit_log.service_data.policyDelta.bindingDeltas)

抜粋元のクエリ: CSA 2.20

パターン 3: protoPayload からのフィールドの参照:

これは、スキーマ移行テーブルで太字で表示されているフィールドの一部が対象となります。次のものがあります。

• protopayload_auditlog（Log Analytics では proto_payload.audit_log）

• protopayload_requestlog（Log Analytics では proto_payload.request_log）

変換前:

protopayload_auditlog.authenticationInfo.principalEmail

変換後:

proto_payload.audit_log.authentication_info.principal_email

抜粋元のクエリ: CSA 1.01

パターン 4: タイプがロードバランサ ログエントリの jsonPayload からのフィールドの参照:

変換前:

jsonpayload_type_loadbalancerlogentry.statusdetails

変換後:

JSON_VALUE(json_payload.statusDetails)

抜粋元のクエリ: CSA 1.20

パターン 5: httpRequest の latency フィールドの参照:

変換前:

httpRequest.latency

変換後:

http_request.latency.nanos / POW(10,9)

まとめ

Log Analytics を使用して、セルフマネージドのログシンクと BigQuery データセットから Google が管理するログシンクと BigQuery データセットに移行することで、ログ分析の費用と複雑さを軽減しながら、よりシンプルで高速なクエリを活用することができます。さらに、リアルタイムのトラブルシューティングに役立つログ エクスプローラ、ログベースの指標、ログアラート、Error Reporting の自動インサイトなど、Cloud Logging の各種機能もご利用いただけます。

このガイドを活用すれば、Log Analytics を使用したログ分析に簡単に切り替えることができます。ここでご紹介したスキーマ移行ガイドを使用し、規範的な 5 つの移行パターンを適用して、BigQuery の SQL ログクエリを変換したり、Log Analytics で新しい SQL を作成したりしてください。