Sentry — интересная альтернатива, мы ее рассматривали, но у нее есть свои недостатки.
Некоторые из них вызваны особенностями продакшн системы — в ней очень много разных сервисов. Чтобы безопасно использовать облачную версию Sentry нужно убедиться, что все сервисы вычищают пользовательские данные, и часть из них поправить. Даже для того, чтобы просто посылать логи в Sentry тоже требуется небольшая разработка.
А self-hosted версия по функциональности очень сильно уступает платной облачной.
Ну и в целом есть разница в подходе. Наша цель — предоставить командам разработки приоретизированный список актуальных проблем. Неактуальные автоматически закрываются, те что воспроизводятся редко получают низкий приоритет. Если ошибка воспроизводится — информация в баге обновляется. Исправленные баги не переоткрываются, пока на про не выкатится соответствующая версия.
Для каждой баги мы дополнительно собираем различную информацию по нашей системе, чтобы им не нужно было самим проводить расследование.
Логи запроса с каждого сервиса, который его обрабатывал
Маршрут запроса внутри системы
Версия каждого сервиса из цепочки обработки
Клиентские приложения, в которых воспроизвелась ошибка
Пользователи, у которых ошибка воспроизводится
Изменения, происходящие в системе в момент появления ошибки
В итоге получается более удобный и адаптированный под нужды разработки сервис.
Согласен с вами, с номерами строк эта логика работает, но на практике вычищать приходится намного больше всего — адреса ссылок, идентификаторы потоков, чисто пользовательские данные. А иногда летят эксепшены от базы данных, завернутые в java.
Кроме того, мы не хотим создавать баги отдельно для каждого релиза, в идеале — один раз создали и далее периодически обновляем и приоритезируем. Если баг воспроизводится чаще — поднимаем приоритет, если реже — понижаем. Несколько месяцев не воспроизводился — закрываем тикет с соответствующим статусом. Все полностью автоматически.
Можете, пожалуйста, подробнее описать как групировали схожие stacktrace? Это вручную делалось, или есть какая-то эвристика помимо регулярок?
Практически все стек трейсы, которые мы обрабатываем выброшены java сервисами. Как следствие — имеют похожий формат.
Алгоритм обработки примерно такой:
Все полученные стек трейсы разбиваем построчно.
В каждой строке находим токен содержащий java package и унифицируем его формат. То есть из java.lang.NullPointerException получается j.l.NullPointerException.
Далее для каждой строки применяем регулярки, чтобы избавиться от номеров строк и прочего шума.
Стек трейсы сравниваем построчно на первые N строк.
Регулярки созданы вручную и их необходимо поддерживать, впрочем не слишком часто.
Подход мягко говоря не идеален, но работает.
Тем временем мы работаем над новым сервисом, который будет обрабатывать вообще все стек трейсы с продакшн системы и анализировать их, используя различные подходы.
Думаю по результатам появится еще одна статья, так что следите за обновлениями в нашем блоге )
Насколько меньше багов стало долетать до прода, в процентах, за более или менее продолжительное время?
Если говорить об ошибках, которые отслеживает наш сервис, то за последние полгода статистика такая:
половина всех исправленных багов найдена на интеграционных окружениях
но 60% созданных там багов не связанны с функциональностью и закрываются без модификации кода
То есть шума все же достаточно много, но возможность исправить ошибку раньше того стоит.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Некоторые из них вызваны особенностями продакшн системы — в ней очень много разных сервисов. Чтобы безопасно использовать облачную версию Sentry нужно убедиться, что все сервисы вычищают пользовательские данные, и часть из них поправить. Даже для того, чтобы просто посылать логи в Sentry тоже требуется небольшая разработка.
А self-hosted версия по функциональности очень сильно уступает платной облачной.
Ну и в целом есть разница в подходе. Наша цель — предоставить командам разработки приоретизированный список актуальных проблем. Неактуальные автоматически закрываются, те что воспроизводятся редко получают низкий приоритет. Если ошибка воспроизводится — информация в баге обновляется. Исправленные баги не переоткрываются, пока на про не выкатится соответствующая версия.
Для каждой баги мы дополнительно собираем различную информацию по нашей системе, чтобы им не нужно было самим проводить расследование.
В итоге получается более удобный и адаптированный под нужды разработки сервис.
Кроме того, мы не хотим создавать баги отдельно для каждого релиза, в идеале — один раз создали и далее периодически обновляем и приоритезируем. Если баг воспроизводится чаще — поднимаем приоритет, если реже — понижаем. Несколько месяцев не воспроизводился — закрываем тикет с соответствующим статусом. Все полностью автоматически.
Практически все стек трейсы, которые мы обрабатываем выброшены java сервисами. Как следствие — имеют похожий формат.
Алгоритм обработки примерно такой:
Регулярки созданы вручную и их необходимо поддерживать, впрочем не слишком часто.
Подход мягко говоря не идеален, но работает.
Тем временем мы работаем над новым сервисом, который будет обрабатывать вообще все стек трейсы с продакшн системы и анализировать их, используя различные подходы.
Думаю по результатам появится еще одна статья, так что следите за обновлениями в нашем блоге )
Если говорить об ошибках, которые отслеживает наш сервис, то за последние полгода статистика такая:
То есть шума все же достаточно много, но возможность исправить ошибку раньше того стоит.