Аварийные завершения процессов: различия между версиями

Материал из Документация Ключ-АСТРОМ
(Создана пустая страница)
 
Строка 1: Строка 1:
Процессы аварийно завершаются по множеству причин, и часто бывает сложно понять основные причины, которые способствуют таким аварийным завершениям. Когда отслеживаемый процесс аварийно завершается, вы увидите запись о сбое процесса в разделе '''События''' каждого затронутого процесса и страницы '''Хосты'''. В примере процесса ниже есть некоторые проблемы с доступностью (показаны красным на временной шкале). При выборе затронутого временного интервала на временной шкале раздел '''События''' показывает количество аварийных завершений процесса, произошедших в течение этого временного интервала (в этом примере 3 сбоя).


[[Файл:178.png]]
Нажмите '''Детали сбоя процесса''' , чтобы просмотреть подробный список сбоев, произошедших в течение выбранного таймфрейма. Здесь вы найдете все подробности, связанные с причиной сбоя каждого процесса.
[[Файл:179.png|граница]]
Предоставленные сведения о сбое включают сигнал, который завершил процесс (например, <code>Segmentation fault</code>или <code>Abort</code>), кадр стека выполнения, который дал сбой, и многое другое. Тип сбоя — например, собственный дамп ядра, дамп ядра Java или ненормальный выход программы из-за исключения — определяет, какие сведения о сбое доступны.
== Анализ дополнительных артефактов сбоя ==
Сведения о сбоях часто включают в себя кнопку '''Загрузить''' , которая обеспечивает доступ к дополнительным артефактам сбоев, таким как <code>hs_err_pid</code>файлы для сбоев Java, текстовые файлы, которые предоставляют анализ основных дампов Linux и Windows, или файлы, содержащие исключения .NET, Java или Node.js, которые потенциально были ответственны за сбои. Например, отчет о сбое '''Segmentation fault''' выше привел к созданию основного дампа. ЕдиныйАгент автоматически проанализировал основной дамп, а затем создал следующий отчет в качестве артефакта журнала:
<code>dumpproc version 1.108.0.20161025-115919, installer version 1.108.0.20161025-121046</code>
<code>2016-11-09 18:00:44: Application 'CreditCardAutho', inner pid '15891', outer pid '0', signal: 'Segmentation fault' (11)</code>
<code>process group ID: 0x441b2cb89962033d</code>
<code>process group instance ID: 0xfe58bab23100f42c</code>
<code>process group Name: easytravel-*-x*</code>
<code>threadCount: 1</code>
<code>thread: 0 - stack range: 0x7ffeda572000-0x7ffeda594000, size: 136 kB</code>
<code>0x00007ffeda592be0 0x00007f4de477604d libpthread-2.15.so!<imagebase>+0xf04d</code>
<code>0x00007ffeda592bf0 0x00000000004038d8 CreditCardAuthorizationS64!main+0x1b8</code>
<code>0x00007ffeda592c60 0x00007f4de41c676d libc-2.15.so!__libc_start_main+0xed</code>
<code>0x00007ffeda592d20 0x000000000040329a CreditCardAuthorizationS64!<imagebase>+0x329a</code>
<code>mapped files:</code>
<code>0000000000400000-000000000041e000 0 /home/labuser/easytravel-2.0.0-x64/CreditCardAuthorizationS64 (MD5: da5992daf5ba3b76c633c853c7da5e87)</code>
<code>000000000051d000-000000000051e000 1d /home/labuser/easytravel-2.0.0-x64/CreditCardAuthorizationS64 (MD5: da5992daf5ba3b76c633c853c7da5e87)</code>
<code>00007f4de41a5000-00007f4de4359000 0 /lib/x86_64-linux-gnu/libc-2.15.so (GNU Build-Id: aa64a66ac46bff200848c0a0694011bd0140ab4e)</code>
<code>00007f4de4359000-00007f4de4558000 1b4 /lib/x86_64-linux-gnu/libc-2.15.so (GNU Build-Id: aa64a66ac46bff200848c0a0694011bd0140ab4e)</code>
<code>00007f4de4558000-00007f4de455c000 1b3 /lib/x86_64-linux-gnu/libc-2.15.so (GNU Build-Id: aa64a66ac46bff200848c0a0694011bd0140ab4e)</code>
<code>00007f4de455c000-00007f4de455e000 1b7 /lib/x86_64-linux-gnu/libc-2.15.so (GNU Build-Id: aa64a66ac46bff200848c0a0694011bd0140ab4e)</code>
<code>00007f4de4563000-00007f4de4565000 0 /lib/x86_64-linux-gnu/libdl-2.15.so (GNU Build-Id: d181af551dbbc43e9d55913d532635fde18e7c4e)</code>
<code>00007f4de4565000-00007f4de4765000 2 /lib/x86_64-linux-gnu/libdl-2.15.so (GNU Build-Id: d181af551dbbc43e9d55913d532635fde18e7c4e)</code>
<code>00007f4de4765000-00007f4de4766000 2 /lib/x86_64-linux-gnu/libdl-2.15.so (GNU Build-Id: d181af551dbbc43e9d55913d532635fde18e7c4e)</code>
<code>00007f4de4766000-00007f4de4767000 3 /lib/x86_64-linux-gnu/libdl-2.15.so (GNU Build-Id: d181af551dbbc43e9d55913d532635fde18e7c4e)</code>
<code>00007f4de4767000-00007f4de477f000 0 /lib/x86_64-linux-gnu/libpthread-2.15.so (GNU Build-Id: c340af9dee97c17c730f7d03693286c5194a46b8)</code>
<code>00007f4de477f000-00007f4de497e000 18 /lib/x86_64-linux-gnu/libpthread-2.15.so (GNU Build-Id: c340af9dee97c17c730f7d03693286c5194a46b8)</code>
<code>00007f4de497e000-00007f4de497f000 17 /lib/x86_64-linux-gnu/libpthread-2.15.so (GNU Build-Id: c340af9dee97c17c730f7d03693286c5194a46b8)</code>
<code>00007f4de497f000-00007f4de4980000 18 /lib/x86_64-linux-gnu/libpthread-2.15.so (GNU Build-Id: c340af9dee97c17c730f7d03693286c5194a46b8)</code>
<code>00007f4de4984000-00007f4de4a02000 0 /lib/x86_64-linux-gnu/liboneagentproc.so (1.108.0.20161025-115919)</code>
<code>00007f4de4a02000-00007f4de4c01000 7e /lib/x86_64-linux-gnu/liboneagentproc.so (1.108.0.20161025-115919)</code>
<code>00007f4de4c01000-00007f4de4c03000 7d /lib/x86_64-linux-gnu/liboneagentproc.so (1.108.0.20161025-115919)</code>
<code>00007f4de4c03000-00007f4de4c05000 7f /lib/x86_64-linux-gnu/liboneagentproc.so (1.108.0.20161025-115919)</code>
<code>00007f4de4cc0000-00007f4de4ce2000 0 /lib/x86_64-linux-gnu/ld-2.15.so (GNU Build-Id: e25ad1a11ccf57e734116b8ec9c69f643dca9f18)</code>
<code>00007f4de4ee2000-00007f4de4ee3000 22 /lib/x86_64-linux-gnu/ld-2.15.so (GNU Build-Id: e25ad1a11ccf57e734116b8ec9c69f643dca9f18)</code>
<code>00007f4de4ee3000-00007f4de4ee5000 23 /lib/x86_64-linux-gnu/ld-2.15.so (GNU Build-Id: e25ad1a11ccf57e734116b8ec9c69f643dca9f18)</code>
== Защитите конфиденциальные данные пользователя ==
Отчеты о сбоях могут содержать конфиденциальную личную информацию, которую не следует просматривать всем пользователям. По этой причине ваш администратор Ключ-АСТРОМ должен включить опцию безопасности учетной записи '''View logs''' и разрешения '''View sensitive request data''' в вашем профиле пользователя, прежде чем вы сможете просматривать персональные данные. Эта опция отключена по умолчанию для всех пользователей, не являющихся администраторами, и должна быть явно включена, прежде чем вы сможете получить доступ к содержимому журнала.
== Обработка сбоев в Windows ==
Для того чтобы общий сбой процесса Windows (дамп ядра) был виден в Ключ-АСТРОМ, сбой должен быть обнаружен '''Windows Error Reporting'''. По этой причине служба '''Windows Error Reporting''' должна быть включена.
[[Файл:180.png|граница]]
Когда в Windows происходит сбой, появляется диалоговое окно с вопросом, хотите ли вы отладить или закрыть аварийное приложение. Это нежелательно для систем headless. Вы можете отключить это диалоговое окно, добавив значение в реестр, как показано ниже:
<code>[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting] "DontShowUI"=dword:00000001</code>
[[Файл:181.png|граница]]
== Обработка дампа ядра Linux ==
В Linux способ обработки ядром дампа ядра задается в <code>/proc/sys/kernel/core_pattern</code>. Начиная с ядра 2.6.19 (1), существует два метода обработки сбоев приложений. Дамп ядра может быть записан в файл, на который указывает запись <code>/proc/sys/kernel/core_pattern</code>, или отправлен в приложение — запись должна иметь префикс в виде вертикальной косой черты (<code>|</code>).
Поскольку '''Suse Linux''' использует первый метод, запись похожа на <code>/proc/sys/kernel/core_pattern:core</code>. Это означает, что файл с именем <code>core</code>записывается в текущий рабочий каталог аварийно завершившегося процесса.
'''Ubuntu''' и '''Red Hat''' обычно полагаются на свои собственные инструменты для создания отчетов об ошибках, поэтому строки выглядят следующим образом:
<code>|/usr/share/apport/apport %p %s %c %P</code>
или
<code>|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e</code>
В последнем примере, когда программа аварийно завершает работу, <code>coredump</code>вывод передается в приложение <code>stdin</code>, указанное в первом параметре. Более того, ядро ​​заполняет значения любых параметров, отформатированных как <code>%[a-zA-Z]</code>. <code>apport</code>Служба отчетов перезаписывает файл <code>/proc/sys/kernel/core_pattern</code>. Если <code>apport</code>включено (в <code>/etc/default/apport</code>), то <code>/proc/sys/kernel/core_pattern</code>настройка конфигурации устанавливается при <code>apport</code>запуске службы отчетов о сбоях при загрузке системы.
=== Изменения операционной системы ===
Установщик ЕдиногоАгента вносит в вашу систему следующие изменения для обработки дампов ядра.
==== Отключение ABRT и Apport ====
'''''[https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/deployment_guide/ch-abrt ABRT]''''' (Red Hat) и '''''[https://launchpad.net/ubuntu/+source/apport Apport]''''' (Debian) службы остановлены и отключены.
Обе службы повторно включаются во время удаления ЕдиногоАгента .
==== Обработка основного шаблона ====
Установщик ЕдиногоАгента перезаписывает основной шаблон своей собственной командой, но сохраняет исходный шаблон.
* Содержимое исходного файла <code>/proc/sys/kernel/core_pattern</code> копируется в <code>/opt/dynatrace/oneagent/agent/conf/original_core_pattern</code>. При удалении ЕдиныйАгент деинсталлятор восстанавливает исходный шаблон ядра, присутствующий в этом файле, в <code>/proc/sys/kernel/core_pattern</code>.
* Содержимое <code>kernel.core_pattern</code>исходного параметра <code>/etc/sysctl.conf</code>копируется в <code>/opt/dynatrace/oneagent/agent/conf/original.sysctl.corepattern</code>. При удалении ЕдиныйАгент деинсталлятор восстанавливает исходный шаблон ядра, присутствующий в этом файле, <code>kernel.core_pattern</code>в <code>/etc/sysctl.conf</code>. Если <code>kernel.core_pattern</code>отсутствует в <code>/etc/sysctl.conf</code>до установки ЕдиногоАгента, <code>/opt/dynatrace/oneagent/agent/conf/original.sysctl.corepattern</code>файл не создается.
В зависимости от исходной записи в <code>core_pattern</code>Ключ-АСТРОМ запишет различные шаблоны в <code>core_pattern</code>. Возможные конфигурации и ожидаемые записи после установки перечислены ниже:
{| class="wikitable"
!Исходная запись 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
|Простой дамп ядра с параметрами в имени файла. Параметр <code>-kp</code>добавляется вместе со всеми параметрами ядра, необходимыми для замены Dynatrace в исходном имени файла.
|-
|/usr/share/apport/apport
|/opt/astromkey/oneagent/agent/rdp -p %p -e %e -s %s
|Дамп ядра следующее приложение без параметров. Аргумент <code>-a</code>не добавляется к выходной записи <code>core_pattern</code>, если нет параметров.
|-
|/usr/share/apport/apport %p %s %c %P
|/opt/astromkey/oneagent/agent/rdp -p %p -e %e -s %s -a %p %s %c %P
|Дамп ядра следующее приложение с параметрами. Аргумент <code>-a</code>добавляется вместе со всеми параметрами после двоичного пути к <code>apport</code>.
|}
=== Основная обработка ЕдиныйАгент dumpproc ===
Когда происходит сбой:
# <code>rdp</code>вызывается для сброса ядра в папки ЕдиногоАгента. Это ядро ​​используется функциональностью '''Crash Reporting'''.
# '''ЕдиныйАгент''' считывает <code>/opt/astromkey/oneagent/agent/conf/original_core_pattern</code>и генерирует ядро ​​в соответствии с настройками. Это означает, что если исходная настройка записывала файл ядра в определенное место, это все равно произойдет после установки ЕдиногоАгента.
# Анализируется дамп ядра, чтобы проверить, мог ли Ключ-АСТРОМ стать основной причиной сбоя.
#* Если ЕдиныйАгент определит, что Ключ-АСТРОМ мог быть причиной:
#** Создается оповещение службы поддержки. Об этом сообщается нашей команде DevOps.
#** Основной дамп архивируется и сохраняется в дополнение ко всем задействованным библиотекам. Это необходимо для последующего офлайн-анализа.
#* Если ЕдиныйАгент определит, что Ключ-АСТРОМ не является причиной:
#** Сообщения о сбое отправляются пользователю через веб-интерфейс Ключ-АСТРОМ.
#** Если это оказывает какое-либо влияние на приложение клиента, открывается проблема и генерируется соответствующее событие для задействованных процессов, как описано выше.
== Очистка ==
Каталоги журналов и оповещений службы поддержки очищаются автоматически.
* Для оповещений службы поддержки мы обрабатываем файл <code>core dump</code>, затем архивируем его и сохраняем для отправки в кластер.
* В случае сбоев (неинструментированных процессов или инструментированных процессов, когда мы решаем, что Ключ-АСТРОМ не виноват) мы обрабатываем, а затем удаляем копию файла <code>core dump</code>.

Версия 12:14, 1 августа 2024

Процессы аварийно завершаются по множеству причин, и часто бывает сложно понять основные причины, которые способствуют таким аварийным завершениям. Когда отслеживаемый процесс аварийно завершается, вы увидите запись о сбое процесса в разделе События каждого затронутого процесса и страницы Хосты. В примере процесса ниже есть некоторые проблемы с доступностью (показаны красным на временной шкале). При выборе затронутого временного интервала на временной шкале раздел События показывает количество аварийных завершений процесса, произошедших в течение этого временного интервала (в этом примере 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/dynatrace/oneagent/agent/conf/original_core_pattern. При удалении ЕдиныйАгент деинсталлятор восстанавливает исходный шаблон ядра, присутствующий в этом файле, в /proc/sys/kernel/core_pattern.
  • Содержимое kernel.core_patternисходного параметра /etc/sysctl.confкопируется в /opt/dynatrace/oneagent/agent/conf/original.sysctl.corepattern. При удалении ЕдиныйАгент деинсталлятор восстанавливает исходный шаблон ядра, присутствующий в этом файле, kernel.core_patternв /etc/sysctl.conf. Если kernel.core_patternотсутствует в /etc/sysctl.confдо установки ЕдиногоАгента, /opt/dynatrace/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добавляется вместе со всеми параметрами ядра, необходимыми для замены Dynatrace в исходном имени файла.
/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.