SentryのSeerはtraceを読める。だからといつも根本原因を見つけるわけではない

フロントエンドが500エラーを投げる。stack traceはReactコンポーネントを指す。本当の問題は3つ先のサービスにあり、リークしているバックグラウンドジョブによって使い果たされたデータベース接続プールにある。

trace waterfallをクリックして進み、タイムスタンプを相関させ、コミット履歴を読むこともできる。あるいは、SentryのSeerに任せることもできる。trace、エラー、コードを読み込み、何が壊れたかを教えてくれるLLM駆動のデバッグエージェントだ。

Seerはこれが得意だ。千里眼ではない。この2つの言明の間の隔たりが、この記事のテーマだ。

statistical debuggingが実際に何を意味するか

statistical debuggingは、多くの実行にわたるパターンを使用してバグを特定する。従来のデバッガーは1回の実行を示す。statistical approachesは分布を見る：どの関数が一緒に失敗するか、どのtraceがエラーと相関するか、どのコミットがクラッシュの急増の前にあったか。

Sentryは統計的な部分を長年行ってきた。Seerはそのデータの上に因果関係を推論するLLMを追加する。統計を代替するわけではない。それを解釈するのだ。

Seerは無から根本原因を幻覚させない。あなたが見るのと同じtraceとstack traceを見るが、数秒で数千のspanを読み込み、codebaseと相関させる。

Seerがspanに溺れずにtraceを読む方法

distributed traceは数千のspanを含むことがある。それらすべてをLLMのcontext windowに入れることは混乱の元だ。モデルは無関係な詳細にこだわり、信号を見逃す。

Sentryは凝縮されたtrace treeを構築することでこれを解決する。すべてのspanの代わりに、Seerはtransactionの階層を見る。spanを意味のある単位にグループ化するservice boundariesだ。このtreeは、どのtransactionがどの他のtransactionを呼び出したか、どれだけ時間がかかったか、内部でエラーが発生したかを示す。

概念的にraw traceがどのように見えるかを以下に示す。

GET /api/checkout
├── POST /payment-service/process
│   ├── SELECT * FROM orders
│   └── UPDATE inventory
├── GET /user-service/profile
│   └── SELECT * FROM users WHERE id = ?
└── POST /notification-service/email
    └── SMTP send

Seerはタイミングとエラーステータスが注釈付けされたこのtreeを受け取る。チェックアウトリクエストが3つのダウンストリームサービスを呼び出したことを見る。要求しない限り、個々のデータベースクエリはすべて見るわけではない。

重要な言葉は「要求しない限り」だ。Seerにはツールがある。treeが支払いサービスが問題だと示唆すれば、そのtransaction内の完全なspan、IDで関連付けられたエラーイベント、またはCPU profilesを取得できる。次に何を見るかを決定する。

このagentic approachが、「このtraceをChatGPTに貼り付ける」とSeerが実際に行うことの違いだ。チャットボットは1回きりだ。Seerはループを持つ：観察、推論、さらなるデータの取得、再推論。

Seerが解決するために構築されたクロスサービス問題

trace以前、Seer（当時はAutofixと呼ばれていた）はstack tracesとbreadcrumbsに依存していた。これはモノリスには機能した。分散システムには機能しなかった。

フロントエンドの500エラーを考えてみよう。stack traceはfetch呼び出しを指す。traceがなければ、Seerはフロントエンドが壊れたと結論付けるだろう。traceがあれば、フロントエンドがAPIゲートウェイを呼び出し、APIゲートウェイが認証サービスを呼び出し、証明書がローテーションされたためにトークン検証エラーを投げたことを見る。

Sentryの自社チームも内部的にこれに遭遇した。SentryのバックエンドとSeerのマイクロサービスの間の認証問題が数日間続いていた。trace treeと両方のリポジトリーへのアクセスを与えられたSeerは、根本原因を特定し、両方のサービスでpull requestを作成した。

それが約束だ。落とし穴はセットアップにある。

Seerがあなたを助けるために必要なもの

Seerがうまく機能するには3つのものが必要だ。

1. 接続されたtrace

サービスがdistributed tracingのない異なるSentryプロジェクトを使用している場合、Seerはtrace treeではなく孤立したエラーを見る。各サービスにSentry SDKがあり、trace header propagationが必要だ。

Pythonでの例：

import sentry_sdk

sentry_sdk.init(
    dsn="https://your-dsn.ingest.sentry.io/project-id",
    traces_sample_rate=0.1,  # Adjust for your volume
)

クロスサービスの伝搬については、SDKがサポート対象のHTTPクライアント上でsentry-traceとbaggageヘッダーを自動的に読み書きする。独自のクライアントを使用する場合は、手動でヘッダーを添付する：

from sentry_sdk import continue_trace

headers = {}
continue_trace(headers).apply_to_request(headers)
response = my_custom_http_client.get(
    "http:// downstream-service/api",
    headers=headers,
)

これがなければ、Seerはフロントエンドとバックエンドのエラーを無関係なインシデントとして見る。trace treeは形成されない。

2. 接続されたコード

Seerはtraceと実装を相関させるためにcodebaseを検索する。これにはGitHub integrationと、リポジトリーをSentryプロジェクトにマッピングすることが必要だ。Seerはzipファイルやローカルパスからコードを読むことはできない。

3. 十分な信号

auto-instrumentされたHTTP spanだけのtraceは、サービスAがサービスBを呼び出したことをSeerに教える。しかし、その間にどのようなビジネスロジックが発生したかは教えない。custom spansは重要だ。

from sentry_sdk import start_span

def process_payment(order_id):
    with start_span(op="payment.process", description="Validate and charge"):
        validate_order(order_id)
        charge_customer(order_id)

これらがなければ、SeerはHTTPリクエストとデータベースクエリの間にブラックボックスを見る。

誰もマーケティングコピーに載せないトレードオフ

Seerには実際の限界があり、Sentryはそれについてかなり誠実だ。

精度は高いが、100%ではない。

Sentryは94.5%の根本原因特定率を報告している。つまり、おおよそ20件に1件は誤診されるということだ。高深刻度のインシデントについては、修正をデプロイする前に人間がSeerの結論を検証する必要がある。

実行ごとにお金がかかる。

Seerの実行は根本原因分析あたり約1ドルかかり、月額サブスクリプションも必要だ。自動スキャンは1件あたり0.003ドルと安い。毎日数十件の問題を処理するチームにとって、これは積み上がる。自動化の閾値は注意深く設定する必要がある。

見えないものは修正できない。

traceが1%でサンプリングされていて、バグが残りの99%にしか現れない場合、Seerはそれを見つけられない。根本原因がSentryにtraceを送信しないサードパーティサービスにある場合、Seerは壁にぶつかる。問題がエラーを投げない論理的バグである場合、Seerは決して発動しない。

LLMはまだいくつかの種類の推論が苦手だ。

Microsoftの研究は、ほとんどの開発者が疑っていることを確認した：AIエージェントは問題の局在化には長けるが、原因が症状から遠い場合の根本原因分析には苦労する。時間を超えた因果関係、特に競合状態や状態破損においては、依然として難しい。

Seerが輝くときとスキップすべきとき

Seerは以下の場合に試す価値がある。

複数のサービスにわたる接続されたtraceを持つ分散システムである
問題はSentryが捉えた明確なエラーイベントを含む
根本原因はおそらく自分たちのコードにあり、サードパーティの依存関係ではない
traceのボリュームが十分にあり、手動での調査が面倒になっている

以下の場合はスキップすべきだ。

サービス間でtraceが接続されていない
問題が断続的で、traceにめったに捉えられない
アクティブなインシデントに対して1分未満の解決が必要である（Seerの実行には数分かかる）
根本原因はほぼ間違いなくインフラであり、コードではない

実際に試す方法

すでに有料のSentryプランを利用している場合、Seerは14日間のトライアルとして利用できる。

Sentryの組織設定でGitHubを接続する
Seerの設定でリポジトリーをSentryプロジェクトにマッピングする
SDKでtracingが有効になっており、traces_sample_rateが設定されていることを確認する
任意のissueを開き、Find Root Causeをクリックする

自動実行の場合、停止ポイントを設定する。ほとんどのチームはStop after Root Causeから始める。精度を信頼できるようになったら、解決策の提案やpull requestの作成を任せることができる。

CursorやClaude Codeを使用している場合、IDEのチャットからSentryのMCP serverを介して直接Seerを呼び出すことができる。

正直な結論

Seerは凝縮されたtrace treeを構築し、オンデマンドで詳細なデータを取得し、codebase全体で推論することで、trace内の根本原因を見つけることができる。接続された、適切に計測された分散システムにとって、それは本当に役立つ。Sentryの自社エンジニアも、クロスサービスの問題で数日分のデバッグ時間を節約している。

自分のシステムを理解することの代替ではない。traceとコードを読める、非常に速くて非常に博学なインターンであり、時々間違ったサービスのせいにすることもある。調査を加速するために使い、排除するために使うのではない。

traceがクリーンで接続されており、有用なspanで満ちているなら、Seerはおそらく感動させてくれるだろう。そうでなければ、まずtraceを修正する。計測する手間を惜しんだものを、どのLLMもデバッグできない。

FAQ

Seerはself-hosted Sentryで動作するか？

いいえ。Seerはsentry.ioを必要とするクラウドサービスだ。LLMエージェントを実行し、テレメトリにアクセスするためにSentry自身のインフラに依存する。self-hostedインスタンスはSeerにアクセスできない。

SeerはPythonとJavaScript以外の言語のtraceも分析できるか？

はい。SeerはSentryからtrace dataを読み込み、言語固有の生のテレメトリではない。traceを生成するSentry SDKで計測されたサービスならどれでも、Seerに入力できる。コード分析ステップにはGitHub integrationが必要だが、これはどの言語でも機能する。

Seerが根本原因を間違えた場合どうなるか？

分析中にフィードバックを提供でき、Seerはそれを取り入れる。最終出力は、コード変更が適用されたりPRが作成されたりする前に、常に人間の承認が必要だ。明示的に設定しない限り、何も自動的に出荷されない。

これはstack traceをClaudeやChatGPTに貼り付けるだけと何が違うのか？

チャットボットは、貼り付けたものを含む単一のcontext windowを得る。Seerは、完全なtrace tree、関連付けられたエラー、CPU profiles、codebaseにアクセスできるagentic loopを持つ。推論しながらさらにデータを取得でき、実際のコードを読むことでシステムの構造を知っている。