256bitのミステリ世界

いとおかし！Databricksでできる、OpenTelemetryの可視化！

お疲れ様です、桑野です！ いとおかし？ざっくり言うと「いとおかし＝めちゃくちゃ趣深い」という清少納言ワードで、…

akuwano
18〜27分

お疲れ様です、桑野です！

いとおかし？ざっくり言うと「いとおかし＝めちゃくちゃ趣深い」という清少納言ワードで、最近DatabricksにZerobus Ingest OpenTelemetry（以下Zerobus OTEL）というやつがBetaで出てきまして、これがまあ「ほう、これはいとおかし、、、」となる代物だったので、今日はその話を書きます（なにそれ

感覚的に「あ、Zerobus OTEL、これみんなほしいやつだな」と思ったのです。ほんとです。

で、Zerobus Ingest OTELとは？

ざっくり一言で言うと:

OpenTelemetryで送ってるテレメトリを、Databricksのテーブルにそのまま直送りできるエンドポイント

です。

ポイントは3つとなっています！

  • コード変更不要 — OpenTelemetry Collector（後述）の送信先URLと認証ヘッダーを変更するだけ
  • サーバーレス — クラスタもKafkaもいらない、自動スケール、インフラ管理ゼロ
  • Unity Catalog管理 — ガバナンス・アクセス制御はDatabricksのいつものやつです（PIIマスキングや属性ベースのアクセス制御も可能です）

特に1つ目「コード変更不要」がかなりいい感じなのです。後で実体験のところでも書きましょう。

で、OpenTelemetryってのが、なんで流行ってるの？

知ってる人は読み飛ばしてOKですｗシュッといきますｗ

OpenTelemetry（OTel） は、CNCF（Cloud Native Computing Foundation）が管理している（していた？）、システム監視データの共通規格 です。要するに「メトリクス（数値計測）」「ログ（イベント記録）」「トレース（処理経路追跡）」みたいな監視データを どこのバックエンドにでも同じ形で送れるようにしようぜ という活動ともいえるのだろうか？です。

なんで流行ってるかも3行で書いていくと、

  • どこに送るかを後から差し替えやすいので、移行や併用がしやすい
  • AWS / Azure / GCPもみんな受け側を公式に用意してる
  • 各言語のSDKやAgent（OpenTelemetry Collector、FluentBit、Telegraf等）が揃っていて、導入のハードルがめちゃ低い

つまり「監視データのデータポータビリティ規格」と理解してもらえれば概ねOKです！

蛇足ですが、データを”運ぶ”こと自体がコモディティ化したことで、価値の重心が“運んだあと、何に使うか”にシフトしてるなー、と思っています。それもあとで書きましょう！

既存の取り込みアプローチって、けっこう面倒ね

「テレメトリを長期保存したい・分析にも使いたい」ってなった時、これまで取れる選択肢はだいたいこんな感じでした:

  1. 既存サービスから定期的にエクスポート — 保存期間制限、Egress課金、運用コストもかかりそう
  2. アプリからObject Storageにデュアルライト — 別途バッチジョブ運用、出力管理が地味に辛い
  3. Kafka / メッセージキュー経由でLakehouseに流す — クラスタの運用、専門知識、大規模ならアリ、だけど運用負荷高め

どれも「まあできるけど、誰かがインフラを面倒みないといけない」 という共通の辛みがあります。俗に言う見えないコストってやつも結構あるわけです。

Zerobus OTELでやると、思ったよりシュッとできた

自分が業務で使ってるClaude Codeの利用ログをDatabricksに流す手順を以前まとめたんですが、その時にこのZerobus OTELを使ったわけです。やってみると思ったよりシュッとできました。

  • Unity Catalog側で テーブルを作る
  • Claude Codeの設定ファイルで 送信先URLと各種設定をDatabricks向けに変える
  • 終わりです（はい

「コード変更ゼロ、設定ファイル数行」で、テレメトリがLakehouseのテーブルに普通にDeltaで入ってくる。Unity Catalogで管理されてるので、誰がアクセスできるかとかPIIマスキングとかも、Unity Catalogの世界で完結する。

これ、地味に「これからのOtel設計の選択肢が変わる」やつだなと触りながら思いました。

Claude Codeのダッシュボードはこちら

Genie Spaceはこちら！便利！

で、Lakehouseに置くと何が嬉しいんだい？

ポイントを整理します！

① コスト構造が変わる

テレメトリで地味に効いてくるのが、長期保存のコスト。LakehouseはObject Storage単価でおいておける（S3にDeltaで置く）ので、「とりあえず溜めとく」が現実的なコストになります 。

長期保存のコスト感は、お安くできます！

② データの所有権やガバナンスが自社側に閉じる

Zerobus OTELの場合、テレメトリは 自社のクラウドアカウントのストレージに、Unity Catalogで管理された形で入る 。データの保管場所も保持期間も、自社側で自由にコントロールできます。

特に「生のプロンプトを外部に送らないでくれ」 という情報セキュリティ要件がある会社にとっては、これは結構大きい話だと思ってます。

③ ビジネスデータとJOINできる

これが個人的に一番好きなやつです。

エラーログ × 顧客レコード、トレース × 売上、APIレイテンシ × 解約率、、、こういう テレメトリとビジネスデータの相関分析、テレメトリがビジネスデータと別の場所にあるとなかなか手が出ません。Lakehouseなら最初から同じUnity Catalogの中なので、 SQL一発でJOIN できます。

「障害で止まりました」だけでなく「結果としてビジネスに$XXXの影響がありました」というレポートが普通に書ける、というのは非常に大事なはず。

④ AI / MLの学習・評価データに使える

テレメトリって実は AIの学習データとしても価値がめちゃくちゃあるんですよね。

  • 異常検知モデルの学習データ
  • MLflowの評価データ
  • AIエージェントのトレースを使った品質評価

テレメトリがLakehouseに溜まっていれば、そのまま学習データとして使える 、というのが地味に強いです。

⑤ SQLとAIで誰でも分析できる

Lakehouseに置けば、AI/BIダッシュボード / Genie（自然言語で問い合わせるデータエージェント） / AI_QUERY（SQLからLLMを呼ぶ） など、Databricksの データ利活用機能を全部そのまま実行可能 。これはシンプルなダッシュボードとは違う体験になります。

4つの使い方

使えそうなユースケースを4つ。

  1. AIコーディングツールの利用監視 — Claude Code / Cursor / Copilotを組織で使ってるけど「誰が何にいくら使ってるか」が見えてない、という場合。Zerobus OTELに流すと、トークン使用量・コスト・ツール呼び出し履歴をそのままDatabricksに集約・管理できる
  2. テレメトリの長期保存とコスト最適化 — いま使ってるツールはそのまま運用して、テレメトリをDatabricksにも流して長期保存する『並走』パターン。長期トレンド分析やキャパシティプランニングはLakehouseで
  3. AIエージェントのトレーシング — MLflow Tracing（OTLP互換、エージェントの内部挙動を追跡する仕組み）でエージェントのプロンプト→ツール呼び出し→応答を全部記録。Observe → Analyze → Evaluate → Improveの改善ループ を回せる
  4. セキュリティ・監査ログの統合 — syslog-ng / FluentBitから監査ログをLakehouseに長期保存、Unity CatalogでPIIマスキング、AI_QUERYで不審パターンを検出。コンプライアンス要件と分析利活用が両立 できる

Databricksを「もう一箇所のテレメトリ保存場所」へ

ここ大事なので強調しますが、 いま使ってるツールをリプレースする話ではないです 。

リアルタイムのアラート検知、設定不要のダッシュボード、運用監視の総合体験、こういうのはいまお使いのツールにそれぞれの強みがあって、引き続き使えばOKです。

個人的に思っているのは:

何かやりたくなったらすぐできるように長期のテレメトリは、Databricksに保存しておこう。

ということです。「いま使ってるツールを全部リプレース！」じゃなくて、「テレメトリのコピーをもう一箇所に置く」だけで、ビジネス側に提供できる価値の幅が変わる 、という話だと思ってます。

まとめ — 春はあけぼの、夏はZerobus（まだいう

雑なまとめなので最後はゆるく行きます。

清少納言が枕草子で「春はあけぼの、、、」って書いたように、季節ごとに “これが趣深いんだよね” というのがあるわけですが、テレメトリ業界における2026年の “いとおかし” は、個人的には DatabricksがOpenTelemetryをネイティブに受け取れるようになったこと だと思ってます。

データを運ぶこと自体（＝OpenTelemetry規格）はもうコモディティ化しました。これからは そのデータをどこに置いて、何に使うか で差がつく。そしてその “どこに置くか” の選択肢として、Databricks Lakehouseを考慮に入れる価値がある時代になった、というのが今日の主張です。

OpenTelemetryでテレメトリを送ってる組織なら、設定変更だけで試せます（コード変更ゼロ、Beta機能）。ぜひ一度、社内で 「テレメトリのコピー、Databricksにも流してみたらおもしろいことできるんじゃない？」 を議題に出してみてください！

ではでは、今日はこのへんで！

参考

コメントを残す

Trending