Как подойти к опросу клиентов JMX

Question

Недавно я попал в мир JMX, пытаясь измерить наши приложения и выставлять некоторые операции через пользовательский JMXClient. Уже начата работа по определению того, как обрабатывать классы, не изменяя многое из нашего существующего кода. Я выполнил это с помощью реализации DynamicMBean. В частности, я создал набор аннотаций, которые мы украшаем нашими классами. Затем, когда объекты создаются (или инициализируются, если они используются как статические классы), мы регистрируем их с помощью нашего MBeanServer через статический класс, который создает динамический класс для класса и регистрирует его. Это прекрасно работает, когда мы просто используем JConsole или VisualVM. Мы можем выполнять операции и просматривать состояние полей, как мы должны быть в состоянии. Мой вопрос больше ориентирован на создание полу-реального времени JMXClient, такого как JConsole.

Самая большая проблема, с которой я столкнулся, заключается в том, как заставить JMXClient сообщать состояние полей как можно ближе к реальному времени, как я могу разумно получить, без необходимости модифицировать инструментальные библиотеки для push-уведомлений (например, в сеттере метод некоторого класса, установите поле, затем отпустите уведомление JMX). Мы хотим, чтобы классы были почти полностью не осведомлены о том, что они используются. Если вы проверяете JConsole при проверке атрибута, в нижней части экрана есть кнопка обновления, которая обновляет значения атрибута. Значение, которое он отображает для вас, - это значение, полученное при загрузке этого атрибута в представление, и никогда не будет изменяться без использования кнопки обновления. Я хочу, чтобы это произошло само по себе.

Я написал небольшой пользовательский интерфейс, который показывает некоторые данные о состояниях соединения и несколько полей на некоторых инструментальных классах. Чтобы эти значения отражали текущее состояние, у меня есть Thread, который вращается в фоновом режиме. Каждые две или около того поток пытается получить текущие значения интересующих меня полей, тогда пользовательский интерфейс обновляется в результате. Мне не очень нравится это решение, так как его сложно написать логику, которая обновляет основные модели. И даже сложнее обновить интерфейс так, чтобы не вызвать странные ошибки (используя Swing).

Я также мог бы написать дополнительный раздел JMXAgent на стороне нашего приложения, с единственным потоком, который проходит через список зарегистрированных DynamicMBeans, определяет, изменились ли значения их атрибутов, а затем выталкивает уведомление (с). Это приведет к перемещению логики уведомления из инструментальных библиотек, но все равно добавит больше нагрузки на приложения :(

Мне просто интересно, был ли кто-либо из вас в этом положении с JMX или чем-то еще, и может вести меня в правильном направлении для методологии проектирования для JMXClient или действительно любой другой совет, который мог бы сделать это решение более элегантным, чем я.

Любые предложения вы, ребята будут оценены.

Answer 1

Если вы не хотите менять сущности, тогда вам придется их опросить. Либо ваш JMXAgent, либо клиент JMX должен будет запрашивать фасоль так часто. У вас нет возможности обойти этот удар производительности, хотя, так как вы называете кучу попаданий, я не думаю, что это будет очень дорого. Конечно, ваш JMXAgent был бы лучше, чем клиентский опрос JMX все время. Но если клиент все равно проверяет все бобы, тогда стоимость может быть одинаковой.

Вам не нужно было бы делать опрос, если бы объекты могли вызвать агента, чтобы сказать, что они были изменены, или если они поддерживают какой-то метод isDirty().

В наших системах у нас есть система показателей, в которой используются различные компоненты. Каждый из классов увеличивал свою метрику, и это были метрики, которые были связаны с персистом. Вы можете запросить значения показателей с помощью JMX или перенести их на диск или провод. Используя тип Metric, тогда существовало разделение между сущностью, которая выполняла подсчет, и сущностями, которые нуждались в доступе ко всем значениям метрики.

Переходя к зарегистрированной модели типа объекта Metric, ваш GUI может затем запросить MetricRegistrar для всех показателей и отобразить их через JMX, HTML или что угодно. Таким образом, ваши объекты будут просто делать metric.increment() или metric.set(...), и GUI будет запрашивать метрику всякий раз, когда это необходимо.

Надеюсь, что-то здесь поможет.

Answer 2

а не решение, но вы можете упростить реализацию JMXAgent-транслятора для трансляции событий, используя весеннюю интеграцию. У этого есть что-то, называемое JMX Attribute Polling Channel, которое, похоже, выполняет y нашей потребности. example here

Answer 3

Быть эффективным здесь означает оставаться внутри сервера mbean, который содержит бобы, на которые вы смотрите. Вы хотите, чтобы конвертировать mbeans, которые не знают, как выдавать уведомления в mbeans, которые do.

Для просмотра цифровых и строковых атрибутов вы можете использовать стандартные mbeans в пакете монитора. Создайте эти в сервере mbean, который содержит бобы, которые вы действительно хотите посмотреть, а затем соответствующим образом установите свойства. Вы можете сделать это без добавления кода в цель, потому что пакет монитора является стандартным для JVM. Мониторы будут наблюдать за объектами, которые вы выбрали для изменений, и будут излучать уведомления об изменениях только в том случае, если будут наблюдаться фактические изменения. Используйте setGranularityPeriod, чтобы сообщить компонентам монитора, как часто смотреть на цель.

После того как мониторы на месте, просто зарегистрируйтесь для MonitorNotifications, которые будут созданы после изменения.