エクスポートされたログの BigQuery スキーマ

エクスポートされたログに対する BigQuery テーブル スキーマは、LogEntry 型の構造とログのペイロードの内容に基づいています。また、Stackdriver Logging では、監査ログの BigQuery スキーマ フィールド名を短縮するための特別なルールが適用されます。テーブル スキーマを確認するには、BigQuery ウェブ UI でログエントリがエクスポートされたテーブルを選択します。

フィールド命名規則

ログエントリ フィールドに適用される命名規則がいくつかあります。

  • LogEntry 型の一部であるログエントリ フィールドの場合、対応する BigQuery フィールド名はログエントリ フィールドとまったく同じです。
  • ユーザー指定のフィールドの場合、大文字小文字は小文字に正規化されますが、それ以外は名前は保持されます。

    • 構造化ペイロードのフィールドの場合、@type 指定子が存在しない限り、大文字小文字は小文字に正規化されますが、それ以外は名前は保持されます。

      @type 指定子が存在する構造化ペイロードについては、@type を含むペイロード フィールドをご覧ください。

次の例は、これらの命名規則がどのように適用されるかを示しています。

ログエントリ フィールド LogEntry 型マッピング BigQuery フィールド名
insertId insertId insertId
textPayload textPayload textPayload
httpRequest.status httpRequest.status httpRequest.status
httpRequest.requestMethod.GET httpRequest.requestMethod.[ABC] httpRequest.requestMethod.get
resource.labels.moduleid resource.labels.[ABC] resource.labels.moduleid
jsonPayload.MESSAGE jsonPayload.[ABC] jsonPayload.message
jsonPayload.myField.mySubfield jsonPayload.[ABC].[XYZ] jsonPayload.myfield.mysubfield

構造化ペイロード フィールドを BigQuery フィールド名にマッピングする場合、構造化フィールドに @type 指定子が含まれているとさらに複雑になります。これについては、以下で説明します。

@type を含むペイロード フィールド

このセクションでは、ログエントリのペイロードに型指定子(@type フィールド)が含まれている特別な BigQuery スキーマ フィールド名について説明します。これには、エクスポートされて BigQuery で保持されている監査ログエントリも含まれます。また、このセクションでは、監査ログエントリの protoPayload フィールドが BigQuery スキーマ フィールド protopayload_auditlog にマッピングされる理由についても説明します。

現在、BigQuery の監査ログエントリには 2 つのスキーマがあります。この 2 つのスキーマは、特定の監査ログペイロード情報で 2 つの異なる BigQuery フィールドが現在重複していることを意味します。古い方には「拡張」というフィールド名、新しい方には「コンパクト」というフィールド名が付けられており、同じ情報が異なるフォーマットで格納されています。2019 年 3 月 1 日に、古いスキーマ(フィールド名)が削除されます。詳細については、下記の更新されるスキーマへの移行を参照してください。

スキーマの命名規則

ログエントリのペイロードには構造化データを含めることができ、その構造化データにはネストされた構造化フィールドを含めることができます。すべての構造化フィールドには、オプションの型指定子を次の形式で含めることができます。

@type: type.googleapis.com/[TYPE]

型指定子を含む構造化フィールドには、フィールド名に [TYPE] が付いた BigQuery フィールド名が指定されます。

たとえば、次の表は、最上位の構造化ペイロード フィールドの BigQuery フィールド名へのマッピングを示しています。

ペイロード ペイロード @type ペイロード フィールド BigQuery フィールド名
jsonPayload (なし) statusCode jsonPayload.statusCode
jsonPayload type.googleapis.com/abc.Xyz statusCode jsonPayload_abc_xyz.statuscode
protoPayload (なし) statusCode protoPayload.statuscode
protoPayload type.googleapis.com/abc.Xyz statusCode protopayload_abc_xyz.statuscode

jsonPayload または protoPayload に他の構造化フィールドが含まれている場合、これらの内部フィールドは次のようにマップされます。

  • ネストされた構造化フィールドに @type 指定子が含まれていない場合、小文字に正規化されることを除き、その BigQuery フィールド名は元のフィールド名と同じになります。
  • ネストされた構造化フィールドに @type 指定子が含まれている場合、その BigQuery フィールド名は、フィールド名に [TYPE](再表記)が付けられたものになり、小文字に正規化されます。

型指定子を含むフィールドでは、上記のルールにいくつかの例外があります。

  • App Engine のリクエストログでは、ペイロードに型指定子が含まれる場合でも、BigQuery にエクスポートされたログのペイロード名は protoPayload になります。クエリの App Engine のログクエリの例でこれを確認できます。

  • Stackdriver Logging では、監査ログの BigQuery スキーマ フィールド名を短縮するための特別なルールが適用されます。これについては、下記の監査ログスキーマのフィールドで説明します。

  • BigQuery にエクスポートされた監査ログは、更新されたコンパクトな形式で記述されています。一部のペイロード情報で、2 つのフィールドが一時的に重複しています。詳細については、更新されるスキーマへの移行を参照してください。

この例は、構造化ペイロード フィールドが BigQuery にエクスポートされたときに、どのような名前になり、どのように使用されるかを示しています。

ログエントリのペイロードが次のように構成されているとします。

jsonPayload: {
  name_a: {
    sub_a: "A value"
  }
  name_b: {
    @type: "type.googleapis.com/google.cloud.v1.SubType"
    sub_b: 22
  }
}

BigQuery フィールドへのマッピングは次のとおりです。

  • フィールド jsonPayloadname_a は構造化されていますが、@type 指定子はありません。BigQuery での名前はそれぞれ jsonPayloadname_a になります。

  • フィールド sub_asub_b は構造化されていないため、BigQuery での名前はそれぞれ sub_asub_b になります。

  • フィールド name_b には @type 指定子があり、[TYPE] は google.cloud.v1.SubType です。したがって、BigQuery での名前は name_b_google_cloud_v1_subtype になります。

つまり、ログエントリのペイロードに対して次の 5 つの BigQuery 名が定義されます。

jsonPayload
jsonPayload.name_a
jsonPayload.name_a.sub_a
jsonPayload.name_b_google_cloud_v1_subtype
jsonPayload.name_b_google_cloud_v1_subtype.sub_b

エクスポートされた監査ログスキーマのフィールド

BigQuery にエクスポートされた監査ログを扱わない場合は、このセクションをスキップできます。

Stackdriver では、古い(「拡張」)監査ログのすべての監査ログペイロード フィールドに型指定子(@type フィールド)が付与されています。対応する BigQuery フィールド名は、長くなりすぎないように特別な構成になっています。

新しい(「コンパクト」)監査ログ ペイロード フィールド、protoPayload.requestprotoPayload.responseprotoPayload.metadata には、@type 型指定子が付与されていますが、JSON データとして扱われます。つまり、それらの BigQuery スキーマ名は、フィールド名に Json が追加され、JSON 形式の文字列データを含む形式になります。

次の表に、これら 2 つの監査ログ ペイロード フィールド名を示します。

ログエントリ フィールド 拡張(旧)BigQuery フィールド名 コンパクト(新)BigQuery フィールド名
protoPayload protopayload_auditlog 同じ
protopayload.metadata protopayload_auditlog.metadata_ * protopayload_auditlog.metadataJson
protoPayload.serviceData protopayload_auditlog.servicedata_v1_bigquery
例: protopayload_auditlog.servicedata_v1_bigquery.tableInsertRequest
同じ
protoPayload.request protopayload_auditlog.request_[Vn]_[PROTO_NAME]
Example: protopayload_auditlog.request_v2_listlogsinksrequest
protopayload_auditlog.requestJson
protoPayload.response protopayload_auditlog.response_[Vn]_[PROTO_NAME]
Example: protopayload_auditlog.response_v2_listlogsinksresponse
protopayload_auditlog.responseJson

2019 年 3 月 1 日に古い拡張スキーマ(フィールド名)が削除される前に、新しいコンパクト スキーマ(フィールド名)を使用するようにクエリを修正する必要があります。

監査ログの命名については、次の点に注意してください。

  • serviceData 命名規則は、BigQuery によって生成され、BigQuery にエクスポートされる監査ログに固有です。これらの監査ログエントリには、次のような @type 指定子がある serviceData フィールドが含まれています。

    type.googleapis.com/google.cloud.bigquery.logging.v1.auditdata
    
  • 拡張(旧)フィールドの request フィールドと response フィールドの命名規則は、型指定子が共通のパターンに従っていることを前提としています。

    [GOOGLE_SERVICE].[Vn].[PROTO_NAME]
    

    たとえば、request フィールドでは指定子は次のようになります。

    google.logging.v2.ListLogSinksRequest
    

    ピリオドをアンダースコアに置き換えて小文字に変更すると、次のフィールド名になります。

    request_google_logging_v2_listlogsinksrequest
    

    特別に構成されたスキーマ フィールド名は次のとおりです。

    request_v2_listlogsinksrequest
    

    パターンの異なる型指定子を検出した場合は、エクスポートされたログエントリを調べて、エクスポートされたフィールド名がどのように短縮されているかを確認します。

BigQuery によって生成された監査ログエントリには、次の名前のフィールドがあります。

protoPayload.serviceData.tableInsertRequest

このログエントリが BigQuery にエクスポートされた場合、tableInsertRequest フィールドはどのように参照されますか。名前を短縮する前、対応するエクスポートされたフィールド名は次のようになります。

protopayload_google_cloud_audit_auditlog.servicedata_google_cloud_bigquery_logging_v1_auditdata.tableInsertRequest

名前の短縮後、同じフィールドが BigQuery テーブルでは次のように参照されます。

protopayload_auditlog.servicedata_v1_bigquery.tableInsertRequest

更新されるスキーマへの移行

現在、BigQuery の監査ログエントリには、「拡張」と「コンパクト」の 2 つのフィールド名があります。2019 年 3 月 1 日に、「拡張」のフィールド名が削除されます。使用しているクエリを見直し、新しいフィールド名に移行する必要があるかどうかを確認してください。

  • 現在、BigQuery クエリでエクスポートされた監査ログの requestresponserequestMetadata フィールドを使用していない場合は、この移行による影響を受けません。このセクションはスキップしてください。

  • requestresponserequestMetadata フィールドを初めて使用する場合は、最初からコンパクト(新)フィールド名を使用してください。新しいサービスを対象にして生成される監査ログでは、新しい「コンパクト」形式のみが使用されます。このセクションはスキップしてください。

  • 現在、BigQuery クエリでエクスポートされた監査ログの requestresponserequestMetadata フィールドを使用しており、拡張(旧)フィールド名を使用している場合は、できるだけ早期にコンパクト(新)フィールド名に切り替えてください。クエリの更新方法の例については、このセクションとクエリの更新を参照してください。

この変更は、管理アクティビティとデータアクセスの両方の監査ログに影響し、現在の拡張形式から更新されたコンパクトな JSON 形式に変換されます(フィールド数は任意)。既存の監査ログの場合、Stackdriver Logging では、すでに新しい「コンパクト」形式で書き込みが行われます。

コンパクト スキーマ

拡張フォーマットが削除される 2019 年 3 月 1 日まで、BigQuery では両方のフォーマットを使用できます。

監査ログ以外のエクスポートは、影響を受けません。BigQuery 以外の場所への監査ログのエクスポートも、影響を受けません。

クエリの更新

監査ログスキーマのフィールドのテーブルには、拡張フィールド名からコンパクト フィールド名への変更によって影響を受けるフィールドが一覧表示されます。これらのフィールドに対してクエリを実行する場合は、古いフィールドが削除される 2019 年 3 月 1 日までに、必要に応じて BigQuery のクエリを見直す必要があります。

クエリを更新するには、BigQuery JSON_EXTRACT() メソッドを使用する必要があります。これらのフィールドの @type 指定子は、JSON データのコンテンツの記述として扱われる必要があります。

例として、拡張フィールド名の場合の、createSinkRequest フィールドの 1 つを選択するクエリを以下に示します。

 SELECT protopayload_auditlog.request_v2_createsinkrequest.sink.destination
 as dest FROM ...

コンパクト フィールド名を変更すると、構文は次のようになります。

SELECT JSON_EXTRACT(protopayload_auditlog.requestJson, '$.sink.destination')
as dest FROM ...

監査ログの表示

既存の監査ログの場合、Stackdriver Logging では、新しい「コンパクト」形式と古い「拡張」形式の両方で書き込みが行われます。拡張フォーマットが削除される 2019 年 3 月 1 日まで、BigQuery では両方のフォーマットを使用できます。

監査ログを確認するには、BigQuery ウェブ UI でエクスポートされたログエントリのテーブルを選択します。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。