Tracer в 2026 году: мы стали observability-платформой

Привет, Хабр! Это Кирилл Попов, руководитель команды проекта Tracer, и Маргарита Скокова, инженер мобильных приложений Android в Одноклассниках. Ещё год назад мы называли Tracer комплексной платформой для сбора и анализа ошибок мобильных и веб-приложений. О том, как всё начиналось и развивалось, можно прочитать в статьях 2023, 2024, 2025 годов и в январской новости. В 2026 году Tracer стал observability-платформой.

В этой статье мы расскажем, что нового в Tracer вы можете использовать для разбора проблем на релизе, сбоев у пользователей и упрощения рутины. Эти инструменты открываются по запросу — будем рады пригласить вас на ранний доступ, чтобы вы попробовали новые функции раньше официального релиза.

Решаем задачу «Ничего не работает» 

Представим сценарий: поддержка приходит с жалобой от пользователя: «Приложение не грузит, невозможно пользоваться». Информации меньше некуда, время бежит, алерты молчат, а недовольство пользователя растёт. Приступаем к разбору проблемы. 

Дано: атрибуты сессии и пользователя и название ошибки. 

Решение: используем имеющиеся данные и объединённые в Tracer инструменты для выяснения настоящей причины сбоя.

Tracer становится вашей доской расследования — как у настоящих детективов, только вместо лупы и улик — трейсы, логи и OTLP-спаны.

В Tracer уже готова инфраструктура для сбора, хранения и анализа телеметрии. Логовница — агрегатор логов — хранит передаваемые по протоколу OTLP данные. Логи можно просматривать прямо в интерфейсе, искать, фильтровать и смотреть на графиках.

На странице телеметрии для поиска трейсов используем TQL — собственный язык запросов для фильтрации и выборки сбоев и логов в Tracer. Заходим в найденный трейс — и перед нами открывается арсенал инструментов:

• просмотр автоматически прикреплённых к трейсу логов, поиск по их содержимому

• просмотр времени выполнения спанов и их атрибутов

• поиск по спанам с ошибками и предупреждениями

• подсветка спанов с ошибками, переход на страницу привязанной ошибки

• автоматическое превращение спана в метрики, что позволяет сразу видеть агрегированную картину производительности без дополнительной настройки

• переход к спану из сбоя по прикреплённой ссылке

Для продвинутых детективов пригодятся такие инструменты:

• Двусторонняя связь ошибки и сессии: можно воспроизвести реальный контекст пользователя, переходя из ошибки в сессии и из сессии — во все ошибки в ней

• «Хлебные крошки»: в логах последнего запуска виден путь пользователя Android-приложения от момента старта приложения до возникновения ошибки 

• Локальные переменные в Python: можно лучше понять контекст возникновения ошибок — все значения переменных и строки кода в момент ошибки видны прямо в стектрейсе

• Легковесные стектрейсы: с Native SDK можно снять стектрейс только одного потока без остановки всего процесса 

• Кастомные ANR: с reportThread можно отправить статус и стектрейс нужного потока на Android 

Теперь нам остаётся сделать несколько шагов:

1. Фильтруем поиск TQL по ID пользователя и названию ошибки

2. Анализируем проблему по трейсу и логам

3. В телеметрии ищем трейсы с OTLP-спанами по содержимому лога со страницы сбоя

4. В дереве спанов найденного трейса видим спан, помеченный ошибкой 

Результат: спан, привязанный к запросу, а именно его долгое выполнение и вероятное зависание, и является причиной исходной проблемы. Вся цепочка расследования укладывается в несколько кликов. Больше никаких переключений между окнами и ручного копирования ID.

Источник проблемы — долгое выполнение запроса и его завершение ошибкой, но из-за чего она возникает, ещё предстоит выяснить.

Волшебный способ помирить клиент и бэкенд

С новой уликой в виде проблемного запроса продолжим расследование: проведём первичную диагностику на клиенте, посмотрим графики, протестируем вручную. На первый взгляд всё чисто. Идём к команде бэкенда и отдаём им задачу, спокойно работаем. Пока они не перекинут задачу обратно на нас. 

Такое в реальности больше не произойдёт, потому что Tracer объединил клиентскую и серверную ошибки. Командам клиентской и бэкенд-разработки не придётся спорить о том, где проблема, — они смотрят на один трейс и решают общую задачу.

Клиентский SDK связывает всё, что происходило на устройстве. К сессии прикрепляется флаг sampled, который уходит с OTLP, — и мобильное приложение с бэкендом видят один сквозной трейс. В одном представлении мы получаем визуализацию выполнения запроса с клиентскими спанами, вызовами бэкенда и сбоями. Это позволяет быстрее определить, на чьей стороне проблема. На чьей же она стороне?

Береги релиз снову, а алерты смолоду

Новый релиз выкатили, дежурный проверяет графики и замечает новый всплеск краша на платформе — именно того, который мы расследуем. Куда смотреть и что делать, пока поддержка не пришла с пачкой жалоб от пользователей? Tracer отвечает на эти вопросы и даёт инструкцию, как действовать.

Следим за последней версией

С анализом ошибок на релизе Tracer тоже поможет — сам определит, какая версия сейчас раскатывается. В поиске не нужно вспоминать и сверять версию, функция latestVersion() сделает это за вас: фильтры и алерты сами привязываются к актуальному релизу по активности пользователей.

Настраиваем алерты

В 2026 году алерты в Tracer стали более гибкими и точными:

• Всплеск и регресс: Tracer оповестит о росте числа неновых событий и о повторном появлении ранее исправленных ошибок

• Не только триггеры из коробки: есть настройка порогов триггера по пользователям и процентам аудитории для crash и ANR

• Отключение алертов до определённой даты на время работ или миграций

• Дублирование алертов для ускорения копирования похожих настроек

• Подписка на метрики: алерты на критические отклонения метрик телеметрии, не только на ошибки

• Осмысленные сообщения: в текст алерта подставляются компонент краша, customData, счётчики — и в мессенджер приходит внятное информативное сообщение

• SKIP_ALREADY_FIRED для регресса: алерт не отправится повторно по той же ошибке

• Вебхук-каналы уведомлений: отправка алертов в любую систему через вебхук и редактирование каналов

• Бот от Tracer продублирует уведомления в MAX и VK Мессенджер 

Помимо алертов, важно следить и за общим состоянием платформы — качество релиза видно по зависаниям. Для этого мы сделали аналог crash-free — график ANR-free, который показывает долю сессий без ANR.

Следим за историей сбоя

Не только поиск стал удобнее — представление самих сбоев теперь интуитивно понятно: ответственного за сбой можно назначить прямо из Tracer, а для удобства фильтрации — указать кастомные теги и срок их действия. Для отслеживания работы над сбоем можно оставлять комментарии и просматривать историю действий с ним. Не придётся искать по истории коммитов, задач и чатов в трёх разных сервисах — всё собрано в одной карточке сбоя.

Группируем трейсы и сбои

В работе с самими стектрейсами также появились новые возможности, которые позволят не тратить время на разбор одинаковых ошибок: можно группировать ошибки по кастомным правилам и объединять их по смыслу. В общем списке будет видна динамика каждой группы сбоя без открытия её страницы.

Некоторые сбои, напротив, могут объединяться по техническому сходству стектрейса, но по сути иметь разные сообщения, смысл и причину возникновения. Для работы с такими событиями Tracer сделал разделение по сообщению: на странице сбоя в настройках нужно найти «Разделение» и ввести тег правила разделения. По тегу можно найти все события, которые теперь автоматически будут добавлены в разные группы.

Рутину отдаём агенту

В июне 2026 Tracer выпустил MCP Server и apptracer-cli, которые помогут в работе со сбоями и телеметрией. ИИ-агент возьмёт на себя рутинные операции по мониторингу релизов и разбору ошибок.

Ассистенту можно задать вопрос, например «В чём причина роста ANR с версии 3.13.22?», а ИИ-агент получит доступ по личному токену, запросит логи, данные сбоя, трейсы и сформирует отчёт.

Ещё одно применение ИИ и MCP — анализ релизов на наличие новых проблем или критичных всплесков, требующих быстрого реагирования. Они найдут то, что может пропустить человек. Мониторинг релизов резко упрощается до пары фраз с ИИ-ассистентом.

Это не все кейсы применения MCP, на сегодняшний день агент может:

• получать информацию об организации и её приложениях

• читать распределённые трейсы, фильтровать их, получать детали трейса

• работать с вариантами крашей, их деталями и трендами

• точнее строить поисковые выражения с новой моделью TQL в последней версии

Агент находится на равном с вами положении: с последней версии — MCP 0.5.0 — он видит всё, что видно в UI. Доступен Remote MCP — hosted-режим для внешних пользователей apptracer, который позволяет подключаться по HTTP с помощью личного токена. А значит, локально скачивать и устанавливать MCP-сервер не нужно.

Подключить MCP можно к разным клиентам по соответствующим конфигурациям. В процессе подключения есть возможность выбрать фичи, которые будут необходимы при работе: сбои, логи, трейсы (apptracer-mcp-server --features reports,logs). Это позволяет экономить контекст на то, что важнее для решаемой задачи.

После подключения мы можем направить агента на расследование, например попросить его разобрать проблему пользователя.

Агент проанализирует запрос и вызовет необходимые инструменты, чтобы найти краш и локализовать проблему: сначала определит организацию и приложение с apptracer_list_orgs, apptracer_list_apps, а после получит информацию уже по ошибке apptracer_get_crash_list, apptracer_get_crash_details. Агент по трейсу и логам определит проблему, проанализирует, на чьей стороне причина, сравнит с ошибками в группе и на устройствах.

Убедимся в том, что нашёл агент, проанализировав и трейсы. Просим найти OTLP-спаны с соответствующей ошибкой: агент вызовет apptracer_get_trace_details, найдёт ошибку и предоставит расширенный отчёт, учитывая контекст всего диалога.

Проблема подтвердилась — ошибка вызвана необработанным исключением при неправильном ответе сервера. Попросим агента составить план защиты от падения на клиенте и создать отчёт о проблеме в файле, чтобы отдать бэкенду для исправления.

Разбор инцидента: меньше ручного переноса

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

• Публичная ссылка на лог, спан или стектрейс открывается в браузере без доступа к Tracer

• Для внешнего анализа можно сгружать логи в CSV

• Задачу в Jira можно создать со страницы ошибки. Вручную заполнять почти ничего не нужно: стектрейс и ключи уже в шаблоне. Расширенная интеграция с заполнением полей из customData открывается по запросу

• Кастомные семплы и вложения загружаются отдельно, получают UUID и привязываются и к крашу, и к трейсу — по сессии и времени. Отправить можно сразу, не дожидаясь конца сессии

Поделиться логом с настройкой приватности:

Как подключиться?

Для миграции из Sentry не нужно переписывать код: копируем DSN из настроек проекта Tracer, вставляем в init Sentry SDK — события идут в Tracer, код не меняется. Breadcrumbs попадают в раздел «Логи», Extra — в Context, а трейсы Sentry SDK появляются в «Телеметрии». Для .NET-команд мы сделали привычное отображение ошибок, для Perl, Ruby и Python добавили правила фильтрации стектрейсов. Для ошибок без стектрейса учитывается fingerprint из Sentry.

Если начинаете с нуля, выбирайте SDK на apptracer.ru: Android, iOS, JavaScript, Java, Native (C/C++), Python и Go. В 2026 добавились PHP и серверный Node.js. Трейсы и логи принимаются по OTLP: слать их можно стандартным коллектором, без привязки к вендору.

Архитектура хранилища представляет из себя мультитенант, развёрнуто оно на ClickHouse, данные лежат в РФ.

Что дальше?

Мы продолжаем развивать Tracer, в ближайшем будущем планируем:

• добавить карту для поиска узких мест на основе трассировок

• обеспечить долгожданную поддержку Flutter

• собрать метаприложение, чтобы можно было выйти за рамки одного проекта в Tracer и удобно работать с тем набором сервисов, который вам нужен, в одном окне

О том, что из этого получится, расскажем в следующих публикациях.