Мониторинг ECC: проверка пути от ядра до оповещения

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

Выделенные серверы CloudSFP на AMD EPYC 7543P оснащены памятью DDR4-3200 ECC и доступны в двух вариантах: 128 ГБ и 256 ГБ. Ниже описана процедура проверки на примере Debian 12. Команды выполняются в операционной системе хоста, а не в гостевой системе. Набор доступных данных может различаться в зависимости от ядра и прошивки. Отсутствующие источники данных необходимо отмечать отдельно, а не считать признаком нулевого числа ошибок.

1. Разграничьте ошибки памяти и пробелы в мониторинге

Исправляемые ошибки обычно обозначаются как CE: это означает, что соответствующая ошибка была исправлена. Неисправляемые ошибки обычно обозначаются как UE: такую ошибку данный механизм коррекции устранить не может. Конкретные последствия также зависят от места возникновения ошибки, действий ядра и затронутого процесса. По одной лишь аббревиатуре нельзя делать вывод, что данные приложения гарантированно не пострадали.

При оценке CE важны прирост счётчика, повторение ошибок в одном месте и нагрузка в момент события. Единичный случай и регулярно повторяющиеся ошибки в одном месте требуют разного приоритета реагирования. При UE в первую очередь нужно защитить данные: проверить завершившиеся процессы, системные сбои и имеющиеся резервные копии, а также прекратить наращивание соответствующей нагрузки.

«Записей нет» — значимое наблюдение только после подтверждения работоспособности всей цепочки сбора. Пустой каталог EDAC, остановленная служба сбора и недоступная для чтения база событий — это пробелы в мониторинге, а не доказательство исправности.

ECC также не заменяет проверку целостности данных, избыточность хранения и резервное копирование. Чтобы связать неверные результаты приложения или повреждение файлов с ошибками памяти, нужны временная корреляция и подтверждения со стороны приложения. Устанавливать причинно-следственную связь напрямую нельзя.

2. Проверьте, какие источники данных действительно предоставляет ядро

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

uname -r
cat /proc/sys/kernel/random/boot_id
ls -ld /sys/devices/system/edac/mc
find /sys/devices/system/edac/mc -maxdepth 2 -type f \
  \( -name ce_count -o -name ue_count -o -name mc_name \) \
  -print -exec cat {} \;
sudo journalctl -k -b --no-pager \
  --grep='EDAC|MCE|Hardware Error|memory error'

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

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

Сообщения MCE или Hardware Error в журнале ядра тоже не обязательно указывают на неисправность памяти: событие может относиться к другому аппаратному узлу. Сохраняйте полный контекст. Одной строки со словом «error» недостаточно для классификации события.

3. Настройте запись rasdaemon и зафиксируйте исходные счётчики

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

sudo apt-get update
sudo apt-get install rasdaemon
sudo systemctl enable --now rasdaemon
systemctl status rasdaemon --no-pager
systemctl cat rasdaemon
ps -C rasdaemon -o pid,args
sudo ras-mc-ctl --status
sudo ras-mc-ctl --summary
sudo ras-mc-ctl --errors

Проверка --status — лишь часть процедуры, а не полное заключение об исправности. Также просмотрите журнал службы на предмет сбоев подписки на события, ошибок доступа и проблем с записью в базу данных.

sudo journalctl -u rasdaemon -b --no-pager

Работающий процесс ещё не означает сохранение событий на диск

Проверьте, включён ли в параметрах запуска -r или --record, и убедитесь, что установленный пакет поддерживает работу с базой данных. Если служба работает, но не сохраняет события, перезапуск процесса сбора может привести к потере части диагностических данных. Расположение базы определяйте по фактической конфигурации пакета, а не по пути, принятому в другом дистрибутиве.

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

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

4. Настройте оповещения так, чтобы они отражали риск, а не создавали поток сообщений

Рекомендуется разделить мониторинг на три категории: отказ цепочки сбора, новые CE и новые UE. К отказам цепочки относятся остановка службы, сбой чтения показаний и ошибка запроса к базе данных. Для них нужны отдельные оповещения: подменять ошибку нулевым значением нельзя.

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

Новые UE требуют повышенного приоритета. Сначала сохраните данные о состоянии в момент сбоя, затем проверьте целостность данных приложения. Не проводите стресс-тесты для дополнительного подтверждения неисправности и не перезагружайте машину только ради обнуления счётчиков.

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

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

5. Сохраните данные, необходимые для диагностики оборудования

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

Организуйте обращение в следующем порядке:

• Идентификатор машины, версии системы и ядра, идентификатор загрузки.
• Время первого обнаружения с явно указанным часовым поясом; продолжают ли появляться новые ошибки.
• Исходные события CE и UE, а также значения счётчиков до и после изменения — не только скриншот оповещения.
• Поля контроллера и местоположения из отчёта; отсутствующие поля отметьте явно.
• Симптомы со стороны приложения за тот же период, уже выполненные действия и их результаты.

Не пытайтесь самостоятельно преобразовывать метку DIMM или адрес из события в номер физического слота: соответствие может зависеть от платформы. Определение неисправного аппаратного узла поручите специалистам поддержки, которые сопоставят событие с данными о машине. Арендатор отвечает за защиту операционной системы, данных приложения и резервных копий.

Итог проверки — не скриншот, на котором «всё зелёное», а проверяемые исходные значения, явно определённый охват источников данных, протестированная цепочка оповещений и полный набор сведений о сбое. После обновления ядра или перезагрузки машины эти условия следует проверить заново, чтобы отказ сбора данных не был принят за исчезновение ошибок.

Часто задаваемые вопросы