Анализ сбоев

Применение Ключ-АСТРОМ / Диагностика / Анализ сбоев

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

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

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

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

Отчеты о сбоях могут содержать конфиденциальную личную информацию, которую не должны просматривать все пользователи. По этой причине ваш администратор Ключ-АСТРОМ должен включить параметр безопасности учетной записи « Просмотр журналов » и разрешения « Просмотр конфиденциальных данных запроса » в вашем профиле пользователя, прежде чем вы сможете просматривать личные данные. Этот параметр отключен по умолчанию для всех пользователей без прав администратора и должен быть явно включен, прежде чем вы сможете получить доступ к содержимому журнала.

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

Чтобы общий сбой процесса Windows (дамп ядра) был виден Ключ-АСТРОМ, сбой должен быть обнаружен с помощью отчетов об ошибках Windows. По этой причине служба отчетов об ошибках Windows должна быть включена.

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

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

Вы можете узнать о других важных настройках, связанных с отчетами об ошибках Windows, посетив документацию Microsoft .

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

Основная обработка с помощью дампа ЕдиногоАгента.

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

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

Очистка

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

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