Article by: (読了時間:5分)
changeLOG(変更履歴)の更新が少し滞ってしまったので、まとめてこの bLOG 記事に放り込むことにしました。巨大な、遡及的な changelog エントリだと思ってください。あるいは、もう少し大げさに言うなら、あなたのフィードに送り込まれる一発の巨大な prompt injection だとでも。いずれにせよ、この夏 Sentry Logs にリリースされたものをすべてご紹介します。
チームが何を作ったのか、話を聞いてみたいですか? Kyle と Josh が Logs の最新アップデートについて語っているこちらの動画をご覧ください。
重要なログ行をピン留めする
Sentry に log pinning が追加されました。次に気になるものを見つけたときは、そのログ行をピン留めしておけば、スクロールを続けても、新しいログが流れ込んできても、検索を絞り込んでも、その行はその場に留まります。ピンは URL の状態にも同期されるため、ピン留めしたビューはそのまま共有可能な本物のリンクになります。次にチームメイトへ、自分が見ているものをそのまま見せたいときに役立ちます。

大規模なログのエクスポート
大量のデータをより高速に処理し、エクスポートする内容を細かくカスタマイズできるように logs のエクスポートを刷新しました。
現在、エクスポートは専用のエクスポートダイアログを通じて行われ、行数と形式を事前に選択できます。大規模なエクスポート向けに新しく追加された JSONL オプションも含まれます。その結果、エクスポートは高速になり、サーバーへの負荷も大幅に軽くなりました。「すべてをエクスポートする」が何を意味するのかを推測する必要がなくなったためです。
また、個々のログ行のエクスポートに、テーブルに表示されている内容だけでなく全 attribute データが含まれるようになったため、ログのまとまりを自分のツールに取り込みたい場合により役立ちます。
エクスポートは集計にも対応しました。集計(たとえば、ある attribute でグループ化した count)を表示している状態でエクスポートすると、常に raw の元ログに戻ってしまうのではなく、実際に見ていた内容と一致する集計結果が得られます。
これは logs だけの改善ではありません。同じ基盤のエクスポート機能が、Errors と Tracing でも利用できるようになりました。

検索ワードに一致するすべての箇所がハイライトされるようになりました。以前は行内で最初に一致した箇所だけでした。

Issue 上の logs テーブルにエラーのインスタンスがインラインで表示されるようになりました。2つのビューを照らし合わせることなく、エラーとその周辺のログをまとめて確認できます。

log の詳細パネルで timestamp が常に表示されるようになりました。timestamp カラムがテーブルから外れた dashboard リンク経由で開いた場合でも表示されます。

複数値の検索フィルタが、1つの長いカンマ区切りの値ではなく、個別の chip(個別に削除できるタグ)として表示されるようになりました。以前は message contains abc,def が分かりにくい1つのテキストの塊として表示されていましたが、今は abc と def が別々の chip になります。

ドラッグによるズームがブラウザの履歴を壊さなくなりました。以前はズームごとに3つの履歴エントリが書き込まれ、「戻る」が期待どおりに動きませんでした。今は1回のズームにつき1エントリです。
ログチャート機能の強化
logs チャートにもいくつか UX の改善を加えました。お気づきかもしれませんが、その多くは、実際のログのために画面上のスペースをより多く確保することに関係しています。
- チャートを展開・縮小できるようになりました。右上に統一されたボタンがあります。じっくり見たいときは展開し、ログのためのスペースが欲しいときは元のサイズに戻せます。
- Y-axis の目盛りが、ブラウザのビューポートの高さではなく、チャートの実際の高さに合わせてスケールするようになりました。ウィンドウをリサイズしても、目盛りが2つに減ってしまうことなく、チャートは読みやすいままです。
- チャートのホバー時の tooltip が大幅に安定し、auto-refresh を有効にしていてもすぐに消えることがなくなりました。
- グループ化された系列のカラーパレットを拡張しました。クエリが2つ3つを超えるグループを返したときでも、見ているものを区別しやすくなります。
インタラクティブデモ:オリジナルサイト参照
Sentry で大規模なログデータを扱う
数百ギガバイトから数テラバイトのログを送信している組織にとって、難しい問題はデータの保存ではなく、そのすべての中から特定の1行を見つけ出すこと、いわば干し草の山から針を探すような検索でした。
今四半期は、このスケールを支えるためにフロントエンドとバックエンドの改善に取り組みました。継続処理付きのより長いクエリタイムアウトや、rate limit まわりのより良い処理などにより、本当に大量のログがあっても検索が使いものになり続けます。
これに付随して、いくつかの小さな修正も行いました。
- Logs と Trace Explorer で
release:latestフィルタが正しく動作するようになりました。以前は、保存済みの dashboard ウィジェットなど一部のフローで空の結果が返され、実際には表示すべきものがあるのに何もないように見えていました。 - rate limit エラーが、その内容を明示するようになりました。スループット制限に達した場合、何かが壊れているように見える汎用的なエラーではなく、rate limit がかかっていることを UI が伝えます。さらに再試行ボタンが追加され、ページ全体を再読み込みせずにもう一度試せます。
試してみて、次に見たいものを教えてください!
リリースした機能の一覧はそれほどテンションのあがるものでないことは分かっていますが、ここまで読んでくださった方、ありがとうございます!
もし何かが壊れていたり、足りなかったり、単に煩わしかったりしたら、ぜひ教えてください。アプリ内の製品フィードバックボタンを押すか、logs@sentry.io まで直接ご連絡ください。
Original Page: What’s new in Sentry Logs: The summer 2026 roundup
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談は「お問い合わせ」からお気軽にお問い合わせください。


