Sentry Logs 一般提供開始（ログはログ…でもついに実用化）

私たちが Sentry に Logs 機能を構築し始めたとき、目標は一つでした。それは、単なる大量のテキストストレージではなく、実際のデバッグに役立つものにすることです。そのために、初日から「トレースと接続」させることにしました。

これにより、アプリケーション内で発生するアクションやパフォーマンスとログを密接に結びつけ、開発者がエラーやパフォーマンス、レイテンシの問題を調査するまさにその場所で活用できるようにしたのです。

現在、Logs はベータ版を終了し、すべてのユーザーに一般公開されました。さらに嬉しいことに、ベータ期間中に皆さんから要望のあった数多くの機能を追加しています。

• ライブテーリング（Live Tailing）：ログをリアルタイムにストリーミングし、修正の確認、長時間実行されるジョブの監視、または問題が発生した瞬間の特定に利用できます。
• アラート（Alerts）：特定のログパターン（例: 繰り返される payment_status=declined）に基づいてトリガーし、ユーザーが報告する前に失敗を把握できます。
• ダッシュボード（Dashboards）：ログの傾向を時系列で可視化します。たとえば Safari でのエラーレートの上昇や、新しい機能フラグに関連する突然のスパイクを確認できます。

チェックアウトの失敗、不安定なジョブ、ページロードの遅延。どんなデバッグであっても、Logs は重要なコンテキストを提供します。そして、それらの Logs が他のテレメトリー（トレース、エラー、リプレイ）と結びつけば、根本原因をより早く突き止めることができます。タブの切り替えも、タイムスタンプの計算も不要。ただ答えがあるだけです。

ここからは、Logs がどのようにして面倒な問題のデバッグを簡単にするのか、その実例をご紹介します。あるいは、今すぐドキュメントを参照してログ送信を始めて頂いても構いません。

何も壊れていないように見えても、裏で起きていることがわかる

トレースと接続されたログは、見過ごされがちなサイレントな失敗を見つける

フロントエンドは checkout.request を送信し、バックエンドは 200 を返し、問題は記録されません。例外も投げられません。

しかし、ユーザーは注文確認を受け取っていないと報告してきます。

Sentry でトレースを開くと、checkout.request のスパンは正常に見えますし、処理は成功しています。しかし、本来その後に続くはずの非同期処理 order.processed のスパンがありません。

checkout.request のスパンをクリックすると、そのスパンにスコープされたログが表示されます。

つまり、そのジョブはキューに入れられていました。次に注文処理サービスのログに切り替え、job_id=ff38cd でフィルタリングします。結果はありません。ですが、近くのログが目に留まります。

Fast-checkout フローがステップを一つ飛ばしていました。クラッシュもなく、エラーもなし。ただ設定が抜けていて、ジョブが落ちただけです。しかし、ログがトレースに結びつき、さらにスパンにスコープされているため、すぐにそれに気づくことができました。

ジョブの実行（あるいは失敗）をリアルタイムで監視

あなたの毎晩の請求書同期は、ここ数週間ずっと不安定でした。修正を加えた今夜、それがうまくいったかどうかを、明日ではなく今夜のうちに知りたいと思っています。

ログを service=invoice-sync でフィルタし、Live Tail を有効にして監視します。

UI のリグレッションが雪だるま式に膨らむ前に検知

ダッシュボードでパターンを把握し、次回はアラートで検知

新しい商品カルーセルをフィーチャーフラグの裏でリリースしました。テストではすべて問題なく見えたのですが、翌日には、「Safari でページが読み込めない」というバグ報告が少しずつ届き始めます。

エラーは投げられず、Issue もトリガーされませんでした。しかし、ユーザーは明らかに問題に直面しています。

ログを確認し、ダッシュボードを作成します。

• feature_flag=product-carousel-v2 でフィルタ
• user_agent と level でグループ化

すると、Safari で level=ERROR のスパイクが際立って見えます。

さらにログを掘り下げると、次のようなメッセージが繰り返し表示されます。

新しい UI は Safari の環境には存在しないフォント API に依存していました。クラッシュはしなかったものの、ページは一度もレンダリングされませんでした。

そこでフラグをロールバックし、ポリフィルを追加してから、ログベースのアラートを設定します。

トリガー条件: feature_flag=product-carousel-v2 かつ メッセージに “render failed” を含む場合

次回からは、何かおかしいというバグ報告を待つことなく対応できます。

これまでの反響は？

私たちがどれだけ Logs が便利か話し続けることもできますが、すでにユーザーの皆さんが代わりにうまく表現してくれています。

　「Log → trace → reply in @getsentry は本当に魔法みたい。ログがついにサポートされたのは嬉しい」

@GKedzierski on X

「Sentry は神。特にいまログが追加されたことで」

@ananayarora on X

ベータ版の時点から、開発者は毎日テラバイト規模のログを Sentry に送り込んでいます。すでに 5,000 以上のチームが利用しており、中にはサーバーに SSH して生ログを grep するのを完全にやめてしまったところもあります。

Logs の始め方

すべての Sentry ユーザーは毎月 5GB のログを無料で利用できます。追加分は 1GB あたり 50 セント。

セットアップはほんの数分。Logs は Python、JavaScript、Go、Ruby、PHP、.NET、Java、モバイルに対応しています

JavaScript の例は以下のとおりです。

SDK を初期化する際に、enableLogs オプションを true に設定します。

その後、logger API を使ってカスタム属性付きの構造化ログを送信できます。