エクスポートされたログに対する 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 フィールドへのマッピングは次のとおりです。
フィールド
jsonPayloadとname_aは構造化されていますが、@type指定子はありません。BigQuery での名前はそれぞれjsonPayloadとname_aになります。フィールド
sub_aとsub_bは構造化されていないため、BigQuery での名前はそれぞれsub_aとsub_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.request、protoPayload.response、protoPayload.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 クエリでエクスポートされた監査ログの
request、response、requestMetadataフィールドを使用していない場合は、この移行による影響を受けません。このセクションはスキップしてください。request、response、requestMetadataフィールドを初めて使用する場合は、最初からコンパクト（新）フィールド名を使用してください。新しいサービスを対象にして生成される監査ログでは、新しい「コンパクト」形式のみが使用されます。このセクションはスキップしてください。現在、BigQuery クエリでエクスポートされた監査ログの
request、response、requestMetadataフィールドを使用しており、拡張（旧）フィールド名を使用している場合は、できるだけ早期にコンパクト（新）フィールド名に切り替えてください。クエリの更新方法の例については、このセクションとクエリの更新を参照してください。
この変更は、管理アクティビティとデータアクセスの両方の監査ログに影響し、現在の拡張形式から更新されたコンパクトな 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 の