Крестовое оборудование JVM

Question

Крестовое оборудование JVM

1

Я провожу время с DynaTrace. Я впечатлен своей особенностью, связанной с кросс-jvm-инструментами. Простыми словами, DynaTrace способен обрабатывать Java-код, создавая трассировку с некоторой статистической информацией. Это ничего нового. Есть очень интересная функция: при вызове внешнего JVM DynaTrace может связать эту новую трассировку с вызывающим (например, удаленный сеансовый компонент, веб-службы, удаленный RMI и т.д.). Как это возможно? Я не могу представить, как реализовать эту функцию? Есть идеи?

спасибо

Alex 22 дек. 2014, в 11:18

Источник

Теги:

java

bytecode

instrumentation

dynatrace

2 ответа

Ещё вопросы

Andreas Grabner · Answer 1 · 2015-02-11T12-39-00.000Z

Dynatrace фактически не полагается на информацию из bean-компонентов. Как вы правильно сказали в своих вопросах - мы используем инструмент байтового кода, например, другие инструменты на рынке. Мы используем ключевые методы для определенных фреймворков, например: Servlet, Axis, JMS, JDBC,... В сценарии, в котором вы выполняете вызов от одной JVM к другой, используя, например: HTTP-связь, мы используем как отправную сторону HTTP Запрос, а также принимающая сторона на другой JVM. На отправляющей стороне мы присоединяем дополнительный HTTP-заголовок с идентификатором текущего PurePath. PurePath - наша патентная технология. Таким образом, каждый PurePath (= каждая транзакция) получает уникальный идентификатор. Этот идентификатор "отправляется" с запросом, например: мы помещаем его в HTTP-запрос в качестве HTTP-шейдера. На принимающей стороне - ваша вторая JVM - мы проверяем этот HTTP-HEADer и поэтому знаем, что все данные, которые мы собираем, принадлежат этому PurePath. Это позволяет нам вести реальную сквозную трассировку, не полагаясь на такие вещи, как Beans, или не сопоставляя эти данные, например: timestamps

Имеет смысл? Если у вас есть дополнительные вопросы, дайте мне знать. Я также записал несколько видеороликов и поместил на YouTube, чтобы объяснить технологию и сам продукт: http://bit.ly/dttutorials

Привет, Андреас, спасибо за ответ. Вы используете HTTP-запрос в качестве примера, но я полагаю, что механизм между JVM работает также для RMI, веб-сервисов и любых других технологий удаленного вызова. Я думаю, что вы не измените mothid подпись в случае вызова RMI / EJB, так как вы перенесете свой идентификатор на удаленную JVM?
Верный. Мы не изменяем сигнатуры методов. Мы нашли другие способы передачи этого «идентификатора PurePath» от вызывающего к вызываемому. Это верно для RMI, JMS, Thread Pooling, ... Я не могу поделиться всеми техническими деталями, как мы реализуем это для различных протоколов - но - просто попробуйте и вы увидите, что это работает без каких-либо изменений. Это ничего не нарушает, если вы используете только одну сторону. Все хорошо проверено и работает в масштабных системах наших пользователей. Попробуйте. Я запускаю 30-дневную бесплатную пробную программу: bit.ly/dttrial
Привет, Андреас, еще раз спасибо за ответ. Я понимаю, что вы не можете поделиться технической реализацией коммерческого продукта. Но это информация, которую я ищу, хотя бы в качестве общего описания.
Как и в случае с HTTP, мы нашли способы «добавить» наш PurePath ID в протокол, не нарушая ни одного из компонентов, участвующих в этом обмене данными. С HTTP мы используем заголовок HTTP. Для RMI подход немного другой. к сожалению, я не могу рассказать вам точные детали так, как мне бы хотелось. Для JMS или MSMQ мы используем свойства сообщения. То же самое верно для WCF.
@AndreasGrabner - Я понимаю, что PurePath запатентован как есть, со всеми подробностями реализации, но как насчет идеи инструментария кода для соответствия HTTP-коммуникации через дополнительный HTTP-заголовок? Должно ли это также рассматриваться как запатентованное? Я хотел бы сделать такой инструмент с подобным подходом и не уверен, где ваш патент "заканчивается" ...
Я полагаю, что нет патента на использование настраиваемого заголовка HTTP для каждого запроса тега и трассировки. Вы должны быть спасены, чтобы двигаться вперед с таким подходом

Rafael Winterhalter · Answer 2 · 2014-12-23T05-14-00.000Z

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