Сбор диагностической информации для анализа проблем#

Данная инструкция описывает процесс сбора необходимой диагностической информации и формат хранения, для каждого типа проблемы.

Утечка памяти#

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

  1. Версия дистрибутивов (IDMX, IDMC).

  2. Среда развертывания (OpenShift, DropApp).

  3. (Если нет внешней системы хранения логов) Скачайте логи проблемных POD - если pod продолжает уходить в рестарт дождаться повторения причины и успеть скачать log. Либо если досутпен Previous log режим в окне логов. То скачать с помощью него лог-файл пода.

    img.png

    Если есть система хранения логов то предоставить логи с проблемного пода за 2 часа до инцидента и 2 часа после.

  4. Скачать Yaml StatefulSet’a idmx-engine (Переходим в меню Workloads кластера OSE / DropApp

    img_1.png

    Переходим в один единственный StatefullSet > затем во вкладку Yaml и нажимаем кнопку Download расположенную внизу справа

    img_2.png

    img_3.png

  5. Скачать значения ConfigMap: idmx-cm-engine (Аналогичным способом (Переходим в меню Workloads кластера OSE / DropApp >

    Затем переходим в ConfigMap: idmx-cm-engine выделенный желтым на скриншоте > затем во вкладку Yaml и нажимаем кнопку Download расположенную внизу справа

    img_4.png

  6. Необходимо собрать сообщения о событиях самого пространства имен в Openshift / DropApp.

    Перейдите в проект в кластере OSE/DropApp в левом меню выберите раздел Home затем перейдите в пункт Events

    img_5.png

    И сделайте скриншот или сохраните в текстовом варианте ошибки:

    img_6.png

  7. Необходимо предоставить данные с системы мониторинга:

    Данные с Дашборда: IDM Engine metrics V2

    Данные с дашборда JVM (Micrometer)

    Дашборды — JVM metrics.json

    img_7.png

    Самым информативным именно для проблемы утечки памяти в данном дашборде будет раздел JVM Memory и JVM Memory pools heap. Но остальные графики так же важны для понимания и выявления косвенных проблем так же приводящих к утечке.

    img_8.png

    img_9.png

Высокая утилизация CPU#

Высокая утилизация CPU Базы данных#

Для определения проблем с утилизацией БД, можем разделить сбор данных на три этапа:

  1. Сбор метрик мониторинга

  2. Сбор логов БД

  3. Сбор статистических данных самого postgres: Pg_profile статистики запросам, блокировок на бд и тд.

Ниже приведено описание действий на каждом этапе:

  1. Сбор метрик мониторинга:

    Необходимо собрать метрики HicariCP дашборда (дашборд прикреплен ниже).

    Hikari CP dashboard.json

    img_10.png

    Данный дашборд покажет проблемы работы самого ядра с БД. Коренвых причин он не отображает, поэтому необходимо будет собрать и метрики и логи с самой БД.

    Для сбора метрик самой базы данных необходимо определить какую БД использует IDM. Это отображено в Config-Map в Openshift:

    БД Репозитария:

    IDM_SET_midpoint_repository_jdbcUrl: >-
jdbc:postgresql://idm-psql.dev.mydomain:12123/dev_db?targetServerType=primary&prepareThreshold=0&sslmode=disable

    БД Аудита:

    IDM_SET_midpoint_audit_auditService__2__jdbcUrl: >-
jdbc:postgresql://idm-psql.dev.mydomain:12123/dev_audit_db?prepareThreshold=0&sslmode=disable

    После определения имен серверов используемых продуктом. Необходимо в инфраструктурном мониторинге «МЯУ» найти данные сервера и прислать все метрики отображаемые относительно данных серверов:

    Утилизация ЦПУ, Утиллизация Памяти, Нагрузка на сеть…

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

  2. Сбор логов БД

    Если к БД подключена внешняя система логирования то логи необходимо собрать за период 2 часа до инцидента и 2 часа после

    Если же внешняя система логирования не подключена, то вам необходимо подключиться непосредственно на сервер где установлен Pangolin (PostgreSQL) перейти в достаточно привелигированного пользователя (postgres, root) у которого будет достаточно прав на просмотр лог файлов. Далее переходим по пути:

    /pgerrorlogs/6/

    И скачиваем файлы:

    • pangolin-pooler.log - логи pgbouncer с 6ой версии pangolin переименован в pangolin-pooler - в нем будут отображены не сами запросы а только работа с подключением.

    • postgresql-2026-01-16_000000.log - логи самой БД, если в настройках баз данных выставлен достаточный уровень логирования то будут видны и сами запросы. По дефолту там логирование мало что отображает, нужно устанавливать в настройках предварительно.

  3. Сбор статистических данных самого postgres:

    1. Во внешней системе «МЯУ» необходимо найти раздел где можно заказывать статистику pg_profile.

      Сохранить отчет.

    2. Во внешней системе «МЯУ» необходимо найти раздел где можно заказывать статистику по блокировках на БД.

      Сохранить отчет.

Высокая утилизация CPU POD#

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

  1. Версия дистрибутивов (IDMX, IDMC).

  2. Среда развертывания (OpenShift, DropApp).

  3. (Если нет внешней системы хранения логов) Скачайте логи проблемных POD - если pod продолжает уходить в рестарт дождаться повторения причины и успеть скачать log. Либо если досутпен Previous log режим в окне логов. То скачать с помощью него лог-файл пода.

    img.png

    Если есть система хранения логов то предоставить логи с проблемного пода за 2 часа до инцидента и 2 часа после.

  4. Скачать Yaml StatefulSet’a idmx-engine (Переходим в меню Workloads кластера OSE / DropApp

    img_1.png

    Переходим в один единственный StatefullSet > затем во вкладку Yaml и нажимаем кнопку Download расположенную внизу справа

    img_2.png

    img_3.png

  5. Скачать значения ConfigMap: idmx-cm-engine (Аналогичным способом (Переходим в меню Workloads кластера OSE / DropApp >

    Затем переходим в ConfigMap: idmx-cm-engine выделенный желтым на скриншоте > затем во вкладку Yaml и нажимаем кнопку Download расположенную внизу справа

    img_4.png

  6. Необходимо собрать сообщения о событиях самого пространства имен в Openshift / DropApp.

    Перейдите в проект в кластере OSE/DropApp в левом меню выберите раздел Home затем перейдите в пункт Events

    img_5.png

    И сделайте скриншот или сохраните в текстовом варианте ошибки:

    img_6.png

  7. Необходимо предоставить данные с системы мониторинга:

    Данные с Дашборда: IDM Engine metrics V2

    Данные с дашборда JVM (Micrometer)

    Дашборды — JVM metrics.json

    img_7.png

    Самым информативным именно для проблемы утечки памяти в данном дашборде будет раздел JVM Misc и Garbage collections. Но остальные графики так же важны для понимания и выявления косвенных проблем так же приводящих к утечке.

    img_12.png

    img_13.png

Общее замедление работы#

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

  1. Версия дистрибутивов (IDMX, IDMC).

  2. Среда развертывания (OpenShift, DropApp).

  3. (Если нет внешней системы хранения логов) Скачайте логи проблемных POD - если pod продолжает уходить в рестарт дождаться повторения причины и успеть скачать log. Либо если досутпен Previous log режим в окне логов. То скачать с помощью него лог-файл пода.

    img.png

    Если есть система хранения логов то предоставить логи с проблемного пода за 2 часа до инцидента и 2 часа после.

  4. Скачать Yaml StatefulSet’a idmx-engine (Переходим в меню Workloads кластера OSE / DropApp

    img_1.png

    Переходим в один единственный StatefullSet > затем во вкладку Yaml и нажимаем кнопку Download расположенную внизу справа

    img_2.png

    img_3.png

  5. Скачать значения ConfigMap: idmx-cm-engine (Аналогичным способом (Переходим в меню Workloads кластера OSE / DropApp >

    Затем переходим в ConfigMap: idmx-cm-engine выделенный желтым на скриншоте > затем во вкладку Yaml и нажимаем кнопку Download расположенную внизу справа

    img_4.png

  6. Необходимо собрать сообщения о событиях самого пространства имен в Openshift / DropApp.

    Перейдите в проект в кластере OSE/DropApp в левом меню выберите раздел Home затем перейдите в пункт Events

    img_5.png

    И сделайте скриншот или сохраните в текстовом варианте ошибки:

    img_6.png

  7. Необходимо предоставить данные с системы мониторинга:

    Данные с Дашборда: IDM Engine metrics V2

    Данные с дашборда JVM (Micrometer)

    Дашборды — JVM metrics.json, IDM Engine metrics V2.json

    img_7.png

  8. Так же необходимо будет собрать события аудита в несколько запросов так как базы раздельные

    select
mae.taskidentifier,
date_trunc('hour', mae."timestamp") AS hour,
COUNT(mae.eventtype) AS event_count,
mae.eventtype
from
public.ma_audit_event mae
where mae.eventstage = 'EXECUTION' and mae.outcome = 'SUCCESS'

and
mae."timestamp" >= '2025-12-23 00:00:00' AND mae."timestamp" < '2025-12-24 00:00:00'

GROUP BY
mae.taskidentifier , hour,mae.eventtype
ORDER BY
event_count DESC, hour;

    Второй запрос для получения имен задач и их идентификаторов

    select distinct mt.namenorm, mt.taskidentifier from public.m_task mt;

Диагностика работы TASK#

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

  1. Версия дистрибутивов (IDMX, IDMC).

  2. Среда развертывания (OpenShift, DropApp).

  3. (Если нет внешней системы хранения логов) Скачайте логи проблемных POD - если pod продолжает уходить в рестарт дождаться повторения причины и успеть скачать log. Либо если досутпен Previous log режим в окне логов. То скачать с помощью него лог-файл пода.

    img.png

    Если есть система хранения логов то предоставить логи с проблемного пода за 2 часа до инцидента и 2 часа после.

  4. Скачать Yaml StatefulSet’a idmx-engine (Переходим в меню Workloads кластера OSE / DropApp

    img_1.png

    Переходим в один единственный StatefullSet > затем во вкладку Yaml и нажимаем кнопку Download расположенную внизу справа

    img_2.png

    img_3.png

  5. Скачать значения ConfigMap: idmx-cm-engine (Аналогичным способом (Переходим в меню Workloads кластера OSE / DropApp >

    Затем переходим в ConfigMap: idmx-cm-engine выделенный желтым на скриншоте > затем во вкладку Yaml и нажимаем кнопку Download расположенную внизу справа

    img_4.png

  6. Необходимо собрать сообщения о событиях самого пространства имен в Openshift / DropApp.

    Перейдите в проект в кластере OSE/DropApp в левом меню выберите раздел Home затем перейдите в пункт Events

    img_5.png

    И сделайте скриншот или сохраните в текстовом варианте ошибки:

    img_6.png

  7. Необходимо предоставить данные с системы мониторинга:

    Данные с Дашборда: IDM Engine metrics V2

    Данные с дашборда JVM (Micrometer)

    Дашборды — JVM metrics.json

    img_7.png

    Самым информативным именно для проблемы утечки памяти в данном дашборде будет разделы Tasks, Perfomance и Provisioning. Но остальные графики так же важны для понимания и выявления косвенных проблем так же приводящих к утечке.

  8. Необходимо сохранить через Edit raw саму task и ее subtasks:

    1. Перейдите во вкладку Администрирование > Задачи:

      img_14.png

    2. Перейдите в саму задачу и нажмите вверху справа кнопку «Экспорт».

      img_15.png

    3. Затем перейдите в подзадачи данной задачи и сделайте тоже самое (Экспорт) перейдя в каждую подзадачу

      img_16.png

Диагностика работы ресурсов#

Для диагностики проблем работы с ресурсами необходимо сообщить и предоставить следующие данные:

  1. Версия дистрибутивов (IDMX, IDMC).

  2. Среда развертывания (OpenShift, DropApp).

  3. (Если нет внешней системы хранения логов) Скачайте логи проблемных POD - если pod продолжает уходить в рестарт дождаться повторения причины и успеть скачать log. Либо если досутпен Previous log режим в окне логов. То скачать с помощью него лог-файл пода.

    img.png

    Если есть система хранения логов то предоставить логи с проблемного пода за 2 часа до инцидента и 2 часа после.

  4. Скачать Yaml StatefulSet’a idmx-engine (Переходим в меню Workloads кластера OSE / DropApp

    img_1.png

    Переходим в один единственный StatefullSet > затем во вкладку Yaml и нажимаем кнопку Download расположенную внизу справа

    img_2.png

    img_3.png

  5. Скачать значения ConfigMap: idmx-cm-engine (Аналогичным способом (Переходим в меню Workloads кластера OSE / DropApp >

    Затем переходим в ConfigMap: idmx-cm-engine выделенный желтым на скриншоте > затем во вкладку Yaml и нажимаем кнопку Download расположенную внизу справа

    img_4.png

  6. Необходимо собрать сообщения о событиях самого пространства имен в Openshift / DropApp.

    Перейдите в проект в кластере OSE/DropApp в левом меню выберите раздел Home затем перейдите в пункт Events

    img_5.png

    И сделайте скриншот или сохраните в текстовом варианте ошибки:

    img_6.png

  7. Необходимо предоставить данные с системы мониторинга:

    Данные с Дашборда: IDM Engine metrics V2

    Данные с дашборда JVM (Micrometer)

    Дашборды — JVM metrics.json

    img_7.png

    Самым информативным именно для проблемы утечки памяти в данном дашборде будет разделы Perfomance, Provisioning в особенности Average execution duration. Но остальные графики так же важны для понимания и выявления косвенных проблем так же приводящих к утечке.

  8. Необходимо сохранить Resource и прикрепить:

    1. Перейдите во вкладку Администрирование > Ресурсы:

      img_17.png

    2. Перейдите в саму задачу и нажмите вверху справа кнопку «Экспорт».

      img_18.png