Что такое SEL и почему это не логи операционной системы

System Event Log (SEL) — это журнал аппаратных событий, который ведёт сам BMC (Baseboard Management Controller), независимо от того, загружена ли операционная система, работает ли она вообще и была ли она переустановлена. По официальному описанию Supermicro, ресурс, отвечающий за такие журналы в Redfish, «represents system health event logs and maintenance event logs» — то есть это именно журнал состояния здоровья оборудования, а не системный лог приложений или ОС.

Практическое следствие этой независимости: если сервер внезапно перезагрузился, отключился по перегреву или потерял резервирование блока питания, а операционная система ничего внятного об этом не записала (или не успела записать перед сбоем), SEL часто остаётся единственным источником, который зафиксировал сам факт и точное время события на аппаратном уровне.

Redfish LogService: как устроена запись в SEL

В модели данных Redfish записи SEL структурированы, а не представляют собой произвольный текст. По официальному руководству Supermicro, запись содержит тип события («EntryType»: «SEL»), уровень серьёзности («Severity», например «Critical»), временную метку создания («Created»), а также сведения о конкретном датчике, зафиксировавшем событие («SensorType», «SensorNumber»). Пример записи из документации иллюстрирует это на конкретном событии: «Severity»: «Critical», «Message»: «[SEC-0000] General chassis intrusion» — то есть даже вскрытие корпуса сервера фиксируется как отдельная типизированная запись с явным уровнем критичности.

Такая структура — не просто формальность: именно она позволяет системам мониторинга автоматически фильтровать записи по критичности или типу датчика, а не вычитывать вручную произвольный текстовый лог.

Очистка журнала через Redfish: действие ClearLog

Официально Redfish предоставляет отдельное действие для очистки журнала — ClearLog. По документации Supermicro: «Use this API to delete all system health event log entries» — запрос выполняется методом POST на путь вида /redfish/v1/Systems/1/LogServices/Log1/Actions/LogService.ClearLog, и при успехе сервис возвращает HTTP 200. Отдельно документация Supermicro отмечает, что LogService поддерживает не только полную очистку, но и подтверждение (acknowledgement) отдельных событий через PATCH-операции, а также сброс отметок о подтверждении через специфичное для вендора действие SmcLogService.ClearAcknowledgements — то есть гранулярное управление журналом, а не только «всё или ничего».

Официальная документация не фиксирует единого общего для всех вендоров поведения при переполнении SEL (что произойдёт с новыми событиями, если журнал заполнен, зависит от конкретной реализации BMC) — это честно отмечено ниже как разрыв провенанса.

Как это выглядит на практике: SEL в Dell iDRAC

Официальная база знаний Dell описывает тот же принцип на уровне конкретного веб-интерфейса. Просмотр: «From the iDRAC web interface, go to Maintenance > System event log». Очистка: «To clear the logs, click Clear Log» — но здесь же документация Dell прямо предупреждает о двух важных ограничениях. Во-первых, право на это действие не универсально: «Clear Log only appears if you have the Clear Logs permission». Во-вторых — и это ключевая практическая деталь — само действие очистки не проходит бесследно: «After the SEL is cleared, an entry is logged in the Lifecycle Controller log. The log entry includes the username and the IP address from where the SEL was cleared» — то есть кто и откуда очистил журнал, фиксируется отдельно, в другом, более защищённом журнале.

Официальная документация Dell по факту описывает очистку SEL не как «удаление улик», а как операцию с явным аудиторским следом — что прямо противоречит распространённому неформальному представлению о том, что очистка лога «стирает историю» бесследно.

Что это значит для эксплуатации

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

Честная оговорка: ни один из двух источников этой статьи не описывает единое для всех вендоров поведение SEL при заполнении журнала (перезапись старых записей по кругу, блокировка новых событий или иной механизм) — это специфично для конкретной модели BMC и версии прошивки, и требует отдельной проверки по документации конкретного производителя, что честно отмечено как разрыв провенанса.

Частые вопросы