Комментарии 13
Решение полезное, но есть одно "но". "Работает - не трогай" и AOP в жаве - это немножко несовместимые вещи. Вы, фактически, скрыто навешиваете кучу прокси-классов на уже работающий код. И вот эта орава классов может легко что-нибудь сломать и/или замедлить. Если уж вы всё равно пересобираете код и надо промониторить одну функцию - так и вставьте туда таймер. По крайней мере будете уверены, что ничего больше в байт-коде не изменилось.
Так есть же micro benchmarks https://www.baeldung.com/java-microbenchmark-harness для спринга. В чем смысл своего велосипеда?
В заметке я уточнил, что хотелось иметь возможность включать\выключать функционал, а также выбирать участки кода для профилирования "на лету" с помощью конфиг файлов, без релизов и пересборки. В варианте по ссылке, насколько вижу, все равно придется навешивать аннотации в самом коде сервиса
с помощью конфиг файлов это не на лету это минимум рестарт пода/контейнера/сервиса, мерить benchmark как раз имеет смысл до того как придет баг с прода что все медленно. если уж и подрубать на лету то это MBean(JMX)
Костыль. Есть много более подходящих решений этой задачи.
Возможно, буду благодарен, если поделитесь
Я бы еще предложить результаты профилирования вынести в метрики(prometheus), чтобы удобно находить медленные участки кода, настроить алертинг и построить графики.
Метрики времени выполнения + счетчики
`{package=“ru.alfastrah.profilingdemo.service”,class=“SomeService”, method=“doSomething”}`
Согласен, удобная была бы доработка, но на тот момент это бы сильно вышло за пределы необходимого по задаче, т.к. суть была просто в обнаружении проблемного места, а не в каком-то перманентном мониторинге. В целом, если говорить о постоянном мониторинге, то у нас настроен prometheus|grafana по эндпойнтам сервиса, и этого хватает, чтобы реагировать на инциденты
А почему не сделать через аннотации? Это ведь удобнее, чем прописывать пути в настройках
Spring Boot. Настройка профилирования времени выполнения