Моніторинг під рукою на IxoraRMS. Швидко і зі смаком

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, без БД, необхідність глибоких знань адміністрування linux та процесу складання з вихідного коду)
  • Для збору всіх показників є агенти і провайдери, багато готові до використання. У багатьох випадках отримання даних з системи/джерела можна просто описати в інтерфейсі без рядків коду.
  • Приклади моніторингу ОС, СУБД, веб-сервера і 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
• у список versions System додаємо «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 при тій же командному рядку відсутні, тому їх видаляємо;
• на закладці is invalid зберігаються типи показників та їх опис для легенди. У нашому випадку рядка для віддалених показників просто зникнуть;
• зберігаємо провайдер.

Таким чином, порівнюючи висновок використовуваних утиліт з вказаними параметрами, наводимо провайдери для 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 провайдера з наступною моделлю даних
Data Connection: Connection/[ Opened, Locked, MaxAvailable ]
Transaction data: Transaction/[Total, Active, MaxAge]
Input/Output: Statistics/[ logical Block reads, logical Block writes, Block reads, Block writes, Selects]

Тепер створюємо нового агента наступним чином:
• відкриваємо меню Tools/Agents Installer і в діалозі натискаємо кнопку Install;
• далі вибираємо Custom agent installation;
• як Agent Template вибираємо SQL;
• заповнюємо властивості агента Linter наступним чином:
image
• тепер відкриваємо меню Tools/Provider Manager;
• вибираємо агент Linter і натискаємо Add для створення провайдера Data Connection;
• вибираємо тип провайдера 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 описуємо що формуються сутності та показники на основі значень колонок у вибірці;

• на закладці is invalid описуємо типи показників та їх опис

Аналогічним чином додаємо ще 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-му тижнях, але хочеться більшого.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.