Классическая настройка RHQ предполагает присутствие агента и плагинов агента на машине («платформа» в RHQ-говорить). Затем плагины связываются с управляемым ресурсом (например, сервером AS7); запросите значения метрик или запустите операции (например, «перезагрузка»). В этой статье показан альтернативный способ мониторинга приложений на примере приложения Ticket Monster из JBoss Developer Framework . 
Протокол связи между плагином и управляемым ресурсом зависит от возможностей этого ресурса. Если ресурс представляет собой процесс Java, часто используется JMX. В случае JBoss AS 7 мы используем протокол DMR через http. За
другие виды ресурсов, это также может быть доступ к файлам или jdbc в случае баз данных. Следующая картинка показывает эту настройку.
Плагин агента общается с управляемым ресурсом и извлекает из него метрики. Агент собирает метрики из нескольких ресурсов и затем отправляет их в виде пакетов на сервер RHQ, где они хранятся, обрабатываются для оповещения и могут быть просмотрены в пользовательском интерфейсе или получены через CLI и REST-api.
простирающийся
Вышеуказанный сценарий, конечно, не ограничивается инфраструктурой и может также использоваться для мониторинга приложений, которые находятся внутри, например, AS7. Вы можете написать плагин, который использует базовое соединение для общения с ресурсом и сбора оттуда статистики (если вы используете плагин jmx или as7, вам не обязательно писать java-код). Это также означает, что вам нужно добавить в ваше приложение хуки, которые экспортируют метрики и делают их доступными в модели управления (MBean-Server в классическом jre; модель DMR в AS7), чтобы плагин мог их получить.
Пушинг из приложения
Еще один способ мониторинга данных приложения — передача данных приложением напрямую на RHQ-сервер. В этом случае вам все еще нужно иметь дескриптор плагина для определения метаданных на сервере RHQ (какие существуют ресурсы и метрики, какие единицы имеют метрики и т. Д.). В этом случае вам нужно только определить дескриптор и не писать код Java для плагина. Это работает путем наследования от плагина No-op . В дополнение к этому, вы также можете просто развернуть этот дескриптор как плагин без jar . Следующий рисунок показывает установку:
В этом сценарии у вас все еще может быть агент с плагинами на платформе, но это не обязательно (но рекомендуется для базового мониторинга инфраструктуры). На стороне сервера мы развернем дескриптор плагина ticket-monster . Приложение TicketMonster было дополнено для отправки каждого бронирования на сервер RHQ в виде двух показателей общего количества проданных билетов и общей цены бронирования ( BookingService .createBooking ()).
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
|
@Statelesspublic class BookingService extends BaseEntityService<Booking> { @Inject private RhqClient rhqClient; public Response createBooking(BookingRequest bookingRequest) { […] // Persist the booking, including cascaded relationships booking.setPerformance(performance); booking.setCancellationCode("abc"); getEntityManager().persist(booking); newBookingEvent.fire(booking); rhqClient.reportBooking(booking); return Response.ok().entity(booking) .type(MediaType.APPLICATION_JSON_TYPE).build(); |
Это происходит через соединение HTTP с REST-api сервера RHQ, которое определено внутри одноэлементного компонента RhqClient . В этом компоненте RhqClient мы читаем файл rhq.properties при запуске, чтобы определить, должны ли вообще быть какие-либо отчеты и как получить доступ к серверу. Если отчетность включена, мы пытаемся найти платформу, на которой мы работаем, и если сервер RHQ не знает об этом, создайте ее. Поверх платформы мы создаем экземпляр TicketMonster. Это безопасно делать несколько раз, как и при создании платформы — я ищу существующую платформу, где агент, возможно, уже может отслеживать основные данные, такие как использование процессора или использование диска. Отчет о показателях выглядит следующим образом:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
|
@Asynchronous public void reportBooking(Booking booking) { if (reportTo && initialized) { List<Metric> metrics = new ArrayList<Metric>(2); Metric m = new Metric("tickets", System.currentTimeMillis(), (double) booking.getTickets().size()); metrics.add(m); m = new Metric("price", System.currentTimeMillis(), (double) booking.getTotalTicketPrice()); metrics.add(m); sendMetrics(metrics, ticketMonsterServerId); } } |
По сути, мы создаем два объекта Metric и затем отправляем их на RHQ-сервер. Второй параметр — это идентификатор ресурса сервера TicketMonster на RHQ-сервере, который мы получили из запроса на создание, о котором я упоминал выше. Отличие от классической установки, в которой объекты MeasurementData внутри RHQ всегда имеют так называемый идентификатор расписания, заключается в том, что в вышеприведенном случае мы передаем имя метрики в том виде, как оно есть в дескрипторе развертывания, и позволяем серверу RHQ отсортировать идентификатор расписания.
|
1
2
3
4
|
<metric property="tickets" dataType="measurement" displayType="summary" description="Total number tickets sold"/> <metric property="price" displayType="summary" description="Total selling price"/> |
И вуаля вот как выглядят продажи, созданные из бота внутри TicketMonster:
Бронирование в RHQ-UI
Интервал отображения был установлен на «последние 12 минут». Если вы видите полосу, это означает, что в течение интервала времени 12 минут / 60 слотов = 12 секунд было несколько заказов. В этом случае столбец показывает максимальное и минимальное значение, а маленькая точка внутри показывает среднее значение (через Rest-Api все еще можно увидеть отдельные значения за последние 7 дней).
Зачем мне это делать?
Вопрос здесь, конечно, почему я хочу отправлять свои бизнес-метрики на сервер RHQ, который обычно используется для мониторинга инфраструктуры? Потому что мы можем! Серьезно, такие бизнес-показатели также могут указывать на проблемы. Если, например, количество бронирований необычно велико или мало, это также может быть источником беспокойства и требует предупреждения. Возьмите пример электронных магазинов, которые продают электронику и где это случилось, когда кто-то сделал опечатку и предложил ноутбуки, которые обычно продаются по 1300 евро, а сейчас продаются по 130 евро. Эти новости быстро распространяются через социальные сети, и продажи в три раза превышают их обычные цифры. Здесь может помочь мониторинг количества проданных ноутбуков. Другая причина заключается в том, что RHQ с его пользовательской концепцией позволяет настраивать специальных пользователей, которые имеют (только для чтения) доступ к ресурсам TicketMonster, но не к другим ресурсам внутри RHQ. Таким образом, бизнес-люди могут получить доступ к метрикам, отслеживая продажи билетов.
Слева вы видите дерево ресурсов под snert платформы со всеми ресурсами, как, например, пользователь rhqadmin. Справа вы видите дерево как пользователь, имеющий право видеть только сервер TicketMonster (™).
Todos
Вышесказанное является подтверждением концепции, чтобы начать это. Осталось еще кое-что сделать:
- Создавайте суб-ресурсы для выступлений и сообщайте о бронировании отдельно
- Регулярно сообщать о доступности сервера TicketMonster
- Лучше отделить внутренний код, который все еще живет в классе
RhqClient - Включите вышеперечисленное в TicketMonster Propper — в настоящее время он находится в моем личном репозитории на github.
- Решите, как лучше обрабатывать сервер RHQ, который временно недоступен
- Get Forge для автоматического создания кода отправки метрики /…, когда для класса или поля есть специальная аннотация для этой цели. То же самое для создания новых предметов, таких как спектакли в корпусе ™.
Если вы хотите попробовать это, вам нужна текущая копия мастера RHQ — в предстоящем выпуске RHQ 4.6 будут внесены некоторые необходимые изменения на стороне RHQ. В бета-версии RHQ 4.6 их еще нет.
Ссылка: Мониторинг монстра с помощью RHQ от нашего партнера по JCG Хейко Руппа в блоге Некоторые вещи, чтобы запомнить