Иногда проблема с приложением выливается в небольшой кошмар, ребус. Назовите, как хотите. Хочу поделиться об опыте использования средств мониторинга разработчиками на одном из проектов. Хабр многолик и уже существуют десятки статей о продуктах, которые облегчают понимание происходящего: cacti — habrahabr.ru/post/179391; zabbix — habrahabr.ru/post/137641; collectd — habrahabr.ru/post/93205; штатные средства JVM — habrahabr.ru/post/147008 (дополняйте).

Попробую рассказать о еще одном небольшом универсальном и легковесном продукте в этой категории — IxoraRMS.
Всем интересующимся, добро пожаловать под кат.

Предистория

Имеем CentOS 6.5, JDK 1.7, JBoss AS 7.1, СУБД ЛИНТЕР и приложение Hibernate/JPA, Seam, RichFaces и странное поведение. Примерно через неделю работы производительность приложения деградирует значительно, веб-интерфейс по своей скорости вызывает нарекания у пользователей и «отдается» разработчикам (в одно место).

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

Можно, конечно, настроить систему сбора статистики и мониторинга Cacti/Munin/Zabbix и т.д., но если делать это хорошо и правильно, то это еще одна задача и в рамках организации это не наша ответственность. Поэтому берем простое, что потребует минимум телодвижений на локальной машине. Отдельные инструменты для Java профилирования и мониторинга есть, но хочется увидеть картинку в целом (ОС, СУБД, сервер приложений, java и само приложение), т.к. источник проблем неуловим. Так как любим Java, то в плане инструмента выбираем IxoraRMS (он на Java! Ура!) (сразу оговорюсь, никакого отношения ни к продукту, ни к его авторам я не имею). Продукт open source, так что поле для доработок открыто. Можно смотреть на www.ixorarms.com, code.google.com/p/ixora-rms, github.com/danielm777/ixora-rms.

Основные моменты почему из Munin, Cacti, collectd выбрали IxoraRMS:

• Легковесность и юзабилити (это простое десктоп приложение Java + Swing, без БД, необходимости глубоких знаний администрирования линукса и процесса сборки из исходного кода)
• Для сбора всех показателей есть агенты и провайдеры, многие готовы к использованию. Во многих случаях получение данных из системы/источника можно просто описать в интерфейсе без строчек кода.
• Примеры мониторинга ОС, СУБД, веб-сервера и JMX из коробки (не без напильника в конкретной конфигурации)
• Много графиков, готовых контрольных панелей.
• Если добавляется/удаляется диск, сервис, компонент EJB или что-то еще, то информация на графиках может меняться динамически, без необходимости перенастройки.
• Запускается одинаково под Linux/Windows (важно, т.к. большинство разработчиков в проекте у нас работают в среде Windows).

Коротко об IxoraRMS

Это java приложение, которое может быть запущено как gui клиент, или как консольное приложение. При этом может использоваться свой агент для запуска и сбора статистики на удаленной машине (нам не хотелось ничего ставить на продакшен сервера) или сбор может осуществляться локально с подключением по сети к удаленной машине (наш случай). Такой вариант может быть полезен также, когда вы приезжаете к заказчику для диагностики проблемы (вашей или чужой).
Что может IxoraRMS:

• Сгруппировать всю информацию по контрольным панелям и экранам.
• Нарисовать графики различных показателей.
• Вывести таблицы и списки с показателями, в том числе с нечисловыми, есть фильтрация.
• Лог записать и проиграть, в том числе состояние всех контрольных панелей и графиков, таблиц, списков во времени.
• Имеет много настроенных агентов для ОС, СУБД, веб серверов и серверов приложений, java(JMX) для сбора показателей и настроенные контрольные панели для них в один клик.
• Все остальные агенты и провайдеры дорабатываются на основе Process, SQL или Java шаблонов через графический интерфейс или руками в XML. При желании можно дописать провайдер на Java
• Исходные показатели с помощью встроенных функций и JavaScript можно обработать.
• Имеет систему настройки оповещений при наступлении какого-либо события (например, нагрузка на процессор больше 80% в течение 3 минут).
• Возможен запуск задач (скриптов) по расписанию или по событиям мониторинга.

Концепция

Для каждого сервера при запуске мониторинга строится дерево сущностей с показателями (аналогия модели JMX), которое содержит хосты, агенты, сущности (entity) и показатели (counter) по узлам. Все это обновляется, по умолчанию, с интервалом в 5 секунд. Схема узлов не жесткая, т.е. узлы могут формироваться динамически (например, на каждый диск, процесс, процессор и др.) в зависимости от текущей конфигурации/ситуации на сервере и настроек мониторинга.

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

Есть начальный набор готовых агентов с провайдерами.



Все остальное можем конструировать с помощью интерфейса или редактированием XML файлов в папке config. Графики, таблицы, списки можно строить, выбрав показатели или определив их список регулярными выражениями. Готовые представления и контрольные панели можно формировать для любого уровня дерева: глобальный для сессии/всех хостов, для текущего хоста, для агента и т.д. вниз по иерархии сущностей. Агент и провайдеры могут опционально предоставлять разный набор сущностей и показателей в зависимости от выставленного уровня детализации мониторинга (maximum, high, medium, low). При необходимости можно написать код провайдера на Java.

После добавления агента у каждой сущности (узла) в дереве могут быть рядом два значка D(ashboard), V(iew), которые означают наличие готовых настроек для просмотра показателей. Этим можно и нужно пользоваться для минимизации усилий. Вот пример, когда вы добавили агент для Linux.



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

И сразу готовая панель с показателями (рисунок после нескольких минут работы и изменения названий панели и окон с представлениями):

Теперь коротко и по шагам

Шаг 1. Скачиваем и запускаем графическую оболочку IxoraRMS

В папке с установленным дистрибутивом запускаем:

       console.bat

Прим.: Есть возможность запуска и останова локального агента (host manager, соответственно hmStart и hmStop) и запуска в пакетном режиме (batchStart, batchStop).

Создаем сессию и добавляем наш хост (на нем CentOS 6.5) в список серверов для мониторинга.

Для нашего хоста из контекстного меню выбираем Add Agents. Можем увидеть какие агенты уже присутствуют в репозитории. Для наших задач нам нужны агенты для CentOS(Linux), Linter, Java(HotSpot или JMX), JBoss 7.1 (JBoss или JMX). Из-за отсутствия разработки с 2011 года, агенты для программных продуктов либо устарели, либо изначально не имели поддержки. Поэтому дальнейшие шаги посвящены настройке приложения под наши требования.

Чтобы иметь возможность в интерфейсе вносить исправления во встроенные агенты и провайдеры, перезапускаем консоль с указанием параметра -Dapplication.dev=true при запуске для java. Правим и запускаем для этого файл console.launch.bat (он перегенерируется при запуске console.bat, будьте внимательны!).

Шаг 2. Мониторим ОС

Для CentOS 6.x подходящий агент существует (Linux), но поддерживаемые версии только RedHat 9 и RedHat AS 3. Если выбрать RedHat 9 и потом запустить мониторинг, то не все графики оживают, в логе IxoraRMS появляются ошибки. Работают провайдеры для агента Linux с использованием утилит iostat, mpstat, vmstat поэтому ставим из репозитория на хост пакеты sysstat и procps.

yum  install  sysstat procps

На примере одного провайдера попробуем разобраться с тем, как они конфигурируются. Для этого:
• открываем меню Tools/Agents Installer
• находим Linux и нажимаем Edit
• в список System versions добавляем «CentOS 6.x»

При показе контрольной панели для RedHat 9 в логе появляются ошибки, связанные с провайдерами File system data и Disk data. Для исправления поступаем следующим образом:
• открываем меню Tools/Provider manager;
• выбираем агент Linux, провайдер Disks data(RedaHat 9, RedHat AS 3)
• создаем на его основе копию с помощью Create Like, указав при этом прежнее имя и другую версию;

• в качестве провайдера в нашем случае используется Process, который перенаправляет стандартный поток вывода от указанной команды на парсер. Поток при этом получается от запуска команды локально или через telnet/ssh с передачей им команды;
• можно выполнить данную команду iostat –d –x 5 на консоли хоста с CentOS, чтобы увидеть формат вывода ({tick} — стандартный параметр с текущим интервалом мониторинга)

• теперь сравним вывод на экран и настройки парсера;
• переключаемся на закладку Parser;

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


• столбцы в выводе iostat, относящиеся к 7 и 8 колонкам вывода «Kilobytes read per second» и «Kilobytes written per second» у нас в CentOS при той же командной строке отсутствуют, поэтому их удаляем;
• на закладке Descriptors хранятся типы показателей и их описание для легенды. В нашем случае строки для удаленных показателей просто исчезнут;
• сохраняем провайдер.

Таким образом, сравнивая вывод используемых утилит с указанными параметрами, приводим провайдеры для CentOS в порядок. Ту же работу можно проделать руками, исправляя файлы:
• config/agents/agents.linux/agent — общее описание агента;
• config/repository/agents.linux/agent.db – контрольные панели на уровне всего агента;
• config/repository/agents.linux/agent.pi – настроенные экземпляры провайдеров;
• config/repository/agents.linux/entity.db – контрольные панели для сущностей;
• config/repository/agents.linux/entity.dv – настроенные представления для сущностей

Эти провайдеры используют telnet/SSH подключение к хосту, по которому удаленно запускается утилита, а весь вывод преобразуется после парсинга в сущности и показатели. Поэтому при добавлении агента приходиться указывать логин и пароль для подключения. Пароль хранится в описании сессии на диске в кодированном виде.

У агента в целом много собираемых показателей от разных утилит и при запуске на хосте висят в нашем случае 5-6 открытых ssh сессий (если через HostManager попробуем, то напишу позже, на разработчики не рекомендуют этот вариант, чтобы агент не вносил большие искажения предварительной обработкой в наблюдаемую систему). Общее потребление ресурсов < 1%.

После корректировки агента и провайдеров удаляем из дерева сущностей агент Linux у хоста и добавляем его заново с выбором версии CentOS 6.x. Запускаем мониторинг и сразу включаем готовую контрольную панель System overview (доступна в дереве у агента). Теперь видим все, что нам было интересно в ОС.

Итоговый файл агента Linux с версией для CentOS 6.x для импорта можно взять здесь (импорт/экспорт у Ixora RMS есть).

Итак ОС мониторим, дальше СУБД.

Шаг 3. Анализируем работу СУБД

Для СУБД ЛИНТЕР агента готового нет. Поэтому в этом случае путь чуть длиннее.

Работу СУБД будем контролировать на основе следующей доступной информации:
• системное представление SYSTEM.$$$CHAN со списком каналов;
• системное представление SYSTEM.SYSINFO с агрегированной информацией по вводу-выводу с момента старта.

Для подключения к БД используем JDBC драйвер из дистрибутива ЛИНТЕР — jdbc/linjdbc-1.4.jar. Его лучше скопировать в папку <Ixora>/lib.

На основе данных таблиц нам доступна следующая информация:
• количество открытых каналов (Connection + Statements);
• максимально возможное количество открытых каналов;
• количество заблокированных каналов;
• количество активных (незакрытых) транзакций по каналам (ядро 6.0.16.x и выше);
• время жизни самой «старой» активной транзакции (сек) (ядро 6.0.16.x и выше);
• общее количество завершенных транзакций;
• общее количество логических записей (в кэш);
• общее количество страниц логического чтения (из кэша);
• общее количество операций физической записи (на диск);
• общее количество операций физического чтения (с диска);
• общее количество операций SELECT.

Предлагается эти показатели разбить на 3 провайдера со следующей моделью данных
Connection data: Connection/[ Opened, Locked, MaxAvailable ]
Transaction data: Transaction/[Total, Active, MaxAge]
Input/Output: Statistics/[ Block logical reads, Block logical writes, Block reads, Block writes, Selects]

Теперь создаем нового агента следующим образом:
• открываем меню Tools/Agents Installer и в диалоге нажимаем кнопку Install;
• далее выбираем Custom agent installation;
• в качестве Agent Template выбираем SQL;
• заполняем свойства агента Linter следующим образом:

• открываем теперь меню Tools/Provider Manager;
• выбираем агент Linter и нажимаем Add для создания провайдера Connection Data;
• выбираем тип провайдера SQL и заполняем соответствующие поля

• в качестве значений полей можно указать специальные переменные {host}, {agent.Username} и т.д., которые определены в сессии или свойствах агента при его добавления к хосту;
• для получения требуемых показателей используем SQL запрос вида:

select * from 
(select count(*) as Opened from $$$CHAN where STATUS<>'') a,
(select count(*) as Locked from $$$CHAN where STATUS<>'' and LOCKED_BY<>0) b,
(select count(*)-1 as MaxAvail from $$$CHAN) c

• на закладке Parser описываем формируемые сущности и показатели на основе значений колонок в выборке;

• на закладке Descriptors описываем типы показателей и их описание

Аналогичным образом добавляем еще 2 провайдера на основе следующих SQL запросов:
1.

select * from 
(select TRANSACTIONS_COUNT as Total from $$$sysinfo) a, 
(select count(*) as Active, NVL(DIVTIME(2, min(TRANSACTION_START), SYSDATE),0) as MaxAge from $$$chan 
 where STATUS<>'' and PARENT_CHANNEL!=0 and TRANSACTION_START > '01.01.1900') b

2.

select READ_BLOCKS, READ_LOGICAL_BLOCKS, WRITE_BLOCKS, WRITE_LOGICAL_BLOCKS,SELECT_COUNT from $$$sysinfo

Теперь можно добавить агент к хосту, заполнив параметры подключения к БД под пользователем SYSTEM.
Для отображения показателей строим контрольную панель из данных провайдеров, используя контекстное меню Add/Use Wizards в разделе Views.

Для больших показателей используем небольшую хитрость: вместо абсолютных значений показываем приращение показателя за интервал мониторинга, тем самым наблюдая за интенсивностью нагрузки. Для этого добавляем описание функции в XML с описанием представления(view), нажав кнопку Edit на готовом представлении.


В IxoraRMS есть встроенные функции для агрегирования и интеграция с JavaScript для произвольных манипуляций (см. подробности здесь www.ixorarms.com/documentation/user-guide/functions)

Для представления(view) также можно задать сигнальные события. Например, для пула каналов в СУБД при использовании его больше 90% в течении 10 секунд можно оповещать администратора.


Настройки для сервера рассылки конфигурируются в общем меню Configuration/Setting.

После несложных манипуляций с построениями представлений через мастер получаем следующую контрольную панель для СУБД.


Для упрощения настройки контрольной панели ее описание вынесено в описание агента путем редактирования XML файлов в папке repository. Теперь для просмотра контрольной панели для любого хоста достаточно подключить агент и активировать готовую панель.


Итоговый агент для СУБД ЛИНТЕР можно взять здесь.

Шаг 4. JVM

По JVM хотелось увидеть: распределение пулов памяти Survivor/Eden/Old/PermGen, затраты на сборку мусора, нити. Для мониторинга JVM от Oracle/Sun есть готовый агент HotSpotJVM, который использует JMX подключение. Для подключения к виртуальной машине с запущенным JBoss AS можно использовать remoting-jmx протокол, который открыт по-умолчанию по порту 9999 и поддерживает авторизацию пользователей, включенных в ManagementRealm.

Чтобы агент HotSpot JVM мог использовать данный протокол необходимо в папку /jars положить файл jboss-client.jar из дистрибутива JBoss As 7.1 и заменить версию файла log4j.jar на версию 1.2.12 и выше (например, в составе дистрибутива JBoss AS 7.1 идет log4j-1.2.16.jar). Описание агента в файле config\agents\agents.hotspotjvm\agent корректируем, добавляем в описание jboss-client.jar.

<?xml version="1.0" encoding="UTF-8"?>
<agent>
 ….
      <jars>
        <jar>/jars/AgentHotspotJVM.jar</jar>
        <jar>/jars/RMSJMX.jar</jar>
        <jar>/lib/javax77.jar</jar>
        <jar>/jars/jboss-client.jar</jar>
      </jars>
….      
</agent>

После изменения описания агента перегружаем IxoraRMS.

Для добавления пользователя в ManagementRealm используем скрипт <JBOSS_HOME>/bin/add-user. Запускаем его и следуем подсказкам.

Теперь можно добавить агент к хосту, указав соответствующие параметры:


После добавления агента для него сразу доступна контрольная панель. Если ей воспользоваться, то получим следующую картинку:


Нефункционально лишь представление JVM Throughput, показывающее производительность в процентах об общего потребляемого времени за вычетом времени на сборку мусора. Т.к. в расчетах используются параметры конкретных сборщиков мусора, то представление нужно корректировать под каждый вариант запуска JVM. Корректировать это представление мы не стали.

Агент с нашими исправлениями в конфигурации можно скачать здесь.

Шаг 5. Теперь очередь сервера приложений

Что хочется узнать:
• Кол-во открытых веб-сессий, ошибки и нагрузку по передаче информации (принято/передано байт).
• Количество транзакций (общее и завершенные с откатом).
• Очереди сообщений JMS (текущий размер очередей).
• Статистика кэша второго уровня Hibernate (Infinispan) (по регионам: размеры кэша, процент попадания, соотношение чтения/записи).
• Пул EJB/MDB компонентов (по компонентам: сколько создано/свободно/используется)
• Статистика по веб-сервисам (по точкам входа: количество запросов общее и с ошибками).

Готовый агент для JBoss AS поддерживает только сервера версий 4.0. и 4.2 через JNDI c доступом по протоколу jnp. Поэтому для мониторинга JBoss AS 7.1 нужно воспользоваться стандартным агентом JMX JSR160 (см. пример и настройку выше для агента HotSpot JVM, в том числе и корректировку описания агента для работы через remoting-jmx).

Прим.: Последний исходный код Ixora RMS уже содержит поддержку JBoss AS 5.x на основе JMX JSR 160, но собранная версия пока отсутствует.


Указания значений в полях Root folder и classpath недостаточно, т.к. используется механизм SPI для поиска протокола, а jar файлы из поля Classpath для агента загружаются отдельным classloader-ом.

После успешного подключения агента к хосту сразу в дереве отображается иерархия сущностей JMX (узлов).


Для примера построения нужных нам графиков и списков, рассмотрим как организовать мониторинг информации по кэшу второго уровня.

Информация о регионах Infinispan представлена в JMX следующими сущностями и показателями:


Для вывода числа и процента попаданий в кэш в виде таблицы с колонками можно воспользоваться XML редактором из контекстного меню на закладке Views. Перед этим лучше активизировать в дереве узел jboss.infinispan, чтобы сохранить построенное представление к этому узлу. После редактирования получим следующий XML:

<rms>
  <view class="com.ixora.rms.ui.dataviewboard.tables.definitions.TableDef">
    <name>Cache regions statistics</name>
    <description>Infinispan cache regions hits statistics</description>
    <query>
      <resource id="region" iname="$1" name="$1" rid="-/-/root/jboss.infinispan/(jboss.infinispan:type=Cache,name="(.*)",.*,component=Statistics)"/>
      <resource id="hits" iname="$1/$counter" name="$1/$counter" rid="-/-/root/jboss.infinispan/(jboss.infinispan:type=Cache,name=(.*),.*,component=Statistics)/[hits]"/>
      <resource id="hitRatio" iname="$1/$counter" name="$1/$counter" rid="-/-/root/jboss.infinispan/(jboss.infinispan:type=Cache,name=(.*),.*,component=Statistics)/[hitRatio]"/>
       </query>
    <agentVersions/>
    <author>customer</author>
    <category id="region"/>
    <column id="hits"/>
    <column id="hitRatio"/>
      </view>
</rms>

Немного комментариев к нему: resource – это источник данных (показатели из дерева) для отображения. Задаются они с помощью абсолютного пути в дереве или относительного. Путь может включать регулярные выражения, которые определяют множество источников. Для каждого источника можно определить атрибуты iname, name, которые определяют уникальный идентификатор ресурса и показываемое его имя. Подробное описание см. на сайте в разделе http://www.ixorarms.com/documentation/user-guide/concepts

Для отображения могут использоваться различные варианты отображения: графики, таблицы с множеством колонок, списки свойств и просмотр логов. В нашем случае используется простейшая таблица.

Определяем в дереве показателей для сервера JBoss AS необходимые нам элементы и для упрощения доступа к ним потом формируем все представления на уровне сущностей jboss.as, jboss.infinispan, jboss.ws соответственно. Для мониторинга различных сервисов используем следующие сущности и их показатели в нотации IxoraRMS:

Веб-сервер	-/-/root/jboss.as/jboss.as:subsystem=web,connector=http.*, показатели: bytesSent, bytesReceived, requestCount, errorCount
Кэш	-/-/root/jboss.infinispan/(jboss.infinispan:type=Cache,name=(.*),.*,component=Statistics), показатели: hits, hitRatio, readWriteRatio, numberOfEntries, evictions
Веб-сервисы	-/-/root/jboss.ws/jboss.ws:context=.*,endpoint=\w+$, показатели: RequestCount, FaultCount
EJB компоненты	-/-/root/jboss.as/jboss.as:deployment=.*,subsystem=ejb3,stateless-session-bean=.*, -/-/root/jboss.as/jboss.as:deployment=.*,subsystem=ejb3,message-drive-bean-bean=.*, показатели: poolAvailableCount, poolCurrentSize, poolCreateCount
Очереди сообщений	-/-/root/jboss.as/jboss.as:subsystem=messaging,hournetq-server=default,jms-queue=.*, -/-/root/jboss.as/jboss.as:subsystem=messaging,hournetq-server=default,jms-topic=.*, показатели: messageCount
Транзакции	-/-/root/jboss.as/jboss.as:subsystem=transactions, показатели: numberOfTransactions, numberOfInflightTransactions, ,numberOfCommitedTransactions, numberOfAbortedTransactions, numberOfApplicationRollbacks

Регулярные выражения позволяют здесь указать целые выборки сущностей вместо конкретных.

В итоге настройки для JBoss AS получим контрольную панель c графиками и таблицами, представленную ниже (уже после нажатия кнопки Start).


Все представления объединяем в единую контрольную панель и сохраняем на уровне агента JMX JSR 160 под названием «JBoss AS 7.x Overview». Это делается мастером на закладке Dashboards для выбранной в дереве сущности. Все настройки представлений и контрольных панелей автоматически сохраняются в настройках агента. Агент JMX JSR 160 с настройками для JBoss AS можно скачать для импорта здесь.

Все контрольные панели можно разместить на различных экранах(screen) в IxoraRMS и переключаться между ними для мониторинга различных показателей системы.

Итого по нашим опытам

Плюсы:

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

И несколько минусов:

• Проект не поддерживается с 2011 года и надо обновлять агенты и провайдеры при необходимости;
• В случае нескольких неудачных прерываний приложения мониторинга JMX интерфейс на стороне JBoss вообще потом не отвечает (это скорее проблема JBoss, но продакшен сервер прийдется перезапускать при необходимости дальнейшего мониторинга);
• Проигрыватель логов на интервале мониторинга 2-3 дня и больше неудобен, отвечает в интерфейсе медленно, тормозит. Правда и размер логов в формате XML около 2-4 Гб, первоначальная фаза просмотра содержит настройки уровня агрегации показателей по минутам, часам, но игры с настройками удобство использования не увеличили. Прим.: позже была обнаружена в последнем исходном коде возможность писать лог в БД, но попробовать не успели.
• Для постоянного мониторинга системы не подходит, можно подключаться эпизодически и контролировать показатели на серверах до 1-2 дней в непрерывном режиме.

На этом мониторинг нашего приложения не закончился и мы попытались без больших вмешательств в приложение мониторить логику самого приложения по следующему списку:

• список наиболее затратных по общему времени выполнению методов сервисов;
• список наиболее затратных по среднему времени выполнению методов сервисов;
• список наиболее часто вызываемых методов сервисов;
• список наиболее затратных по общему времени выполнению SQL запросов;
• список наиболее затратных по среднему времени выполнению SQL запросов;
• список наиболее часто вызываемых SQL запросов;
• ошибки в логе

Но об этом в следующей части. Успехов в отладке!

P.S. А полное понимание исходной проблемы так и не пришло. Показатель Context switches per second для ОС отчетливо уходит в диапазон 8000-10000 через неделю. При этом количество нитей растет несущественно. Синхронизация? AutoFlushIfRequired в Hibernate занимает ну очень много времени: от долей секунды до 30-70 секунд суммарно после деградации на некоторых вызовах сервиса. Кэш первого уровня одинаков по объему для этого запроса сервиса (около 8000 сущностей), но время операции выполнения растет. Синхронизация внутри связки HIbernate и Infinispan? Правдами и неправдами время деградации системы увеличилось и уже близко к 2-м неделям, но хочется большего.