Мониторинг железа выделенного сервера: SMART, температура и ошибки ECC

MAATRIX · Выделенные серверы · Статья 46 из 48

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

Мониторинг железа выделенного сервера нужен не для предсказания даты его смерти. Такого календаря нет даже у самых дорогих систем наблюдения. Его задача скромнее и полезнее: замечать ухудшение, сохранять историю и давать человеку время на действие. Иногда это время измеряется днями, иногда минутами. Иногда предупреждения не будет вовсе — поэтому рядом с мониторингом всегда живут резервные копии.

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

Начните с перечня доступных датчиков, а не с красивого дашборда

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

Например, у NECROPOLIS заявлены EPYC 7642, 128 ГБ DDR4 и два NVMe по 1 ТБ. У CARTOUCHE — два Xeon E5-2680 v4, 128 ГБ DDR4 и два SSD по 600 ГБ. Это полезная отправная точка для инвентаризации, но не готовый список метрик. Два диска также не означают, что между ними уже собран RAID.

После получения машины нужно сохранить модель и серийный номер каждого накопителя, версии прошивок, состав памяти, схему массива, названия сетевых интерфейсов. Серийный номер здесь важнее привычного имени /dev/sdb: после изменения конфигурации буквы могут поменяться, а обращение «замените второй диск слева» в удалённом дата-центре звучит не слишком убедительно.

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

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

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

SMART диска: читайте историю, а не одну зелёную строку

SMART и журналы состояния накопителей дают сведения об ошибках, температуре, наработке и других параметрах. Они не являются гарантией сохранности данных. Итоговый статус «passed» нельзя переводить как «диск точно переживёт следующий месяц»: часть отказов развивается быстро, а некоторые проблемы происходят вне самого носителя.

Для начала можно определить, какие устройства распознаёт установленная версия smartmontools:

sudo smartctl --scan

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

sudo smartctl -x /dev/nvme0

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

Дальше начинается содержательная работа. У SATA SSD и NVMe отличаются форматы и наборы показателей. Значения некоторых атрибутов зависят от производителя. Поэтому правило «любое большое число плохо» годится примерно так же, как диагностика автомобиля по количеству цифр на приборной панели.

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

Для NVMe есть и отдельная утилита nvme-cli. В актуальной документации семейства 3.x используется команда nvme log smart; в более старых установках привычно имя nvme smart-log. Синтаксис проверяют по установленной версии, а не по случайной шпаргалке. Документация nvme-cli описывает чтение соответствующего журнала.

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

Разбор конкретных атрибутов есть в материале о показателях SMART. В эксплуатационном регламенте важнее следующий шаг: какое изменение создаёт заявку, какие сведения прикладываются и можно ли продолжать нагрузку до ответа поддержки.

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

Температура: универсальных шестидесяти градусов не существует

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

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

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

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

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

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

ECC: исправленная ошибка тоже заслуживает внимания

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

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

Исправленная ошибка означает, что механизм защиты выполнил свою работу. Однако повторяющиеся события в одной области памяти или быстрый рост их количества требуют расследования. Нельзя бесконечно благодарить ECC за спасение и делать вид, что ничего не происходит. Как нельзя по одному событию без контекста уверенно назначать замену конкретной планки.

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

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

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

Собирать метрики должен сервер, а замечать его молчание — другая машина

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

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

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

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

Для каждой тревоги нужны получатель и ожидаемая реакция. «Посмотреть утром» допустимо не для каждого события. В то же время уведомления каждую минуту о незначительном колебании температуры быстро обучают людей главному навыку плохого мониторинга: перестать его читать.

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

Что отправлять провайдеру, когда график стал подозрительным

Хорошее обращение начинается с идентификатора сервера, времени и часового пояса. Затем идут симптом, изменение относительно обычного состояния и приложенные отчёты. Для накопителя — модель, серийный номер, SMART и связанные сообщения ядра. Для памяти — тип и повторяемость событий, обозначение модуля, если оно доступно. Для температуры — датчик, нагрузка и длительность отклонения.

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

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

Периодическая проверка SMART и температуры дополняет постоянный мониторинг: она помогает заметить забытые датчики, пересмотреть пороги и сверить оборудование после изменений. Но квартальный осмотр не заменяет уведомление о проблеме, возникшей сегодня ночью.

Хорошая система наблюдения не обещает бессмертия железа. Она делает его состояние понятнее, разговор с поддержкой предметнее, а решения — спокойнее. Для сервера, на котором работает бизнес, это уже очень много.

Все материалы о выделенных серверах