Spring Boot. Настройка профилирования времени выполнения

[svp7093]

Решение полезное, но есть одно "но". "Работает - не трогай" и AOP в жаве - это немножко несовместимые вещи. Вы, фактически, скрыто навешиваете кучу прокси-классов на уже работающий код. И вот эта орава классов может легко что-нибудь сломать и/или замедлить. Если уж вы всё равно пересобираете код и надо промониторить одну функцию - так и вставьте туда таймер. По крайней мере будете уверены, что ничего больше в байт-коде не изменилось.

[GekIn]

Про навешивание прокси - согласен. Смысл как раз был в том, что пересобирать код придется один раз - во время добавления стартера с конфигурацией, а включать\выключать функционал прокси и выбирать какой кусок кода мониторить можно уже без релизов и пересборки

[evseevvd]

Так есть же micro benchmarks https://www.baeldung.com/java-microbenchmark-harness для спринга. В чем смысл своего велосипеда?

[GekIn]

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

[evseevvd]

с помощью конфиг файлов это не на лету это минимум рестарт пода/контейнера/сервиса, мерить benchmark как раз имеет смысл до того как придет баг с прода что все медленно. если уж и подрубать на лету то это MBean(JMX)

[GekIn]

Да, согласен, не совсем "на лету", но всё же сильно быстрее и удобнее чем через код и релиз (во всяком случае в разрезе той задачи, что передо мной стояла). Спасибо, посмотрю в сторону JMX

[zKey]

Костыль. Есть много более подходящих решений этой задачи.

[GekIn]

Возможно, буду благодарен, если поделитесь

[yeap]

Я бы еще предложить результаты профилирования вынести в метрики(prometheus), чтобы удобно находить медленные участки кода, настроить алертинг и построить графики.

Метрики времени выполнения + счетчики 

`{package=“ru.alfastrah.profilingdemo.service”,class=“SomeService”, method=“doSomething”}`

[GekIn]

Согласен, удобная была бы доработка, но на тот момент это бы сильно вышло за пределы необходимого по задаче, т.к. суть была просто в обнаружении проблемного места, а не в каком-то перманентном мониторинге. В целом, если говорить о постоянном мониторинге, то у нас настроен prometheus|grafana по эндпойнтам сервиса, и этого хватает, чтобы реагировать на инциденты

[LeshaRB]

А почему не сделать через аннотации? Это ведь удобнее, чем прописывать пути в настройках

[GekIn]

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

[centralhardware2]

Тогда уж можно и в zookeeper их вынести