С первого релиза в августе 2023 года Tracer успел стать востребованным решением. Уже к концу 2024 года в нём было зарегистрировано свыше 1 500 организаций и 5 000 пользователей и ежедневно обрабатывалось более 2,5 млрд запросов. В 2025 году количество зарегистрированных организаций превысило 1 800, а число пользователей достигло отметки в 8 000. Но это не предел, ведь работа над прокачкой инструмента не останавливается. 

Меня зовут Кирилл Попов. Я руководитель команды проекта Tracer, а также UI-разработки и автоматизации в ОК. В этой статье я расскажу об инструменте и обновлениях, которые он получил за последние полгода.

Немного о Tracer

Tracer — инструмент для аналитики ошибок. Он решает три ключевые задачи:

• сбор и анализ ошибок в приложении или сервисе

• сбор и анализ данных о состоянии приложения

• сбор и анализ телеметрии

С помощью Tracer можно собирать данные о падениях и зависаниях приложений, находить утечки памяти в приложении и на диске. Tracer также умеет профилировать приложения в проде для поиска критических мест в производительности. Причём инструмент ориентирован не только на выявление проблем, но и на обнаружение их причин.

Tracer архитектурно разделён на три части: 

• Tracer api-plugin. Компонент, который отвечает за приём различных символов, маппингов и Source Map. Метаинформация собираемых объектов попадает в NewSQL (наш форк Cassandra с поддержкой транзакций), а сами объекты — в S3

• Tracer api-sdk. Компонент, в который поступают ошибки с различных SDK (сейчас есть поддержка Android, iOS, JavaScript, Native, Java). После получения ошибки попадают на шедулер (schedulers), где анализируются и обрабатываются, а затем передаются в Kafka и ClickHouse

• Tracer api-web. Компонент, который принимает запросы от фронтенда Tracer и отдаёт данные из ClickHouse, NewSQL или S3

  

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

Важно несколько аспектов:

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

• Реализация Tracer строится вокруг умного троттлинга и семплинга. Основная цель — дать разработчику максимум информации и объективную картину, не перегружая отчёты лишними данными

• Ошибки агрегируются по crashID. Это хеш, по которому можно распознавать одинаковые ошибки

• Tracer — модульная платформа. Инструмент можно гибко кастомизировать под задачи конкретного проекта

О новых возможностях Tracer

С начала 2025 года команда Tracer уже успешно реализовала большой пул обновлений инструмента.

• Предусмотрели поддержку componentID и environment. Пользователям Tracer важно группировать ошибки произвольным образом. Для этого мы изначально добавили в инструмент поле module. Но анализ его использования показал, что рациональнее выделить два отдельных компонента для более точной идентификации группы ошибок: componentID и environment. Так, componentID позволяет распознавать, к какой конкретно версии конкретного компонента относится ошибка, а environment — к какой среде разработки относится эта ошибка

  

• Улучшили поддержку A/B-экспериментов. В Tracer изначально была возможность сравнивать ошибки в разных версиях и отсматривать различия между ними. Но для корректной работы был нужен один ключ — например, название эксперимента или его ID, что применимо не во всех системах для A/B-экспериментов. Иногда в Tracer передавались просто маркеры, указывающие на принадлежность человека к одной из групп. Поэтому мы доработали эту механику, и сейчас Tracer может сравнивать выборки между разными ключами 

  

• Внедрили поддержка фичи severity. Изначально все ошибки, поступающие в Tracer, делились на две большие группы: crash и non fatal. Но это не позволяло сформировать объективную картину происходящего — например, сразу видеть, что именно скрывается под non fatal: warning или error. Теперь Tracer поддерживает фичу severity, что позволяет ему более чётко классифицировать ошибки по типам

• Улучшили UX-алерты. Теперь в сообщении, которое присылает алерт, можно сразу поставить ссылку на алерт и фильтры. Также из алерта можно сразу перейти к фильтрам

  

  

• Проработали поддержку кастомного crashID в системных ошибках в iOS. В iOS часто возникают ситуации, когда происходит системный сбой, и stack trace состоит только из системных вызовов. В таких случаях сложно определить причину проблемы, так как она может быть связана с конфигурацией или действиями, выполненными ранее в коде. Однако в iOS есть метаинформация, которую предоставляет система. На её основе мы научили Tracer более детально классифицировать системные сбои

Помимо этого:

• Оптимизировали отправку данных в ClickHouse — объём хранения в СУБД уменьшился от 2 до 50 раз без влияния на точность и производительность. Это позволило кратно ускорить обработку запросов

• Реализовали поддержку статических и динамических библиотек в Tracer.Lite iOS 

• Реализовали самодиагностику алертов. Теперь пользователи могут видеть всю историю срабатываний и несрабатываний алертов 

  

• Выкатили релиз в паблик JS SDK, алертов и Tracer под ОС Аврора 

Теперь подробнее разберём результаты, упомянутые здесь — и не только их.

Повышение стабильности Android SDK

Для нас было важно вычистить все ошибки в Android SDK и прийти к состоянию, когда Tracer SDK не провоцирует краши и ANR. Причём надо было сделать это надёжно, чтобы не допускать регрессий, а также выработать универсальный способ, который смогут задействовать и авторы других SDK.

Для этого мы решили применить уже имеющееся у нас решение для мониторинга качества библиотек — Tracer.Lite (о нем мы уже писали здесь). Это стало возможно, поскольку Tracer SDK под Android — тоже библиотека. То есть потенциально можно встроить Tracer.Lite в Tracer. И гипотеза оказалась верной — реализовав подобную схему, мы отловили все краши и 80% ANR и смогли быстро починить их.

Работы на бэкенде Tracer

Бэкенд Tracer мы также доработали. Так, в фокусе команды бэкенда были:

• адаптация Tracer к возрастающей нагрузке

• работа по улучшению производительности

• внедрение интеграции с Grafana on Call

• внедрение новых фич

Остановимся на каждом.

• Адаптация Tracer к возрастающей нагрузке

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

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

• User-Events

С введением распределённой агрегации свою функциональность потеряла одна из фич Tracer — поиск по UserID. 

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

Также благодаря внедрению отдельного сервиса между бэкендом и ClickHouse нам удалось снизить объём очереди более чем в 6 раз. Это ускоряет время отображения событий в Tracer и позволяет быстрее детектить новые события, ошибки и инциденты.

• Environment и Severity

Среди прочего в Tracer есть несколько фич, которые сделают работу разработчиков проще — Environment и Severity.

• Environment — это поле, позволяющее разделять события на окружения. Например, можно помечать тестовые и продовые окружения и создавать алерты только в нужной среде, чтобы видеть, какие ошибки появляются на этапе тестирования

  

• Severity — фича, с помощью которой мы можем не ограничиваться событиями типа crash и non fatal, а использовать больше типов для более точного разделения событий на группы — например, fatal, error, warning, notice, info и debug

  

Развитие JavaScript SDK

Команда Tracer также активно развивает JavaScript SDK.

• Запустили в паблик JS. Уже доступно создание JS-проектов. При этом JS SDK публикуется в npmjs и доступен всем желающим

• Создали JavaScript-версию для библиотек и компонентов. Она отличается от версии для Android, но с её помощью библиотеки и самостоятельные компоненты сами могут отправлять свои ошибки. Ранее этого не было — и приходилось на каждый компонент заводить отдельный проект в Tracer

  

• Добавили поддержку Error.cause. Error.cause добавляет контекст в стектрейс, показывая не только текущую ошибку, но и её первопричину, что улучшает отладку. Внедрённая поддержка даёт возможность JavaScript привязывать исходную ошибку к новой через свойство cause, сохраняя контекст цепочки ошибок

  

• Предусмотрели возможность обработки любых типов данных. Раньше поддержка типов была несколько ограничена, что могло создавать проблемы. Теперь репортить в качестве ошибки можно любые типы данных. При этом даже не обязательно создавать специальный инстанс ошибки — можно отправить то, что получилось. Также в Tracer появилась опция handleOtherErrorDataType для необработанных ошибок

• В UI добавили поддержку разных единиц измерения, а также модуль замера памяти. Помимо этого, к метрикам можно цеплять любые атрибуты

  

• Разработали модуль Async, который позволяет дополнять информацию об ошибках, чтобы было легче находить проблемы. Подробнее об этом можно прочитать в статье ведущего разработчика в команде Tracer Александра Бавина «Решаем фундаментальную проблему асинхронных JavaScript-ошибок»

Чего ждать дальше

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

Но наш приоритет — непрерывное развитие Tracer. Так, наши основные задачи на ближайшую перспективу:

• повышение скорости и стабильности Tracer

• объединение клиентских и серверных ошибок

• интеграция с Jira, Git  

• снижение барьеров для интеграции Tracer в разные проекты и ещё больший пул задач

Как мы будем справляться с поставленными задачами и что ещё привнесём в Tracer, обязательно расскажем — следите за нашими публикациями.