Azure Blobアクセスログ

こんにちは、for-dさん。

お元気でいらっしゃいますか!

Databricks から Azure Blob Storage に SAS トークンでアクセスして認証で弾かれているような場合、「どのログを見ればよいか」は大きく (1) Storage Analytics / 经典ログ と (2) Azure Monitor の診断ログ（Log Analytics/ Resource logs） の2系統になります。 公開フォーラム向けには、まず Databricks 側の通信が Blob に到達しているか／失敗しているか を、Blob の要求ログから追うのが定石です。

1) まず確認したい：Blob の要求ログ（失敗/成功を含む）

A. ストレージ分析のログ(クラシック/レガシー)

Storage Analytics ログは、Blob の操作ごとに要求詳細が記録され、成功/失敗の両方が追えます。 例としてドキュメント上に以下のようなログエントリがあります（Blob の例）。

• PutBlob の例（SAS 成功時のログ例） ログには PutBlob や SASSuccess のような情報が入っています。
• ログフォーマット（Analytics log format） GetBlob / PutBlob などの operation 名 や authenticated / anonymous、成功/失敗コード等が確認できます。

どの操作が記録されるかは、Databricks が実行している Blob 操作に依存します（例：ダウンロードなら GetBlob、アップロードなら PutBlob、コピーなら CopyBlob など）。

また、CopyBlob は 3 操作（CopyBlob, CopyBlobSource, CopyBlobDestination）に分かれてログされる点も注意です。

B. Azure Monitor resource logs(診断設定→Log Analytics / Event Hub など)

現在の推奨導線としては、ストレージアカウントで診断設定を有効化して、Storage Blob のログを Azure Monitor（特に Log Analytics）に送るのが一般的です。

この場合、Blob アクセスの追跡は StorageBlobLogs（テーブル/クエリ）を使って行います。 CallerIpAddress や RequesterUpn 等も取得して、SAS 由来か・送信元が意図通りか等を見られます。

• 「Storage Analytics logging is not enabled by default」なので、まずは診断設定でログ出力が有効になっているかを確認する、という流れがドキュメントで案内されています

2) どのログ “列” を見ればよいか（認証で弾かれている前提）

少なくとも次を見に行くと切り分けしやすいです。

• operation 名（Databricks が行っているのは GetBlob か PutBlob か、など）
• authentication の状態（例：authenticated / anonymous、SAS 成功/失敗に相当する値）
• 応答コード（成功/失敗）
• SAS/認証が絡む情報（診断ログ側ならクエリで取り出し）
• 送信元（Caller IP）（ネットワークFW/CIDR許可と整合するか）

ログが「入っている（有効化済み）」前提でない場合は、ここまでのログが参照できないので、まず診断設定の有効化確認が最優先になります。

3) 参考：Databricks → Blob の典型的な弾かれ要因（状況整理）

SAS が使える前提でも、次のようなものが「認証/権限/ネットワーク」で失敗につながります。

• SAS トークンの期限（st/se） や 開始時刻が未来 になっている
• SAS の sp（権限）不足（上書き等で必要権限が増えるケース）
• 生成したトークンの 形式不備 や 参照しているストレージアカウントキーの不一致
• Storage 側ファイアウォール/Private Endpoint/DNS 周り（許可されていない経路だと 403/失敗になり得る）

4) フォーラム回答用の結論（短く）

• 失敗/成功の Blob 要求を追うなら、Storage Analytics（classic） または Azure Monitor の診断ログ（StorageBlobLogs） を見ます。
• 現在の実務では、Databricks 側のアクセスを粒度よく追うために 診断設定→Log Analytics→StorageBlobLogs をクエリするのが分かりやすいです。
• その上で operation と認証状態（authenticated/SAS関連）と応答コード、Caller IP を確認します。

フォローアップの質問(必要な情報)

より的確に「どのログを見るべきか／どこが原因か」まで絞るため、次を教えてください。

1. Databricks からの操作は具体的に ダウンロード（GetBlob）、アップロード（PutBlob）、コピー（CopyBlob）どれですか？
2. 対象は 一般の Blob（階層なし） ですか？ それとも ADLS Gen2（hierarchical namespace） を使っていますか？
3. Storage アカウントの 診断設定（Diagnostic settings） は有効化済みですか？ （Log Analytics へ送っていますか？ ）
4. 現在参照できるログは Storage Analytics（classic） ですか？ それとも Log Analytics（StorageBlobLogs） ですか？
5. Databricks 側のエラーメッセージ（例：403 系で request not authorized 等）は何でしょうか？

提供された行動計画が役に立ったかどうか、ぜひ教えていただけますか?

ご質問やご不明点があればお知らせください。対応できるよう努めます。

もしこれらが質問に答えたら、「アップボート」をクリックしてください。これはこのスレッドを読んでいる他のコミュニティメンバーにとって有益かもしれません。

Harshavardhan Sriramulaさん

回答ありがとうございます。

１．Databricks からの操作は具体的に ダウンロード（GetBlob）、アップロード（PutBlob）、コピー（CopyBlob）どれですか？

⇒Databrics側からBlobを取り込みたいため、ダウンロード（GetBlob）となると思われます。

２．対象は 一般の Blob（階層なし） ですか？ それとも ADLS Gen2（hierarchical namespace） を使っていますか？

⇒一般の Blob（階層なし） です。

３．Storage アカウントの 診断設定（Diagnostic settings） は有効化済みですか？

⇒先ほど有効化しました。（カテゴリ：Storage Read、Write、Dalete）

４．現在参照できるログは Storage Analytics（classic） ですか？ それとも Log Analytics（StorageBlobLogs） ですか？

⇒**Log Analytics（StorageBlobLogs）**と思われます。

５．Databricks 側のエラーメッセージ（例：403 系で request not authorized 等）は何でしょうか？

⇒認証で弾かれているそうですが、詳細は現在確認中となります。

上記を踏まえ、診断設定を有効化したので、もう一度SASトークンを発行して、Databricsからアクセス可能か試し、改めて回答いたします。

引き続きよろしくお願いいたします。

Harshavardhan Sriramulaさん

Storage アカウントの診断設定を有効化し、SASトークンを再払い出しし、Databricsからアクセス可能か試したところ、

Databrics側には以下のようなログが出力されました。

・azure_invalid_credentials_configuration)] Azure key provider or credentials are configured incorrectly. Reason: Failure to initialize configuration for storage account zzzstorage.dfs.core.windows.net: Invalid configuration value detected for fs.azure.account.key. SQLSTATE: 42KDK

・File <command>, line 73 70 print(f"[INFO] 読み込み完了: {raw_count:,} 件") 72 except Exception as e: ---> 73 raise RuntimeError( 74 f"Azure Blob 接続・読み込み失敗: {e}\n" 75 "確認事項:\n" 76 " 1. Unity Catalog に Storage Credential / External Location が正しく定義されているか\n" 77 " 2. 実行ユーザー（またはワークスペース）に External Location への READ 権限が付与されているか\n" 78 " 3. NCC Stable Egress IP が Azure Blob の IP フィルタで許可されているか" 79 ) 81 if raw_count == 0: 82 raise ValueError("読み込み件数が 0 件です。パス・設定を確認してください。")

またストレージアカウントのログ（発行したクエリ：StorageBlobLogs | where TimeGenerated > ago(1d) ）を確認したところ、

Databricsからアクセスした時間帯のログは特に何も出力されていませんでした。

認証で弾かれているため、ログに出力されていないのでしょうか？

よろしくお願いいたします。

こんにちは @Anonymous 、

追加の情報とテスト結果を提供してくれてありがとう。

共有してくれたエラーメッセージに基づくと、この動作はリクエストが認証確認のために Azure Blob Storage に到達していないことを示しているようです。

主なエラーは以下の通りです：

azure_invalid_credentials_configuration

fs.azure.account.key に無効な構成値が検出されました

このエラーは通常、Databricks 側で認証情報の初期化中に発生し、Databricks がストレージアカウントにリクエストを送信する前に無効または誤って構成されたストレージ認証情報を使用している可能性があることを示しています。

さらに、あなたは以下のことを述べていました：

• 対象は標準の Blob Storage アカウントです。
• 診断設定が有効になっており、ログは StorageBlobLogs に収集されています。
• テスト実行中に StorageBlobLogs に該当するエントリは確認されませんでした。

もしリクエストがストレージアカウントに到達していた場合、通常は失敗したリクエストを含むリクエスト記録が見られるはずです（ StorageBlobLogsでの例（例えば、403の認証や認可の失敗）などです。 テスト中に関連するレコードが生成されなかったため、この失敗は、リクエストがAzure Storageに送信される前のDatabricksの認証または資格情報設定段階で発生している可能性がさらに示唆されます。 この段階では、Databricks側で以下の項目を確認することをお勧めします：

• SASトークンがDatabricksの設定内で正しく参照されていることを確認する。
• Storage Account Keyベースの設定（fs.azure.account.key）が残っていないか、SASベースの認証方法より優先されていないことを確認する。
• Unity Catalogを使用している場合は、Storage CredentialおよびExternal Locationの設定を確認する。
• StorageBlobLogsを監視しながら再テストし、リクエストがStorage Accountに届き始めるかどうか確認する。

さらに絞り込むために、以下を共有していただけますか：

DatabricksからBlob Storageにアクセスする際に使用している方法（例えば、SAS など）トークンの設定、ABFSパス、マウントされたストレージ、Unity Catalogの外部ロケーションなど。 Databricksで使用されている完全な認証設定（機密情報は伏せた状態で）。 ストレージアカウントにアクセスする際に、blob.core.windows.netエンドポイントを使っているのか、dfs.core.windows.netエンドポイントを使っているのか。 上記の情報があれば、問題がDatabricksの認証設定に関連しているのか、それともAzureストレージの認証に関連しているのかを判断するのに役立ちます。 結果を教えてもらえれば、引き続き一緒に調査できますので、よろしくお願いします。

Hello @dla-d ,

Hope you're doing well.

Can you please update us on the latest response.

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

If these answer your question, click "Upvote" which may be beneficial to other community members reading this thread.