Аварийные завершения процессов

Применение АппОптима / Профилирование и оптимизация / Аварийные завершения процессов

Процессы аварийно завершаются по множеству причин, и часто бывает сложно понять основные причины, которые способствуют таким аварийным завершениям. Когда отслеживаемый процесс аварийно завершается, вы увидите запись о сбое процесса в разделе События каждого затронутого процесса и страницы Хосты. В примере процесса ниже есть некоторые проблемы с доступностью (показаны красным на временной шкале). При выборе затронутого временного интервала на временной шкале раздел События показывает количество аварийных завершений процесса, произошедших в течение этого временного интервала (в этом примере 3 сбоя).

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

Предоставленные сведения о сбое включают сигнал, который завершил процесс (например, Segmentation faultили Abort), кадр стека выполнения, который дал сбой, и многое другое. Тип сбоя — например, собственный дамп ядра, дамп ядра Java или ненормальный выход программы из-за исключения — определяет, какие сведения о сбое доступны.

Анализ дополнительных артефактов сбоя

Сведения о сбоях часто включают в себя кнопку Загрузить , которая обеспечивает доступ к дополнительным артефактам сбоев, таким как hs_err_pidфайлы для сбоев Java, текстовые файлы, которые предоставляют анализ основных дампов Linux и Windows, или файлы, содержащие исключения .NET, Java или Node.js, которые потенциально были ответственны за сбои. Например, отчет о сбое Segmentation fault выше привел к созданию основного дампа. ЕдиныйАгент автоматически проанализировал основной дамп, а затем создал следующий отчет в качестве артефакта журнала:

dumpproc version 1.108.0.20161025-115919, installer version 1.108.0.20161025-121046

2016-11-09 18:00:44: Application 'CreditCardAutho', inner pid '15891', outer pid '0', signal: 'Segmentation fault' (11)

process group ID: 0x441b2cb89962033d

process group instance ID: 0xfe58bab23100f42c

process group Name: easytravel-*-x*

threadCount: 1

thread: 0 - stack range: 0x7ffeda572000-0x7ffeda594000, size: 136 kB

0x00007ffeda592be0 0x00007f4de477604d libpthread-2.15.so!<imagebase>+0xf04d

0x00007ffeda592bf0 0x00000000004038d8 CreditCardAuthorizationS64!main+0x1b8

0x00007ffeda592c60 0x00007f4de41c676d libc-2.15.so!__libc_start_main+0xed

0x00007ffeda592d20 0x000000000040329a CreditCardAuthorizationS64!<imagebase>+0x329a

mapped files:

0000000000400000-000000000041e000 0 /home/labuser/easytravel-2.0.0-x64/CreditCardAuthorizationS64 (MD5: da5992daf5ba3b76c633c853c7da5e87)

000000000051d000-000000000051e000 1d /home/labuser/easytravel-2.0.0-x64/CreditCardAuthorizationS64 (MD5: da5992daf5ba3b76c633c853c7da5e87)

00007f4de41a5000-00007f4de4359000 0 /lib/x86_64-linux-gnu/libc-2.15.so (GNU Build-Id: aa64a66ac46bff200848c0a0694011bd0140ab4e)

00007f4de4359000-00007f4de4558000 1b4 /lib/x86_64-linux-gnu/libc-2.15.so (GNU Build-Id: aa64a66ac46bff200848c0a0694011bd0140ab4e)

00007f4de4558000-00007f4de455c000 1b3 /lib/x86_64-linux-gnu/libc-2.15.so (GNU Build-Id: aa64a66ac46bff200848c0a0694011bd0140ab4e)

00007f4de455c000-00007f4de455e000 1b7 /lib/x86_64-linux-gnu/libc-2.15.so (GNU Build-Id: aa64a66ac46bff200848c0a0694011bd0140ab4e)

00007f4de4563000-00007f4de4565000 0 /lib/x86_64-linux-gnu/libdl-2.15.so (GNU Build-Id: d181af551dbbc43e9d55913d532635fde18e7c4e)

00007f4de4565000-00007f4de4765000 2 /lib/x86_64-linux-gnu/libdl-2.15.so (GNU Build-Id: d181af551dbbc43e9d55913d532635fde18e7c4e)

00007f4de4765000-00007f4de4766000 2 /lib/x86_64-linux-gnu/libdl-2.15.so (GNU Build-Id: d181af551dbbc43e9d55913d532635fde18e7c4e)

00007f4de4766000-00007f4de4767000 3 /lib/x86_64-linux-gnu/libdl-2.15.so (GNU Build-Id: d181af551dbbc43e9d55913d532635fde18e7c4e)

00007f4de4767000-00007f4de477f000 0 /lib/x86_64-linux-gnu/libpthread-2.15.so (GNU Build-Id: c340af9dee97c17c730f7d03693286c5194a46b8)

00007f4de477f000-00007f4de497e000 18 /lib/x86_64-linux-gnu/libpthread-2.15.so (GNU Build-Id: c340af9dee97c17c730f7d03693286c5194a46b8)

00007f4de497e000-00007f4de497f000 17 /lib/x86_64-linux-gnu/libpthread-2.15.so (GNU Build-Id: c340af9dee97c17c730f7d03693286c5194a46b8)

00007f4de497f000-00007f4de4980000 18 /lib/x86_64-linux-gnu/libpthread-2.15.so (GNU Build-Id: c340af9dee97c17c730f7d03693286c5194a46b8)

00007f4de4984000-00007f4de4a02000 0 /lib/x86_64-linux-gnu/liboneagentproc.so (1.108.0.20161025-115919)

00007f4de4a02000-00007f4de4c01000 7e /lib/x86_64-linux-gnu/liboneagentproc.so (1.108.0.20161025-115919)

00007f4de4c01000-00007f4de4c03000 7d /lib/x86_64-linux-gnu/liboneagentproc.so (1.108.0.20161025-115919)

00007f4de4c03000-00007f4de4c05000 7f /lib/x86_64-linux-gnu/liboneagentproc.so (1.108.0.20161025-115919)

00007f4de4cc0000-00007f4de4ce2000 0 /lib/x86_64-linux-gnu/ld-2.15.so (GNU Build-Id: e25ad1a11ccf57e734116b8ec9c69f643dca9f18)

00007f4de4ee2000-00007f4de4ee3000 22 /lib/x86_64-linux-gnu/ld-2.15.so (GNU Build-Id: e25ad1a11ccf57e734116b8ec9c69f643dca9f18)

00007f4de4ee3000-00007f4de4ee5000 23 /lib/x86_64-linux-gnu/ld-2.15.so (GNU Build-Id: e25ad1a11ccf57e734116b8ec9c69f643dca9f18)

Защитите конфиденциальные данные пользователя

Отчеты о сбоях могут содержать конфиденциальную личную информацию, которую не следует просматривать всем пользователям. По этой причине ваш администратор АппОптима должен включить опцию безопасности учетной записи View logs и разрешения View sensitive request data в вашем профиле пользователя, прежде чем вы сможете просматривать персональные данные. Эта опция отключена по умолчанию для всех пользователей, не являющихся администраторами, и должна быть явно включена, прежде чем вы сможете получить доступ к содержимому журнала.

Обработка сбоев в Windows

Для того чтобы общий сбой процесса Windows (дамп ядра) был виден в АппОптима, сбой должен быть обнаружен Windows Error Reporting. По этой причине служба Windows Error Reporting должна быть включена.

Когда в Windows происходит сбой, появляется диалоговое окно с вопросом, хотите ли вы отладить или закрыть аварийное приложение. Это нежелательно для систем headless. Вы можете отключить это диалоговое окно, добавив значение в реестр, как показано ниже:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting] "DontShowUI"=dword:00000001

Обработка дампа ядра Linux

В Linux способ обработки ядром дампа ядра задается в /proc/sys/kernel/core_pattern. Начиная с ядра 2.6.19 (1), существует два метода обработки сбоев приложений. Дамп ядра может быть записан в файл, на который указывает запись /proc/sys/kernel/core_pattern, или отправлен в приложение — запись должна иметь префикс в виде вертикальной косой черты (|).

Поскольку Suse Linux использует первый метод, запись похожа на /proc/sys/kernel/core_pattern:core. Это означает, что файл с именем coreзаписывается в текущий рабочий каталог аварийно завершившегося процесса.

Ubuntu и Red Hat обычно полагаются на свои собственные инструменты для создания отчетов об ошибках, поэтому строки выглядят следующим образом:

|/usr/share/apport/apport %p %s %c %P

или

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

В последнем примере, когда программа аварийно завершает работу, coredumpвывод передается в приложение stdin, указанное в первом параметре. Более того, ядро ​​заполняет значения любых параметров, отформатированных как %[a-zA-Z]. apportСлужба отчетов перезаписывает файл /proc/sys/kernel/core_pattern. Если apportвключено (в /etc/default/apport), то /proc/sys/kernel/core_patternнастройка конфигурации устанавливается при apportзапуске службы отчетов о сбоях при загрузке системы.

Изменения операционной системы

Установщик ЕдиногоАгента вносит в вашу систему следующие изменения для обработки дампов ядра.

Отключение ABRT и Apport

ABRT (Red Hat) и Apport (Debian) службы остановлены и отключены.

Обе службы повторно включаются во время удаления ЕдиногоАгента .

Обработка основного шаблона

Установщик ЕдиногоАгента перезаписывает основной шаблон своей собственной командой, но сохраняет исходный шаблон.

• Содержимое исходного файла /proc/sys/kernel/core_pattern копируется в /opt/astromkey/oneagent/agent/conf/original_core_pattern. При удалении ЕдиныйАгент деинсталлятор восстанавливает исходный шаблон ядра, присутствующий в этом файле, в /proc/sys/kernel/core_pattern.
• Содержимое kernel.core_patternисходного параметра /etc/sysctl.confкопируется в /opt/astromkey/oneagent/agent/conf/original.sysctl.corepattern. При удалении ЕдиныйАгент деинсталлятор восстанавливает исходный шаблон ядра, присутствующий в этом файле, kernel.core_patternв /etc/sysctl.conf. Если kernel.core_patternотсутствует в /etc/sysctl.confдо установки ЕдиногоАгента, /opt/astromkey/oneagent/agent/conf/original.sysctl.corepatternфайл не создается.

В зависимости от исходной записи в core_patternАппОптима запишет различные шаблоны в core_pattern. Возможные конфигурации и ожидаемые записи после установки перечислены ниже:

Исходная запись core_pattern	core_pattern после установки ruxitdumpproc	Комментарий
core	/opt/astromkey/oneagent/agent/rdp -p %p -e %e -s %s	Простой дамп ядра без параметров.
core_%s_%e	/opt/astromkey/oneagent/agent/rdp -p %p -e %e -s %s -kp %s,%e	Простой дамп ядра с параметрами в имени файла. Параметр -kpдобавляется вместе со всеми параметрами ядра, необходимыми для замены АппОптима в исходном имени файла.
/usr/share/apport/apport	/opt/astromkey/oneagent/agent/rdp -p %p -e %e -s %s	Дамп ядра следующее приложение без параметров. Аргумент -aне добавляется к выходной записи core_pattern, если нет параметров.
/usr/share/apport/apport %p %s %c %P	/opt/astromkey/oneagent/agent/rdp -p %p -e %e -s %s -a %p %s %c %P	Дамп ядра следующее приложение с параметрами. Аргумент -aдобавляется вместе со всеми параметрами после двоичного пути к apport.

Основная обработка ЕдиныйАгент dumpproc

Когда происходит сбой:

1. rdpвызывается для сброса ядра в папки ЕдиногоАгента. Это ядро ​​используется функциональностью Crash Reporting.
2. ЕдиныйАгент считывает /opt/astromkey/oneagent/agent/conf/original_core_patternи генерирует ядро ​​в соответствии с настройками. Это означает, что если исходная настройка записывала файл ядра в определенное место, это все равно произойдет после установки ЕдиногоАгента.
3. Анализируется дамп ядра, чтобы проверить, мог ли АппОптима стать основной причиной сбоя.
   • Если ЕдиныйАгент определит, что АппОптима мог быть причиной:
     • Создается оповещение службы поддержки. Об этом сообщается нашей команде DevOps.
     • Основной дамп архивируется и сохраняется в дополнение ко всем задействованным библиотекам. Это необходимо для последующего офлайн-анализа.
   • Если ЕдиныйАгент определит, что АппОптима не является причиной:
     • Сообщения о сбое отправляются пользователю через веб-интерфейс АппОптима.
     • Если это оказывает какое-либо влияние на приложение клиента, открывается проблема и генерируется соответствующее событие для задействованных процессов, как описано выше.

Очистка

Каталоги журналов и оповещений службы поддержки очищаются автоматически.

• Для оповещений службы поддержки мы обрабатываем файл core dump, затем архивируем его и сохраняем для отправки в кластер.
• В случае сбоев (неинструментированных процессов или инструментированных процессов, когда мы решаем, что АппОптима не виноват) мы обрабатываем, а затем удаляем копию файла core dump.