【Log Drains 提供開始】プラットフォームログを直接Sentryへ

02/27/2026

Sentry は Log Drains に対応しました。これにより、アプリケーションコードの変更や手動でのプロジェクトキー検索をすることなく、簡単にログを Sentry へ転送できます。すでに別の場所にログがある場合でも、コード変更なしで、Sentry上でエラーやトレースと並べて確認できるようになりました。

すぐに試したい方は、クイックスタートガイドをご確認ください。

ログを1か所に集約し、Issue のコンテキストと関連付ける

2025年9月に Sentry で Logs を一般提供した際の目的は、ログ、トレース、エラー、リプレイを単一のプラットフォームで確認できるようにすることでした。そしてフィードバックで特に多かったのは、「適切なログが適切な Issue にデフォルトで紐づいていてほしい」という点でした。

「Sentry をアプリに統合したところ、急に「もうひとつ目が増えた」ように感じています。私たちは Logs にも活用していて、デバッグが大幅に楽になりました。Sentry がエラーを報告すると、関連するログがその場ですぐに確認できます。もうひとつ大きな利点は、各ログエントリにユーザー情報が自動でタグ付けされることです。そのため手作業で付ける必要がありません。」

Log Drains を使用することで、プラットフォームのログ（およびトレース）が自動的に Sentry に流れ込み、アプリケーションコード外のプラットフォームレベルのイベントにも「もうひとつの目」が届くようになります。

「例を見せてほしい」と思った方は DevEx チームが Sentry で Vercel ログについて説明する動画をご覧ください。

アプリケーションのエラーやトレースと一緒にプラットフォームのログを一箇所に集約することで、チームはビルド、デプロイ、エッジランタイム、データベース、認証レイヤーにわたるシステムの動作を全体的に把握できます。追加のエージェントを実行したり、アプリケーションコードに触れたりする必要はありません。

ダッシュボードを行き来したり、ログの保持期限が短いせいで大切な情報を失ったりすることなく、エンジニアは Sentry上でエンドツーエンドに問題を調査できます。

今すぐ始める：すべてのプランで5GBのログが含まれています（追加分は1GB$0.50）。

チームはどのように Log Drains を活用しているのか

Sentryを離れることなくVercelデプロイをデバッグする

デプロイ後、ある ECチームは Sentry でクライアント側の失敗が急増していることに気づきました。

Sentry SDKが収集したブラウザーイベントやログ（ui.render_failed や api.fetch_failed など）が、請求ページの route=/settings/billing 周辺に集中しており、特定の地域のSafariユーザーに主に影響しています。

SDKはルート、ユーザーエージェント、地域、リリースがすでに紐づいているため、「誰に」「どこで」起きているかを把握できます。さらに vercel.deployment_id を Sentry のカスタムタグとして追加しているため、この急増は広範囲な問題ではなく、単一のデプロイに対応していることが簡単に確認できます。

そこからチームは Sentry 内の Vercel ログへ切り替え、origin:auto.log_drain.vercel を用いて同じ時間枠で、Log Drain イベントをフィルタリングします。解決された関数パス vercel.path と実際にコードが実行された場所 vercel.execution_region で、ランタイムログをグルーピングすると、明確なホットスポットが見えてきます。/api/billing/subscription へのリクエストが5xxレスポンスを返しており、特定の地域に集中しています。

こうして、エラーが2つの有用な観点から確認できるようになりました。SDKビューでは、スタックトレースやアプリのコンテキストを通して、アプリケーション内部で何がうまくいかなかったのかを示しています。一方、Vercel の Log Drain ビューでは、リクエストID、所要時間、メモリ使用量、stderr の出力などの周辺のランタイム詳細が追加されています。この2つを切り替えることで、エラーだけでなく、本番環境でどのように発生していたかまで理解しやすくなります。

vercel.source:build のビルドログはクリーンで、デプロイ自体の成功を確認できます。次に、Vercel のファイアウォールログ（vercel.source:firewall）を見ると、最後のピースが埋まります。影響が出ている地域で、同じルートに対する deny アクションが、エッジの vercel.proxy.path で急増しています。これらのプラットフォーム側のシグナルによって、一部のリクエストがアプリケーションコードに到達していない理由が説明できます。

まとめると、チームは請求ページが失敗するのは、バックエンドとなるAPIが断続的に失敗したり、特定の地域でブロックされていることが原因であると判断します。今後は、ランタイムの5xxエラーやファイアウォールの deny アクションに関するログベースのアラートをパスや地域ごとにグループ化して追加し、将来のリグレッションを特定のデプロイと影響範囲に即座に結び付けられるようにします。

Supabaseの認証およびデータベースの問題のデバッグ

Supabase を Postgres のために使用しているチームは、アプリケーションサービスに Sentry SDK を利用していましたが、Supabase 内部で発生する問題については可視性が限られていました。データベースエラーは Supabase のダッシュボードでしか確認できず、保存期間も限られていたため、インシデント後の調査が難しい状況でした。

Supabase の Log Drain を有効化することで、チームはアプリケーションコードを変更せずに、Supabase Postgres のログをSentryに転送しました。これにより、データベースのアクティビティがアプリケーションのテレメトリと同じ場所に表示され、次のようなクエリで検索可能になりました。

service:supabase AND message:error

あるケースでは、ログイン失敗の増加が Supabase データベースのログに示されたトークンの有効期限切れに関連するエラー（message:JWTexpired*）と一致しました。これらのログがSentryに保持されていたため、チームは原因がアプリケーションではなくトークン有効期限の設定ミスだと素早く特定できました。不要なコード変更を避け、Supabase側で直接問題を解決しました。

Cloudflare Worker のログを Sentry に取り込む

Cloudflare Workers の背後でAPIを運用するチームは、コアサービスに Sentry SDK を使用していましたが、Worker の挙動は盲点のままでした。リクエストはルーティング、キャッシュ、リクエストサイズなどが原因でリクエストが失敗することがありましたが、Cloudflare Worker のログは Cloudflare のダッシュボードにのみ存在し、インシデントレビュー時には確認できないことも少なくありませんでした。

Cloudflare Log Drain を有効化したところ、エージェントをデプロイしたりアプリケーションコードを変更したりすることなく、Cloudflare WorkerのアプリケーションログをSentryへストリーミングできるようになりました。次のようなクエリでWorkerのエラーを検索できます。

service:cloudflare AND message:error

あるインシデントでは、4xxエラーの急増が単一の地域から繰り返し発生しているリクエストサイズの拒否（message:*request body too large*）を示すWorkerログと対応していました。これらのログが Sentry で可視化されたことで、チームは問題がバックエンド障害ではなく、エッジの構成上の問題であることを特定し、不必要なサービス変更を回避して、Cloudflareで直接問題を修正しました。