課金利用ログの配信とアクセス

プレビュー

この機能は パブリックプレビュー版です。

注：

課金利用ログはすべての製品の使用状況を記録するわけではありません。 Databricks では、完全な使用ログを表示するにはシステムテーブルを使用することをお勧めします。

Databricks アカウント管理者は、CSV ファイル形式の課金対象の使用状況ログを AWS S3 ストレージ バケットに毎日配信するように設定し、 そこでデータを使用状況分析に使用できるようにすることができます。 Databricks は、アカウント内のワークスペースごとに個別の CSV ファイルを配信します。 この CSV ファイルには、Databricks ユニット (DBU) でのワークスペースのクラスター使用状況に関するヒストリカルデータが含まれており、クラスター ID、課金 SKU、クラスター作成者、クラスター タグなどで並べ替えることができます。 各 CSV ファイル列の説明については、「 CSV ファイルのスキーマ」を参照してください。

APIを使用して、ログ配信を設定せずに課金利用ログをダウンロードするには、 課金利用ログの返却を参照してください。

アカウント管理者は、アカウントコンソールの使用状況ページで使用状況をグラフまたは表形式で見ることができます。このページには、ワークロードの種類別にグループ化されたアカウントの使用状況をDBUで表示する使用状況チャートも含まれており、使用状況データをCSV形式で直接ダウンロードすることができます。

アカウントが別のバージョンのプラットフォームにある場合、アカウント所有者はレガシーアカウントコンソールの「使用状況の概要」タブで使用状況を確認できます。

オプションで、ログ配信用に作成したIAMロールに使用されるアカウント以外のAWSアカウントにログを配信することができます。これにより、たとえば複数のAWSアカウントから同じS3バケットに配信するワークスペースを設定するなど、柔軟な対応が可能になります。このオプションでは、クロスアカウントIAMロールを参照するS3バケットポリシーを設定する必要があります。この記事では、その手順とポリシーテンプレートを提供しています。

アカウント所有者とアカウント管理者のログへのアクセスは、S3バケットの設定方法によって異なります。Databricksは、AWS組み込みのBucketOwnerFullControl Canned ACLを使用してS3バケットにログを配信するため、アカウントの所有者および指定されたユーザーはログを直接ダウンロードできます。新しく作成されたオブジェクトのバケット所有権をサポートするには、バケットの「S3オブジェクト所有権」設定を「バケット所有者の優先」値に設定する必要があります。

重要

代わりに、バケットの「S3オブジェクト所有権」設定を「オブジェクトライター」にすると、ログなどの新しいオブジェクトは、アップロードアカウント（デフォルトでは、バケットにアクセスするために作成および指定したIAMロール）が所有したままになります。この場合、AWSコンソールやバケット所有者として認証された自動化ツールからアクセスすることはできないため、ログにアクセスするのが難しくなります。

Databricksは、バケット内のデータを不要なアクセスから保護するためのガイダンスとして、S3のセキュリティベストプラクティスを確認することをお勧めしています。

実行中のワークスペースのログの配信に加えて、キャンセルされたワークスペースのログも配信され、ワークスペースの最終日を表すログが適切に配信されるようになります。

構成オプション

アカウントに複数のワークスペースがある場合、課金利用ログ配信を構成するときに、以下のオプションを利用できます。

• アカウント内のすべてのワークスペースで同じ構成（ログ配信S3バケットとIAMロール）を共有する。これがデフォルトです。

• アカウント内の各ワークスペースに個別の構成を使用する。

• ワークスペースのグループごとに個別の構成を使用し、グループ内で構成を共有する。

注：

アカウントAPIを使用してログ配信を構成する場合でも、アカウントAPIを使用して作成されていないワークスペースを含め、任意のワークスペースでログ配信を構成できます。

大まかなフロー

課金利用ログ配信の大まかなフロー

1. ストレージの設定: AWS で、新しい AWS S3 バケットを作成します。 Databricks APIsを使用して、アカウント API を呼び出して、バケット名を使用するストレージ設定オブジェクトを作成します。

   注：

   ログ配信用に作成したIAMロールに使用されるアカウント以外のAWSアカウントにログを配信するには、S3バケットポリシーを追加する必要があります。このステップではポリシーを追加せず、後のステップで追加します。

2. 認証情報の設定: AWS で、適切な AWS IAMロールを作成します。 Databricks APIsを使用して、アカウント API を呼び出して、IAM ロールの ARN を使用する認証情報設定オブジェクトを作成します。 ロールポリシーでは、S3 バケット内のログ配信のパスプレフィックスを指定できます。 S3 バケットを共有し、異なるパスプレフィックスを使用する異なるワークスペースのログ配信設定が必要な場合は、複数のパスプレフィックスを含めるように IAMロールを定義することを選択できます。

3. オプションのクロスアカウントサポート ログ配信用に作成した IAM ロールのアカウント以外の AWS アカウントにログを配信するには、S3 バケットポリシーを追加します。 このポリシーは、前のステップで作成したクロスアカウント IAM ロールの ID を参照します。

4. ログ配信 API を呼び出す: アカウント API を呼び出して、前のステップの認証情報とストレージ設定オブジェクトを使用するログ配信設定を作成します。 このステップ では、アカウント全体 (現在および将来のワークスペース) にログ配信設定を関連付けるか、特定のワークスペースセットに関連付けるかを指定できます。

5. 分析のためにCSVファイルにアクセスします。 配信場所は <bucket-name>/<prefix>/billable-usage/csv/です ここで、 <prefix> は、ログ配信の構成時に設定したオプションの配信パス接頭辞の名前です。 ファイルの名前は workspaceId=<workspace-id>-usageMonth=<month>.csvです。 ファイルは、ワークスペースごとにその月の CSV ファイルを上書きすることで毎日配信されます。 このデータを分析のために Databricks にインポートできます。 これらの CSV ファイルに基づいて利用状況分析ダッシュボードを実行するために使用できるサンプル ノートブックもあります。 「 Databricks での使用状況データの分析」を参照してください。

重要

アカウントに対して作成できるログ配信設定の数には制限があります。アカウントレベルを使用する有効な構成を2つ（ワークスペースフィルターなし）、特定のワークスペースごとに有効な構成を2つまで作成できます（2つの構成のワークスペースフィルターにworkspaceIdを含めることができます）。ログ配信設定を削除することはできませんが、無効にすることはできます。無効にした構成を再度有効にすることはできますが、前述の制限に違反するとリクエストが失敗します。

要件

• アカウント管理者である必要があります

• アカウント ID。 アカウント ID は アカウントコンソールで確認できます。

アカウントAPIへの認証方法

アカウント API に対して認証するには、サービスプリンシパル用の Databricks OAuth、ユーザー用の Databricks OAuth、または Databricks アカウント管理者のユーザー名とパスワードを使用できます。 Databricks では、ユーザーまたはサービスプリンシパルに Databricks OAuth を使用することを強くお勧めします。 サービスプリンシパルは、自動化ツール、ジョブ、アプリケーションで使用するために Databricks で作成する ID です。 「OAuth マシン間 (M2M) 認証」を参照してください。

次の例を使用して、Databricks アカウントに対して認証を行います。 サービスプリンシパルの OAuth、ユーザーの OAuth、またはユーザーのユーザー名とパスワード (レガシー) を使用できます。 背景については、以下を参照してください。

• サービスプリンシパルのOAuthについては、「OAuthマシン間(M2M)認証」を参照してください。

• ユーザーのOAuthについては、「 OAuthユーザーからマシン(U2M)認証」を参照してください。

• ユーザーのユーザー名とパスワード (レガシ) については、「 基本認証 (レガシー)」を参照してください。

認証の例については、以下から選択してください。

1. Databricks CLI バージョン 0.205 以降をインストールします。 「Databricks CLI のインストールまたは更新」を参照してください。

2. ステップを完了して、アカウント内のサービスプリンシパルのOAuth M2M認証を設定します。 OAuthマシン間(M2M)認証を参照してください。

3. .databrickscfg ファイルで Databricks 構成プロファイルを特定するか、手動で作成し、関連する host、 account_id、 client_id 、およびサービスプリンシパルへのclient_secretマッピングに対してプロファイルのフィールドが正しく設定されます。OAuthマシン間(M2M)認証を参照してください。

4. 対象のDatabricks CLIコマンドを実行します。ここで、<profile-name>は.databrickscfgファイル内の構成プロファイルの名前を表します。

   databricks account <command-name> <subcommand-name> -p <profile-name>
   

   たとえば、アカウント内のすべてのユーザーを一覧表示するには、以下のようにします。

   databricks account users list -p MY-AWS-ACCOUNT
   

   • 使用可能なアカウントコマンドを一覧表示するには、コマンドdatabricks account -hを実行します。

   • accountコマンドで使用可能なサブコマンドを一覧表示するには、コマンドdatabricks account <command-name> -hを実行します。

1. Databricks CLI バージョン 0.205 以降をインストールします。 「Databricks CLI のインストールまたは更新」を参照してください。

2. ステップを完了して、アカウント内のユーザーのOAuth U2M認証を構成します。 OAuthユーザーからマシン(U2M)への認証を参照してください。

3. 以下のDatabricks CLIコマンドを実行して、ユーザー認証プロセスを開始します。

   databricks auth login --host <account-console-url> --account-id <account-id>
   

   例：

   databricks auth login --host https://accounts.cloud.databricks.com --account-id 00000000-0000-0000-0000-000000000000
   

   注：

   host フィールドと account_id フィールドが既に設定されている既存の Databricks 構成プロファイルがある場合は、--host <account-console-url> --account-id <account-id> を --profile <profile-name>に置き換えることができます。

4. 画面の指示に従って、Databricks CLIが関連するDatabricks構成プロファイルを.databrickscfg ファイルに自動的に作成します。

5. 画面の指示に従って、WebブラウザからDatabricksアカウントにサインインします。

6. 対象のDatabricks CLIコマンドを実行します。ここで、<profile-name>は.databrickscfgファイル内の構成プロファイルの名前を表します。

   databricks account <command-name> <subcommand-name> -p <profile-name>
   

   たとえば、アカウント内のすべてのユーザーを一覧表示するには、以下のようにします。

   databricks account users list -p ACCOUNT-00000000-0000-0000-0000-000000000000
   

   • 使用可能なアカウントコマンドを一覧表示するには、コマンドdatabricks account -hを実行します。

   • accountコマンドで使用可能なサブコマンドを一覧表示するには、コマンドdatabricks account <command-name> -hを実行します。

1. Databricks CLI バージョン 0.205 以降をインストールします。 「Databricks CLI のインストールまたは更新」を参照してください。

2. .databrickscfg ファイルで Databricks 構成プロファイルを特定するか、手動で作成し、関連する host、 account_id、 username 、および Databricks ユーザー アカウントへのpasswordマッピング用にプロファイルのフィールドが正しく設定されます。「 基本認証 (レガシー)」を参照してください。

3. 対象のDatabricks CLIコマンドを実行します。ここで、<profile-name>は.databrickscfgファイル内の構成プロファイルの名前を表します。

   databricks account <command-name> <subcommand-name> -p <profile-name>
   

   たとえば、アカウント内のすべてのユーザーを一覧表示するには、以下のようにします。

   databricks account users list -p MY-AWS-ACCOUNT
   

   • 使用可能なアカウントコマンドを一覧表示するには、コマンドdatabricks account -hを実行します。

   • accountコマンドで使用可能なサブコマンドを一覧表示するには、コマンドdatabricks account <command-name> -hを実行します。

ステップ1：ストレージを構成する

Databricksは、課金利用データをアカウントのS3バケットに配信します。複数のワークスペースが単一のS3バケットを使用するように構成することも、ワークスペース（またはワークスペースのグループ）ごとに異なるバケットを使用するように定義することもできます。

この手順では、アカウントの1つ以上のワークスペースに共通の構成で単一の構成オブジェクトを設定する方法について説明します。ワークスペースごとに異なる保存場所を使用するには、ワークスペースまたはワークスペースのグループごとにこの記事の手順を繰り返してください。

1. 「ステップ1：監査ログストレージを構成する」の手順に従って、S3バケットを作成します。

   重要

   Databricks ワークスペースに使用されているアカウント以外の AWS アカウントにログを配信するには、S3 バケットポリシーを追加する必要があります。 このステップではバケットポリシーを追加しません。 「ステップ 3: オプションのクロスアカウントサポート」を参照してください。

2. 新しい S3 バケットを表す Databricks ストレージ構成レコードを作成します。 新しいストレージ設定の作成 API (POST /accounts/<account-id>/storage-configurations) を呼び出して、S3 バケットを指定します。

   以下を指定します。

   • storage_configuration_name — 新しい一意のストレージ構成名。

   • root_bucket_info — S3バケット名を含むbucket_nameフィールドを含むJSONオブジェクト。

   応答本文で返されたstorage_configuration_id値をコピーします。この設定は、後のステップでログ配信設定を作成するために使用します。

   例：

   curl -X POST
       'https://accounts.cloud.databricks.com/api/2.0/accounts/<databricks-account-id>/storage-configurations' \
     --header 'Authorization: Bearer $OAUTH_TOKEN' \
     -d '{
       "storage_configuration_name": "databricks-workspace-storageconf-v1",
       "root_bucket_info": {
         "bucket_name": "my-company-example-bucket"
       }
     }'
   

   応答：

   {
     "storage_configuration_id": "<databricks-storage-config-id>",
     "account_id": "<databricks-account-id>",
     "root_bucket_info": {
       "bucket_name": "my-company-example-bucket"
     },
     "storage_configuration_name": "databricks-workspace-storageconf-v1",
     "creation_time": 1579754875555
   }
   

ステップ2：資格情報を構成する

この手順では、アカウントの1つ以上のワークスペースに共通の構成で単一の構成オブジェクトを設定する方法について説明します。ワークスペースごとに異なる資格情報を使用するには、各ワークスペースまたはワークスペースのグループに対してこの記事の手順を繰り返します。

注：

異なるS3バケット名を使用するには、別のIAMロールを作成する必要があります。

1. 管理者権限を持つユーザーとしてAWSコンソールにログインし、IAMサービスに移動します。

2. サイドバーの「ロール」タブをクリックします。

3. 「ロールの作成」をクリックします。

   1. 「信頼できるエンティティの種類の選択」で、「AWSサービス」を選択します。

   2. 「一般的なユースケース」で、「EC2」をクリックします。

   3. 「次へ：権限」ボタンをクリックします。

   4. 「次へ：タグ」ボタンをクリックします。

   5. 「次へ：確認」ボタンをクリックします。

   6. 「ロール名」フィールドにロール名を入力します。

      

   7. 「ロールの作成」をクリックします。ロールのリストが表示されます。

4. ロールのリストで、作成したロールをクリックします。

5. インラインポリシーを追加します。

   1. 「権限」タブで、「インラインポリシーを追加」をクリックします。

      

   2. ポリシーエディターで、「JSON」タブをクリックします。

      

   3. このアクセスポリシーをコピーして変更します。ポリシー内の以下の値を独自の設定値に置き換えます：

      • <s3-bucket-name>：AWS S3バケットのバケット名。

      • <s3-bucket-path-prefix>: (オプション) S3 バケット内の配信場所へのパス。 指定しない場合、ログはバケットのルートに配信されます。 このパスは、 ログ配信 API を呼び出すときの delivery_path_prefix 引数と一致する必要があります。

      {
        "Version":"2012-10-17",
        "Statement":[
          {
            "Effect":"Allow",
            "Action":[
              "s3:GetBucketLocation"
            ],
            "Resource":[
              "arn:aws:s3:::<s3-bucket-name>"
            ]
          },
          {
            "Effect":"Allow",
            "Action":[
              "s3:PutObject",
              "s3:GetObject",
              "s3:DeleteObject",
              "s3:PutObjectAcl",
              "s3:AbortMultipartUpload"
            ],
            "Resource":[
              "arn:aws:s3:::<s3-bucket-name>/<s3-bucket-path-prefix>/",
              "arn:aws:s3:::<s3-bucket-name>/<s3-bucket-path-prefix>/*"
            ]
          },
          {
            "Effect":"Allow",
            "Action":[
              "s3:ListBucket",
              "s3:ListMultipartUploadParts",
              "s3:ListBucketMultipartUploads"
            ],
            "Resource":"arn:aws:s3:::<s3-bucket-name>",
            "Condition":{
              "StringLike":{
                "s3:prefix":[
                  "<s3-bucket-path-prefix>",
                  "<s3-bucket-path-prefix>/*"
                ]
              }
            }
          }
        ]
      }
      

      パスプレフィックスのポリシー使用をカスタマイズできます。

      • バケットパスプレフィックスを使用したくない場合は、<s3-bucket-path-prefix>/（末尾のスラッシュを含む）が表示されるたびにポリシーから削除します。

      • S3バケットを共有しているが異なるパスプレフィックスを使用している別のワークスペース用にログ配信設定が必要な場合は、複数のパスプレフィックスを含めるようにIAMロールを定義できます。ポリシーでは、2カ所で<s3-bucket-path-prefix>を参照しています。それぞれで、パスプレフィックスを参照する2つの隣接する行を複製します。新しいパスプレフィックスごとに各行のペアを繰り返します。例：

      {
        "Resource":[
          "arn:aws:s3:::<mybucketname>/field-team/",
          "arn:aws:s3:::<mybucketname>/field-team/*",
          "arn:aws:s3:::<mybucketname>/finance-team/",
          "arn:aws:s3:::<mybucketname>/finance-team/*"
        ]
      }
      

   4. 「ポリシーの確認」をクリックします。

   5. 「名前」フィールドにポリシー名を入力します。

   6. 「ポリシーの作成」をクリックします。

   7. AWSアカウントレベルで特定のアクションを拒否するためにService Control Policiesを使用する場合、Databricksがクロスアカウントロールを引き受けることができるようにsts:AssumeRoleがホワイトリストに登録されていることを確認します。

6. ロールの概要ページで、「信頼関係」タブをクリックします。

7. このアクセス ポリシーをエディターに貼り付け、ポリシー内の次の値を独自の構成値に置き換えます。 ポリシーでは、Databricks AWS アカウント ID 414351767826を使用します。 Databricks on AWS GovCloudで Databricksを使用している場合は、 Databricksアカウント ID 044793339203 を使用してください。

   <databricks-account-id>：DatabricksアカウントID。

   {
     "Version":"2012-10-17",
     "Statement":[
       {
         "Effect":"Allow",
         "Principal":{
           "AWS":"arn:aws:iam::414351767826:role/SaasUsageDeliveryRole-prod-IAMRole-3PLHICCRR1TK"
         },
         "Action":"sts:AssumeRole",
         "Condition":{
           "StringEquals":{
             "sts:ExternalId":[
               "<databricks-account-id>"
             ]
           }
         }
       }
     ]
   }
   

8. 後の手順で使用するため、ロールの概要でロールARNをコピーして保存してください。

   

9. AWS ロールの Databricks 認証情報設定 ID を作成します。 資格情報構成の作成 API (POST /accounts/<account-id>/credentials) を呼び出します。このリクエストはクロスアカウント信頼を確立し、新しいワークスペースを作成するときに使用する参照 ID を返します。

   <account-id>をDatabricksのアカウントIDに置き換えます。さらにリクエスト本文で以下を実施します。

   • credentials_nameにはアカウント内で一意の名前に設定します。

   • aws_credentialsをsts_roleプロパティを含むオブジェクトに設定します。このオブジェクトには、作成したロールのrole_arnを指定する必要があります。

   応答本文には、新しいワークスペースを作成するために必要なDatabricks認証情報構成IDであるcredentials_idフィールドが含まれます。このフィールドをコピーしておくことで、後の手順でログ配信設定を作成するために使用することができます。

   例：

    curl -X POST
      'https://accounts.cloud.databricks.com/api/2.0/accounts/<databricks-account-id>/credentials' \
     --header 'Authorization: Bearer $OAUTH_TOKEN' \
      -d '{
      "credentials_name": "databricks-credentials-v1",
      "aws_credentials": {
        "sts_role": {
          "role_arn": "arn:aws:iam::<aws-account-id>:role/my-company-example-role"
        }
      }
    }'
   

   応答例：

    {
      "credentials_id": "<databricks-credentials-id>",
      "account_id": "<databricks-account-id>",
      "aws_credentials": {
        "sts_role": {
          "role_arn": "arn:aws:iam::<aws-account-id>:role/my-company-example-role",
          "external_id": "<databricks-account-id>"
        }
      },
      "credentials_name": "databricks-credentials-v1",
      "creation_time": 1579753556257
    }
   

   後で使用するために、応答からcredentials_idフィールドをコピーします。

ステップ3：オプションのクロスアカウントサポート

S3バケットがログ配信に使用されるIAMロールと同じAWSアカウントにある場合は、このステップをスキップしてください。

ログ配信用に作成したIAMロールに使用されるアカウント以外のAWSアカウントにログを配信するには、以下のようにS3バケットポリシーを追加します。このポリシーでは、前のステップで作成したクロスアカウントIAMロールのIDを参照します。

1. AWSコンソールで、S3サービスに移動します。

2. バケット名をクリックします。

3. 「権限」タブをクリックします。

4. 「バケットポリシー」ボタンをクリックします。

   

5. このバケットポリシーをコピーして変更します。

   <s3-bucket-name>をS3バケット名に置き換えます。<customer-iam-role-id>を新しく作成したIAMロールのロールIDに置き換えます。<s3-bucket-path-prefix>を目的のバケットパスプレフィックスに置き換えます。パスプレフィックスのカスタマイズについては、ポリシーサンプルの後に記載されている注記を参照してください。

   {
     "Version": "2012-10-17",
     "Statement": [
         {
             "Effect": "Allow",
             "Principal": {
                 "AWS": ["arn:aws:iam::<customer-iam-role-id>"]
             },
             "Action": "s3:GetBucketLocation",
             "Resource": "arn:aws:s3:::<s3-bucket-name>"
         },
         {
             "Effect": "Allow",
             "Principal": {
                 "AWS": "arn:aws:iam::<customer-iam-role-id>"
             },
             "Action": [
                 "s3:PutObject",
                 "s3:GetObject",
                 "s3:DeleteObject",
                 "s3:PutObjectAcl",
                 "s3:AbortMultipartUpload",
                 "s3:ListMultipartUploadParts"
             ],
             "Resource": [
                 "arn:aws:s3:::<s3-bucket-name>/<s3-bucket-path-prefix>/",
                 "arn:aws:s3:::<s3-bucket-name>/<s3-bucket-path-prefix>/*"
             ]
         },
         {
             "Effect": "Allow",
             "Principal": {
                 "AWS": "arn:aws:iam::<customer-iam-role-id>"
             },
             "Action": "s3:ListBucket",
             "Resource": "arn:aws:s3:::<s3-bucket-name>",
             "Condition": {
                 "StringLike": {
                     "s3:prefix": [
                         "<s3-bucket-path-prefix>",
                         "<s3-bucket-path-prefix>/*"
                     ]
                 }
             }
         }
     ]
   }
   

   パスプレフィックスのポリシー使用をカスタマイズできます。

   • バケットパスプレフィックスを使用したくない場合は、<s3-bucket-path-prefix>/（末尾のスラッシュを含む）が表示されるたびにポリシーから削除します。

   • 同じS3バケットを共有しているが異なるパスプレフィックスを使用している複数のワークスペース用にログ配信設定が必要な場合は、複数のパスプレフィックスを含めるようにIAMロールを定義できます。ポリシーでは、2カ所で<s3-bucket-path-prefix>を参照しています。それぞれの場所で、パスプレフィックスを参照する2つの隣接する行を複製します。新しいパスプレフィックスごとに各行のペアを繰り返します。例：

     {
       "Resource":[
         "arn:aws:s3:::<mybucketname>/field-team/",
         "arn:aws:s3:::<mybucketname>/field-team/*",
         "arn:aws:s3:::<mybucketname>/finance-team/",
         "arn:aws:s3:::<mybucketname>/finance-team/*"
       ]
     }
     

ステップ4：ログ配信APIをコールする

ログ配信を構成するには、 ログ配信構成 API (POST /accounts/<account-id>/log-delivery) を呼び出します。

前の手順でコピーした以下の値が必要です。

• credentials_id：クロスアカウントロール資格情報を表すDatabricks資格情報構成ID。

• storage_configuration_id：お客様のDatabricksルートS3バケットを表すストレージ構成ID。

以下のフィールドも設定します。

• log_type：常にBILLABLE_USAGEに設定します。

• output_format:常に CSVに設定されます。 CSV ファイル形式の詳細については、 「課金利用ログ スキーマ (レガシー)」を参照してください。

• delivery_path_prefix：（オプション）パスプレフィックスに設定します。これは、ロールポリシーで使用したパスプレフィックスと一致する必要があります。

• workspace_ids_filter：（オプション）デフォルトでは、このログ構成はアカウントIDに関連付けられたすべてのワークスペースに適用されます。一部のタイプのデプロイメントでは、ワークスペースがアカウントIDごとに1つだけであるため、このフィールドは不要です。もともとアカウントAPIを使用してワークスペースを作成するためにアカウントを作成していた場合、アカウントIDに複数のワークスペースが関連付けられている可能性があります。オプションで、このフィールドをこの構成が適用されるワークスペースIDの配列に設定することができます。ワークスペースごとに異なるログ配信設定を使用する予定がある場合は、これを空白のままにするのではなく、明示的に設定します。これを空白のままにした場合、今後お客様のアカウントIDを追加のワークスペースに関連付けると、この構成が新しいワークスペースにも適用されます。ワークスペースが複数のログ配信設定に適用される場合があり、その場合、ログは複数の場所に書き込まれます。

  重要

  アカウントに対して作成できるログ配信設定の数には制限があります。アカウントレベルを使用する有効な構成を2つ（ワークスペースフィルターなし）、特定のワークスペースごとに有効な構成を2つまで作成できます（2つの構成のワークスペースフィルターにworkspaceIdを含めることができます）。ログ配信設定を削除することはできませんが、無効にすることはできます。無効にした構成を再度有効にすることはできますが、前述の制限に違反するとリクエストが失敗します。

• delivery_start_time：（オプション）ログ配信が開始される月と年。デフォルトは現在の月です。形式は、YYYY-MM形式のテキストです。2019-03以降の任意の月と年を入力できます。

例：

curl -X POST
  'https://accounts.cloud.databricks.com/api/2.0/accounts/<databricks-account-id>/log-delivery' \
  --header 'Authorization: Bearer $OAUTH_TOKEN' \
  -d '{
  "log_delivery_configuration": {
    "log_type": "BILLABLE_USAGE",
    "config_name": "billable usage config",
    "output_format": "CSV",
    "credentials_id": "<databricks-credentials-id>",
    "storage_configuration_id": "<databricks-storage-config-id>",
    "delivery_path_prefix": "usage-data",
    "delivery_start_time": "2020-06",
    "workspace_ids_filter": [
        6383650456894062,
        4102272838062927
    ]
    }
}'

応答例：

{
    "log_delivery_configuration": {
        "config_id": "<config-id>",
        "config_name": "billable usage config",
        "log_type": "BILLABLE_USAGE",
        "output_format": "CSV",
        "account_id": "<account-id>",
        "credentials_id": "<databricks-credentials-id>",
        "storage_configuration_id": "<databricks-storage-config-id>",
        "workspace_ids_filter": [
            6383650456894062,
            4102272838062927
        ],
        "delivery_path_prefix": "usage-data",
        "delivery_start_time": "2020-06",
        "status": "ENABLED",
        "creation_time": 1591638409000,
        "update_time": 1593108904000,
        "log_delivery_status": {
          "status": "CREATED",
          "message": "Log Delivery Configuration is successfully created. Status will be updated after the first delivery attempt."
        }
    }
}

ログ配信APIの追加機能

ログ配信APIsには追加機能があります。詳細については、API リファレンス ドキュメントを参照してください。

追加の操作には以下のものがあります。

• すべてのログ配信設定を取得する

• IDでログ配信設定を取得する

• IDでログ配信設定の有効化または無効化する

ログ配信設定ステータスは、API応答のlog_delivery_statusオブジェクトで確認できます。log_delivery_statusを使用すると、ステータス（成功または失敗）と、最後に試行または成功した配信の時間を確認できます。

重要

アカウントに対して作成できるログ配信設定の数には制限があります。アカウントレベルを使用する有効な構成を2つ（ワークスペースフィルターなし）、特定のワークスペースごとに有効な構成を2つまで作成できます（2つの構成のワークスペースフィルターにworkspaceIdを含めることができます）。ログ配信設定を削除することはできませんが、無効にすることはできます。無効にした構成を再度有効にすることはできますが、前述の制限に違反するとリクエストが失敗します。

ステップ5：分析のためにログファイルにアクセスする

ログファイルは<bucket-name>/<prefix>/billable-usage/csv/に配信されます。ここで、<prefix>はログ配信設定中に設定したオプションの配信パスプレフィックスの名前です。ファイルの名前はworkspaceId=<workspace-id>-usageMonth=<month>.csvになります。ファイルは、ワークスペースごとに月のCSVファイルを上書きして毎日配信されます。

CSV スキーマについては、「 CSV ファイルのスキーマ」を参照してください。

Databricks を使用してこれらのファイルを分析する方法については、「 Databricks での使用状況データの分析」を参照してください。

Terraformを使用した自動構成

Databricks Terraformプロバイダーを使用すると、databricks_mws_log_deliveryリソースによって使用状況ログ配信を自動的に設定できます。以下は、使用状況ログと監査ログの配信のエンドツーエンドの例です。

variable "databricks_account_id" {
  description = "Account ID. You can get your account ID in the bottom left corner of the account console. See https://accounts.cloud.databricks.com"
}

resource "aws_s3_bucket" "logdelivery" {
  bucket = "${var.prefix}-logdelivery"
  acl    = "private"
  versioning {
    enabled = false
  }
  force_destroy = true
  tags = merge(var.tags, {
    Name = "${var.prefix}-logdelivery"
  })
}

resource "aws_s3_bucket_public_access_block" "logdelivery" {
  bucket             = aws_s3_bucket.logdelivery.id
  ignore_public_acls = true
}

data "databricks_aws_assume_role_policy" "logdelivery" {
  external_id = var.databricks_account_id
  for_log_delivery = true
}

resource "aws_iam_role" "logdelivery" {
  name               = "${var.prefix}-logdelivery"
  description        = "(${var.prefix}) UsageDelivery role"
  assume_role_policy = data.databricks_aws_assume_role_policy.logdelivery.json
  tags               = var.tags
}

data "databricks_aws_bucket_policy" "logdelivery" {
  full_access_role = aws_iam_role.logdelivery.arn
  bucket           = aws_s3_bucket.logdelivery.bucket
}

resource "aws_s3_bucket_policy" "logdelivery" {
  bucket = aws_s3_bucket.logdelivery.id
  policy = data.databricks_aws_bucket_policy.logdelivery.json
}

resource "databricks_mws_credentials" "log_writer" {
    account_id       = var.databricks_account_id
    credentials_name = "Usage Delivery"
    role_arn         = aws_iam_role.logdelivery.arn
}

resource "databricks_mws_storage_configurations" "log_bucket" {
    account_id                 = var.databricks_account_id
    storage_configuration_name = "Usage Logs"
    bucket_name                = aws_s3_bucket.logdelivery.bucket
}

resource "databricks_mws_log_delivery" "usage_logs" {
    account_id = var.databricks_account_id
    credentials_id = databricks_mws_credentials.log_writer.credentials_id
    storage_configuration_id = databricks_mws_storage_configurations.log_bucket.storage_configuration_id
    delivery_path_prefix = "billable-usage"
    config_name = "Usage Logs"
    log_type = "BILLABLE_USAGE"
    output_format = "CSV"
}

resource "databricks_mws_log_delivery" "audit_logs" {
    account_id = var.databricks_account_id
    credentials_id = databricks_mws_credentials.log_writer.credentials_id
    storage_configuration_id = databricks_mws_storage_configurations.log_bucket.storage_configuration_id
    delivery_path_prefix = "audit-logs"
    config_name = "Audit Logs"
    log_type = "AUDIT_LOGS"
    output_format = "JSON"
}