Комментарии 9
Можете, пожалуйста, подробнее описать как групировали схожие stacktrace? Это вручную делалось, или есть какая-то эвристика помимо регулярок?
Насколько меньше багов стало долетать до прода, в процентах, за более или менее продолжительное время?
Можете, пожалуйста, подробнее описать как групировали схожие stacktrace? Это вручную делалось, или есть какая-то эвристика помимо регулярок?
Практически все стек трейсы, которые мы обрабатываем выброшены java сервисами. Как следствие — имеют похожий формат.
Алгоритм обработки примерно такой:
- Все полученные стек трейсы разбиваем построчно.
- В каждой строке находим токен содержащий java package и унифицируем его формат. То есть из java.lang.NullPointerException получается j.l.NullPointerException.
- Далее для каждой строки применяем регулярки, чтобы избавиться от номеров строк и прочего шума.
- Стек трейсы сравниваем построчно на первые N строк.
Регулярки созданы вручную и их необходимо поддерживать, впрочем не слишком часто.
Подход мягко говоря не идеален, но работает.
Тем временем мы работаем над новым сервисом, который будет обрабатывать вообще все стек трейсы с продакшн системы и анализировать их, используя различные подходы.
Думаю по результатам появится еще одна статья, так что следите за обновлениями в нашем блоге )
Насколько меньше багов стало долетать до прода, в процентах, за более или менее продолжительное время?
Если говорить об ошибках, которые отслеживает наш сервис, то за последние полгода статистика такая:
- половина всех исправленных багов найдена на интеграционных окружениях
- но 60% созданных там багов не связанны с функциональностью и закрываются без модификации кода
То есть шума все же достаточно много, но возможность исправить ошибку раньше того стоит.
Далее для каждой строки применяем регулярки, чтобы избавиться от номеров строк и прочего шума.
Стек трейсы сравниваем построчно на первые N строк.
Я так понимаю номера строк выкидываются из-за разных версий сервисов. А если логи раскидать по версиям софта, тогда одинаковые stacktrace будут одинаковы полностью, что может сделать систему сбора еще более продуктивной, как мне кажется
Кроме того, мы не хотим создавать баги отдельно для каждого релиза, в идеале — один раз создали и далее периодически обновляем и приоритезируем. Если баг воспроизводится чаще — поднимаем приоритет, если реже — понижаем. Несколько месяцев не воспроизводился — закрываем тикет с соответствующим статусом. Все полностью автоматически.
Мы для отслеживания ошибок используем Sentry. При первом подключении было много ошибок и влетало это в копеечку, но все ошибки поправили за пару месяцев и мы переключились на бесплатный плат. Сейчас редко выходим за лимиты бесплатного плана. 2 года в бою, полет нормальный.
Конфиденциальные данные мы в Sentry не отправляем, поэтому с этим проблем нет. Но разработать свой аналог это конечно круто. Вы молодцы.
Некоторые из них вызваны особенностями продакшн системы — в ней очень много разных сервисов. Чтобы безопасно использовать облачную версию Sentry нужно убедиться, что все сервисы вычищают пользовательские данные, и часть из них поправить. Даже для того, чтобы просто посылать логи в Sentry тоже требуется небольшая разработка.
А self-hosted версия по функциональности очень сильно уступает платной облачной.
Ну и в целом есть разница в подходе. Наша цель — предоставить командам разработки приоретизированный список актуальных проблем. Неактуальные автоматически закрываются, те что воспроизводятся редко получают низкий приоритет. Если ошибка воспроизводится — информация в баге обновляется. Исправленные баги не переоткрываются, пока на про не выкатится соответствующая версия.
Для каждой баги мы дополнительно собираем различную информацию по нашей системе, чтобы им не нужно было самим проводить расследование.
- Логи запроса с каждого сервиса, который его обрабатывал
- Маршрут запроса внутри системы
- Версия каждого сервиса из цепочки обработки
- Клиентские приложения, в которых воспроизвелась ошибка
- Пользователи, у которых ошибка воспроизводится
- Изменения, происходящие в системе в момент появления ошибки
В итоге получается более удобный и адаптированный под нужды разработки сервис.
Даже для того, чтобы просто посылать логи в Sentry тоже требуется небольшая разработка.
У нас Symfony и для нее есть готовый бандл, так что у нас с подключение Sentry вообще никаких проблем. Так же есть интеграция GitLab <=> Sentry. И нам вполне хватает стектрейса собранного Sentry для идентификации и исправления проблемы. Но в вашем случае конечно все гораздо сложнее с учетом вашей архитектуры и вам нужно значительно больше данных чем может собрать Sentry. Тут я не спорю.
Я лишь хочу сказать, что Sentry очень хорошо подходит для не очень больших проектов. Так сказать, инструмент для старта.
Для тех же, кто не готов изобретать очередной велосипед, но со своим рулем и педалями, имеются готовые коммерческие решения уже встроенные в систему сбора логов.
Я не работал с Elastic, но имею большой опыт работы например со Splunk в котором имеется поддержка чего только душе твоей угодно и ему не нужны никакие доп. костыли в виде поисковых сервисов как Sentry. Максимально гибко настраиваемые отчеты по логам, дашборды для мониторинга, алерты с рассылкой по почте, созданием тикетов в Jira, даже смску тебе пошлет если захочешь…
Последний рубеж обороны QA: автоматическое обнаружение ошибок