Открыть меню
Открыть персональное меню
Вы не представились системе
Your IP address will be publicly visible if you make any edits.

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

Материал из Документация АппОптима

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

178.png

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

179.png

Предоставленные сведения о сбое включают сигнал, который завершил процесс (например, 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 должна быть включена.

180.png

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

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

181.png

Обработка дампа ядра 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.