Как стать автором
Обновить
0
РЕЛЭКС
Разработка ПО на заказ, аутсорсинг, СУБД ЛИНТЕР

Мониторинг под рукой на IxoraRMS. Быстро и со вкусом

Время на прочтение 16 мин
Количество просмотров 8.4K
image
Иногда проблема с приложением выливается в небольшой кошмар, ребус. Назовите, как хотите. Хочу поделиться об опыте использования средств мониторинга разработчиками на одном из проектов. Хабр многолик и уже существуют десятки статей о продуктах, которые облегчают понимание происходящего: 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).

Примеры того, что можно увидеть на экране после настройки
image

image

image

Остальные скриншоты можно посмотреть здесь

Коротко об IxoraRMS


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


Концепция


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

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

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

image


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

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

image


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

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

image


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


Шаг 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»
image

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

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

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

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

image

• столбцы в выводе 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 следующим образом:
image

• открываем теперь меню 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-м неделям, но хочется большего.
Теги:
Хабы:
+6
Комментарии 0
Комментарии Комментировать

Публикации

Информация

Сайт
relex.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия

Истории