Резервное копирование и анализ дампов сбоев Linux с помощью kdump

Что фиксирует kdump при сбое ядра

kdump готовит резервную копию образа памяти ядра Linux до того, как произойдет сбой. Для этого при запуске обычного ядра резервируется область памяти. В эту область записывается отдельный Ядро Capture загруженный, который при возникновении соответствующего события сбоя может быть запущен с помощью kexec.

Ядро Capture работает независимо от аварийно завершившего работу системного ядра и получает доступ к его образу памяти через /proc/vmcore. Он может записать этот образ в заданное место назначения. Созданный файл обычно называется vmcore; то, содержит ли он все исходные области памяти, зависит, в частности, от выбранных параметров фильтрации.

Задачи разделены: kdump фиксирует и сохраняет состояние, а программа авария затем анализирует имеющийся дамп. Это позволяет, например, изучить сообщения ядра и стеки задач. При этом дамп представляет собой моментальный снимок и не всегда автоматически предоставляет полную предысторию ошибки.

Ошибка ядра (Oops) не является синонимом паники ядра (Kernel Panic): Oops может возникнуть без немедленного перехода системы в состояние паники. Поэтому не каждое сбоя ядра приводит к созданию файла kdump. В то же время дамп памяти приложения (Core Dump) отражает состояние процесса и не является файлом vmcore ядра.

Эта подготовка имеет решающее значение для последующего анализа. Если на момент сбоя ядро Capture не было подготовлено или не был создан образ памяти, kdump не сможет впоследствии восстановить утраченное состояние памяти. В таком случае в качестве отправной точки останутся имеющиеся журналы и другие диагностические данные, сохранившиеся после перезапуска.

Предпосылки и ограничения сбора данных

Сначала уточните дистрибутив, версию и архитектуру сервера. От этого зависят названия пакетов, управление службами, конфигурация загрузки и поддерживаемые места хранения. Для настройки используйте документацию именно по этой платформе, а не комбинируйте команды из разных дистрибутивов; на требования также влияют аппаратное обеспечение и установленные драйверы.

Параметр загрузки crashkernel определяет Бронирование памяти для регистрации сбоев. Этот диапазон недоступен для обычного режима работы. Указание фиксированного значения не является надежным: ориентируйтесь на требования к распределению, архитектуре и конкретному оборудованию, а также учитывайте потребности системы сбора данных в памяти.

Одной только зарезервированной памяти недостаточно. Ядро Capture должно быть загружено и иметь возможность подключиться к настроенному целевому устройству. Для этого в его среде должны быть доступны необходимые драйверы и компоненты; в случае сетевого целевого устройства к необходимым условиям относятся также наличие подключения и доступность удаленного узла.

Запланируйте на целевом сервере достаточный объем ресурсов для ожидаемых образов и их хранения. Размер дампа зависит, в частности, от содержимого хранилища и настроек фильтрации. Переполненный или недоступный целевой сервер может помешать созданию резервной копии, даже если резервирование настроено правильно.

Даже заранее подготовленная установка не гарантирует получения пригодного для использования дампа. Ошибка «Oops» не всегда приводит к панике; при полном отключении питания ядро Capture перестает работать. Аналогичным образом, серьёзный аппаратный сбой может помешать его запуску или записи образа. Поэтому процесс сбора данных и конечный результат необходимо рассматривать отдельно от непосредственной причины сбоя.

Какие файлы учитываются при анализе

Для анализа важен не только файл дампа. По возможности сохраните также соответствующие файлы ядра и журналы, чтобы можно было сопоставить состояние системы на момент сбоя с сообщениями и изменениями. В приведённом ниже обзоре собственно образ памяти отделён от вспомогательных файлов, которые позволяют его проанализировать.

Это особенно важно подходящий файл vmlinux: Архитектура и точная сборка ядра должны соответствовать ядру, приведшему к сбою. Ядро, запущенное после перезагрузки, может быть другим. Вывод команды uname -r на вновь запущенном сервере этого недостаточно для выбора нужного файла старого дампа.

Кроме того, используйте версию crash, совместимую с ядром и форматом дампа. Если задействованы внешние или дополнительные драйверы, подготовьте также соответствующие файлы модулей и отладочную информацию. В случае отсутствия символов или отфильтрованных необходимых страниц памяти анализ может быть ограничен; такие пробелы должны быть отражены в документации по результатам анализа.

Файл vmcore может содержать конфиденциальную информацию из оперативной памяти. Поэтому ограничьте доступ к нему, обеспечьте защиту при передаче и установите сроки хранения и удаления. Прежде чем передавать дамп или дополнительные журналы в службу поддержки, уточните необходимые разрешения и допустимый объем информации.

Подготовка kdump на сервере

Отправной точкой являются дистрибутив, версия и архитектура сервера. Ознакомьтесь с документацией по ним, чтобы узнать, какие пакеты необходимы для kdump и загрузки ядра Capture, а также как настраивается эта служба. Инструкции для разных дистрибутивов не являются взаимозаменяемыми: названия пакетов, конфигурация загрузки и инструменты проверки могут различаться.

К подготовке относится подходящая Бронирование памяти через параметр загрузки crashkernel. Выберите размер и, при необходимости, дополнительные настройки в соответствии с требованиями конкретной платформы и аппаратного обеспечения. Зарезервированная память не будет доступна для нормально работающей системы; поэтому указание универсального размера будет столь же бесполезно, как и непроверенное копирование настроек с другого сервера.

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

cat /proc/cmdline

В RHEL 9 ты также можешь проверить статус с помощью следующей команды в командной строке. В других дистрибутивах используй способ проверки, описанный в соответствующей документации. Положительный результат Сообщение о состоянии является важным показателем готовности, но не заменяет контролируемого тестирования всего пути обеспечения безопасности.

kdumpctl status

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

Выбор цели резервного копирования и объема дампа

Das Цель обеспечения должно быть доступно во время сбора данных и иметь достаточно свободного места. Использование локального хранилища позволяет избежать зависимости от сетевого соединения, однако требует наличия доступного места на сервере. Также следует учитывать, что несколько сохраненных дампов и сопутствующих диагностических файлов могут занимать значительный объем места.

RHEL 9 документирует не только локальные цели, но и сетевые цели через NFS или SSH. Это позволяет хранить файл отдельно от соответствующего сервера; для этого необходимо, чтобы сеть, удалённый узел и необходимые компоненты в системе Capture работали исправно. Проверьте соответствующие ограничения конкретной конфигурации RHEL, а не приравнивайте доступность в обычном режиме работы к доступности в системе сбора данных.

С makedumpfile изображение можно сжать и отфильтровать по выбранным областям памяти. Фильтрация Это позволяет сэкономить место на диске и объем передаваемых данных, но при этом удаляются страницы, которые могут понадобиться при последующем анализе. Поэтому определяйте объем дампа исходя из предполагаемой диагностики и документируйте используемые фильтры; самый маленький файл не всегда является самым полезным.

Файл vmcore может содержать конфиденциальную информацию из оперативной памяти. Поэтому ограничьте доступ к нему, обеспечьте защиту при передаче и определите, как долго файлы будут храниться и когда их следует удалить. Перед передачей файла в службу поддержки необходимо получить соответствующее разрешение; это также относится к отдельно сохраненным копиям.

Открыть имеющийся файл vmcore с помощью команды crash

Для последующего анализа тебе понадобится имеющийся файл vmcore, соответствующий сбоевому сборке ядра и архитектуре vmlinux с отладочной информацией а также версию программы crash, совместимую с ядром и форматом дампа. Ядро, запущенное после перезагрузки, может быть другим; поэтому одно только указание его версии не позволяет достоверно идентифицировать сбойную сборку.

Следующая схематическая команда должна быть введена в обычном шелле на системе анализа. Замените оба пути на пути к реально существующим файлам. Эта команда открывает существующий образ для анализа; она не создаёт дамп и не запускает kdump.

crash /pfad/zum/passenden/vmlinux /pfad/zum/vmcore

После успешного старта ты будешь заниматься crash-Prompt, а не в обычном шелле. Там отображается log доступные сообщения ядра. Сначала обратите внимание на сообщение о панике и события, произошедшие в это время; сообщения могут служить отправной точкой, но не всегда отражают полную причину.

С bt ты анализируешь стек текущего контекста анализа; bt -a отображает стеки активных задач на процессорах. Сравните цепочки вызовов с сообщениями, а не рассматривайте отдельный фрейм как доказательство неисправности. В зависимости от состояния и объема дампа часть информации может отсутствовать.

В том же окне командной строки можно воспользоваться командой ps в обзоре задач; kmem -i предоставляет общую информацию о памяти. Сам по себе этот «снимок» не доказывает ни наличия утечки памяти, ни её причины. Если необходимо более тщательно проанализировать какой-либо из вовлечённых модулей, могут потребоваться соответствующие файлы модулей и отладочная информация.

Классификация стеков и указателей памяти

Если после смены драйвера возникает паника, сначала зафиксируй момент возникновения, версию ядра, приведшую к сбою, и задействованные модули. Сравните эти данные с журналом изменений: был ли обновлён только драйвер или одновременно установлено новое ядро? Таким образом вы сможете определить, какие изменения имеют значение для расследования.

Затем прочитай вместе с log доступные сообщения ядра и проанализируйте их с помощью команды bt стек текущего контекста анализа. bt -a дополняет представление об активных задачах процессоров. Помимо текста сообщения о сбое, запишите также сообщения, предшествовавшие сбою; они могут помочь понять контекст ошибки, которая проявится позже.

A Рамка драйвера Наличие ошибки в стеке — это отправная точка, но не доказательство вины. Например, повреждение памяти, произошедшее ранее, может проявиться только в функции драйвера. Поэтому, прежде чем считать какое-либо изменение причиной, проверь, согласуются ли сообщения, задействованные модули и ход событий.

При подозрении на хранение предоставляет kmem -i обзор информации о памяти, насколько это позволяют дамп и инструмент. Рассматривайте эти значения в совокупности с сообщениями ядра. Одно значение само по себе не свидетельствует ни о наличии утечки памяти, ни о её причине; кроме того, в результате фильтрации могут отсутствовать необходимые страницы памяти.

Чтобы ответить на вопрос, нарастает ли потребление с течением времени, тебе понадобятся дополнительные временные ряды. При отдельном анализе загрузки ЦП можно Профилирование ЦП с помощью инструмента Linux Perf помочь. Такие измерения дополняют дамп памяти, но не заменяют зафиксированное в нём состояние на момент сбоя.

Если нет пригодного для использования файла vmcore

После зависания и последующей перезагрузки сначала необходимо выяснить, произошла ли вообще ситуация «Panic» и был ли создан файл vmcore. Сама по себе перезагрузка не подтверждает ни того, ни другого. Поищите сообщения, соответствующие по времени, и проверьте настроенное место хранения, прежде чем делать выводы о конкретной ошибке на основании отсутствия файла.

Изучи Цепочка регистрации Отдельно: был ли для затронутого процесса загружен ядро с функцией захвата, и было ли данное событие подходящим для запуска kdump? Не каждое событие «Oops» приводит к панике. Кроме того, полная потеря питания или серьёзный аппаратный сбой могут помешать запуску ядра с функцией захвата или записи данных.

Затем проверьте целевой объект резервного копирования: был ли он доступен, было ли достаточно места и содержала ли система Capture необходимые драйверы и компоненты? В случае сетевого целевого объекта к этому добавляются зависимости, связанные с подключением и удаленным узлом. В RHEL файл kexec-dmesg.log Указать информацию о фазе сбора данных, если она была создана и сохранена.

При отсутствии пригодного для использования дампа важной альтернативой служат предыдущие журналы или сохраненные сообщения консоли и ядра. Однако эти источники не предоставляют полного образа памяти; утраченное состояние невозможно восстановить задним числом с помощью kdump.

Если сообщения или другие наблюдения указывают на проблемы в сети, можно провести дополнительную Анализ загрузки SoftIRQ в Linux помочь в определении характера обработки пакетов. Она отвечает на другой вопрос, чем проверка адреса назначения дампа, и сама по себе не свидетельствует ни о панике, ни о причине сбоя резервного копирования.

Проверить сбор данных и зафиксировать результаты

Выберите объем дампа с учётом предполагаемого диагностического вопроса и имеющихся ресурсов. Сжатие и фильтрация позволяют сэкономить место на диске и уменьшить объём передаваемых данных; однако удалённые страницы памяти больше не будут доступны для последующего изучения. Задокументируйте это решение, чтобы при анализе было понятно, какие данные, возможно, отсутствуют.

Файл vmcore может содержать конфиденциальные данные из памяти. Поэтому необходимо регулировать доступ к нему, обеспечивать защищённую передачу и определять срок хранения, а также порядок хранения соответствующих файлов отладки. Перед передачей данных в службу поддержки необходимо уточнить, требуется ли разрешение на их передачу и как предполагается обращаться с этими данными.

Повторно проверьте подготовку, если изменились ядро, драйверы, конфигурация загрузки или инфраструктура резервного копирования. Сюда входят загруженное ядро для захвата данных и доступность выбранного целевого устройства. Положительное сообщение о состоянии полезно, но само по себе не показывает, будет ли в текущих условиях действительно сгенерирован дамп, пригодный для анализа.

Предупреждение: Контролируемое сквозное тестирование намеренно вызывает сбой и может привести к перезапуску системы и потере данных. Проводите его только в разрешённой тестовой среде или в заранее запланированное окно технического обслуживания с резервным копированием данных. Заранее уточните круг ответственности, возможные последствия и порядок восстановления работы; команда запуска для этого намеренно не указана.

Показательный Сквозное тестирование Не ограничивайтесь проверкой статуса: убедитесь, что файл поступил в назначенное место назначения и открывается вместе с файлами, соответствующими зарегистрированной сборке. Затем при отладке сервера зафиксируйте выявленные проблемы, отсутствующие данные, неопределённости и следующие шаги проверки. При этом чётко разграничивайте наблюдаемые признаки и ещё неподтверждённые причины.