Фронтенд выдаёт 500. Stack trace указывает на React-компонент. Реальная проблема в трёх сервисах отсюда, в пуле соединений с базой данных, исчерпанном утекающей фоновой джобой.

Вы могли бы кликать через waterfall трейсов, коррелировать таймстампы и читать историю коммитов. Или вы могли бы передать это Seer от Sentry — агенту отладки на базе LLM, который читает ваши трейсы, ошибки и код, а затем говорит, что сломалось.

Seer хорош в этом. Он не ясновидящий. Промежуток между этими двумя утверждениями — о чём этот пост.

Что на самом деле означает statistical debugging

Statistical debugging использует паттерны из множества выполнений для точного определения багов. Традиционные дебаггеры показывают вам один прогон. Статистические подходы смотрят на распределения: какие функции падают вместе, какие трейсы коррелируют с ошибками, какие коммиты предшествовали всплеску крашей.

Sentry делал статистическую часть годами. Seer добавляет LLM для рассуждения о причинности поверх этих данных. Он не заменяет статистику. Он её интерпретирует.

Seer не галлюцинирует root causes из ничего. Он смотрит на те же трейсы и stack traces, на которые смотрели бы вы, но читает тысячи спанов за секунды и коррелирует их с вашим codebase.

Как Seer читает trace, не тонув в спанах

Распределённый trace может содержать тысячи спанов. Закидывание их всех в контекстное окно LLM — рецепт путаницы. Модель зацикливается на нерелевантных деталях и пропускает сигнал.

Sentry решает это, строя сжатое дерево trace. Вместо каждого спана Seer видит иерархию транзакций — service boundaries, группирующие спаны в осмысленные единицы. Дерево показывает, какие транзакции вызывали какие, сколько времени они заняли и были ли ошибки внутри них.

Вот как концептуально выглядит 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 получает это дерево, аннотированное таймингом и статусом ошибки. Он видит, что запрос checkout вызвал три downstream-сервиса. Он не видит каждый отдельный database query, если только не запросит их.

Ключевое слово — «если только». У Seer есть инструменты. Если дерево подсказывает, что проблема в платёжном сервисе, он может запросить полные спаны внутри этой транзакции, связанные события ошибок по ID или CPU-профили. Он решает, на что смотреть дальше.

Этот агентный подход — разница между «вставь этот trace в ChatGPT» и тем, что Seer делает на самом деле. Чат-бот получает один шанс. Seer получает цикл: наблюдай, рассуждай, запрашивай больше данных, рассуждай снова.

Межсервисная проблема, для решения которой был создан Seer

До трейсов Seer (тогда называвшийся Autofix) полагался на stack traces и breadcrumbs. Это работало для монолитов. Это провалилось для распределённых систем.

Возьмём ошибку 500 на фронтенде. Stack trace указывает на вызов fetch. Без трейсов Seer заключил бы, что сломался фронтенд. С трейсами он видит, что фронтенд вызвал API gateway, который вызвал auth-сервис, который бросил ошибку валидации токена, потому что сертификат ротировался.

Собственная команда Sentry столкнулась с этим внутри. Проблема аутентификации между бэкендом Sentry и микросервисом Seer сохранялась днями. Seer, получив дерево trace и доступ к обоим репозиториям, идентифицировал root cause и открыл pull requests в обоих сервисах.

Это и есть обещание. Подвох — в настройке.

Что нужно Seer, прежде чем он сможет вам помочь

Seer нужно три вещи для хорошей работы:

1. Связанные трейсы.

Если ваши сервисы используют разные проекты Sentry без distributed tracing, Seer видит изолированные ошибки, а не дерево trace. Вам нужен Sentry SDK в каждом сервисе и propagation заголовков trace.

На 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
)

Для межсервисного propagation SDK читает и пишет заголовки sentry-trace и baggage автоматически на поддерживаемых HTTP-клиентах. Если вы используете свой собственный клиент, прикрепляйте заголовки вручную:

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 никогда не формируется.

2. Связанный код.

Seer ищет по вашему codebase, чтобы коррелировать трейсы с реализацией. Это требует интеграции с GitHub и маппинга репозиториев на проекты Sentry. Seer не может прочитать ваш код из zip-файла или локального пути.

3. Достаточно сигнала.

Trace только с автоинструментированными HTTP-спанами говорит Seer, что сервис A вызвал сервис B. Он не говорит Seer, какая бизнес-логика происходила между ними. Кастомные спаны имеют значение.

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%-й rate идентификации root cause. Это означает, что примерно одна из двадцати проблем получает неверный диагноз. Для инцидентов высокой степени тяжести вам всё равно нужен человек, чтобы проверить вывод Seer, прежде чем деплоить фикс.

Это стоит денег за каждый запуск.

Запуски Seer стоят примерно $1 за каждый root cause analysis плюс ежемесячная подписка. Автоматизированные сканы дешевле — $0.003 за проблему. Для команды, обрабатывающей десятки проблем ежедневно, это накапливается. Настраивайте пороги автоматизации внимательно.

Он не может исправить то, что не может видеть.

Если ваши трейсы сэмплируются на 1%, а баг проявляется только в оставшихся 99%, Seer не найдёт его. Если root cause находится в стороннем сервисе, который не шлёт трейсы в Sentry, Seer упрётся в стену. Если проблема — логический баг, который никогда не бросает ошибку, Seer никогда не активируется.

LLM всё ещё плохо справляются с некоторыми видами рассуждений.

Исследование Microsoft подтвердило то, что подозревают большинство разработчиков: AI-агенты превосходно локализуют проблемы, но испытывают трудности с root cause analysis, когда причина далека от симптома. Причинность во времени, особенно с race conditions или повреждением состояния, остаётся сложной.

Когда Seer блестит и когда его стоит пропустить

Seer стоит попробовать, когда:

  • У вас распределённая система со связанными трейсами через несколько сервисов
  • Проблема включает чёткое событие ошибки, которое Sentry захватил
  • Root cause, вероятно, в вашем собственном коде, а не в сторонней зависимости
  • У вас достаточный объём трейсов, чтобы ручное расследование было утомительным

Пропустите, когда:

  • Ваши трейсы не связаны между сервисами
  • Проблема прерывистая и редко захватывается в трейсах
  • Вам нужно разрешение менее минуты для активного инцидента (Seer работает минутами)
  • Root cause почти наверняка — инфраструктура, а не код

Как на самом деле попробовать

Если вы уже на платном плане Sentry, Seer доступен как 14-дневный trial.

  1. Подключите GitHub в настройках организации Sentry
  2. Смапьте ваши репозитории на ваши проекты Sentry в настройках Seer
  3. Убедитесь, что tracing включён в ваших SDK с установленным traces_sample_rate
  4. Откройте любую проблему и нажмите Find Root Cause

Для автоматизированных запусков настройте точку остановки. Большинство команд начинают с Stop after Root Cause. Как только вы доверяете точности, вы можете позволить ему предлагать решения или черновить pull requests.

Если вы используете Cursor или Claude Code, вы можете вызывать Seer через MCP-сервер Sentry прямо в чате вашей IDE.

Честный итог

Seer может находить root causes в трейсах, строя сжатые деревья trace, запрашивая детальные данные по требованию и рассуждая через ваш codebase. Для связанных, хорошо инструментированных распределённых систем он действительно полезен. Собственные инженеры Sentry сэкономили дни времени отладки на межсервисных проблемах.

Он не замена пониманию собственной системы. Это очень быстрый, очень начитанный стажёр, который может читать трейсы и код, но всё ещё иногда винит не тот сервис. Используйте его для ускорения расследования, а не для его устранения.

Если ваши трейсы чистые, связанные и полные полезных спанов, Seer, вероятно, впечатлит вас. Если нет — сначала почините трейсы. Ни один LLM не может отлаживать то, что вы не удосужились инструментировать.

FAQ

Работает ли Seer с self-hosted Sentry? Нет. Seer — это облачный сервис, требующий sentry.io. Он полагается на собственную инфраструктуру Sentry для запуска LLM-агента и доступа к вашей телеметрии. Self-hosted инстансы не имеют доступа к Seer.

Может ли Seer анализировать трейсы из языков, отличных от Python и JavaScript? Да. Seer читает данные trace из Sentry, а не raw языкоспецифическую телеметрию. Любой сервис, инструментированный Sentry SDK, который производит трейсы, может питать Seer. Шаг анализа кода требует интеграции с GitHub, которая работает с любым языком.

Что происходит, если Seer ошибается в root cause? Вы можете дать обратную связь во время анализа, и Seer учтёт её. Финальный выход всегда требует человеческого одобрения, прежде чем какие-либо изменения кода будут применены или PR открыты. Ничего не деплоится автоматически, если вы явно не настроите это.

Чем это отличается от простой вставки stack trace в Claude или ChatGPT? Чат-бот получает одно контекстное окно с тем, что вы вставили. Seer получает агентный цикл с доступом к вашему полному дереву trace, связанным ошибкам, CPU-профилям и codebase. Он может запрашивать больше данных по мере рассуждения и знает структуру вашей системы, потому что читает реальный код.