Просмотр кода страницы Анализ сбоев

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

[[Файл:as1.png]]

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

[[Файл:as2.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
 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)</code>

== Защитите конфиденциальные данные пользователей ==
Отчеты о сбоях могут содержать конфиденциальную личную информацию, которую не должны просматривать все пользователи. По этой причине ваш администратор Dynatrace должен включить параметр безопасности учетной записи « '''Просмотр журналов »''' и разрешения « '''Просмотр конфиденциальных данных запроса''' » в вашем профиле пользователя, прежде чем вы сможете просматривать личные данные. Этот параметр отключен по умолчанию для всех пользователей без прав администратора и должен быть явно включен, прежде чем вы сможете получить доступ к содержимому журнала.

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

[[Файл:as3.png]]

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

<code>[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting] "DontShowUI"=dword:00000001</code>

[[Файл:as4.png]]

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

== Обработка дампа ядра 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 ====
Службы ABRT (Red Hat) и Apport (Debian) остановлены и отключены.

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

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

* Содержимое исходного <code>/proc/sys/kernel/core_pattern</code>файла копируется в <code>/opt/astromkey/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/astromkey/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/opt/astromkey/oneagent/agent/conf/original.sysctl.corepattern</code>

В зависимости от исходной записи в <code>core_pattern</code>, Dynatrace будет записывать в <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>.
|}

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

# <code>rdp</code>вызывается для сброса ядра в папки ЕдиногоАгента Это ядро используется функцией отчетов о сбоях.
# ЕдиныйАгент считывает <code>/opt/Dynatrace/oneagent/agent/conf/original_core_pattern</code>и генерирует ядро в соответствии с установленными там настройками. Это означает, что если исходная установка записывала основной файл в определенное место, это все равно произойдет после установки ЕдиногоАгента .
# Дамп ядра анализируется, чтобы проверить, не могла ли Dynatrace быть основной причиной сбоя.
#* Если ЕдиныйАгент  определяет, что виновата Dynatrace:
#** Создается оповещение службы поддержки. Об этом сообщается нашей команде DevOps.
#** Дамп ядра заархивирован и сохраняется вместе со всеми задействованными библиотеками. Это необходимо для последующего автономного анализа.
#* Если ЕдиныйАгент определяет, что Dynatrace не виноват:
#** О сбое сообщается пользователю через веб-интерфейс Dynatrace.
#** Если это оказывает какое-либо влияние на приложение клиента, открывается проблема и генерируется соответствующее событие для задействованных процессов, как описано выше.

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

* Для предупреждений службы поддержки мы обрабатываем файл <code>core dump</code>, затем архивируем его и сохраняем для отправки в кластер.
* В случае сбоев (неинструментальных процессов или инструментальных, когда мы решаем, что Dynatrace не виновата), мы обрабатываем, а затем удаляем копию файла <code>core dump</code>.