Для Linux вышел HWall – открытый монитор оборудования на Rust, в котором подробная опись аппаратной части соседствует с показаниями датчиков в реальном времени. Интерфейса два: графический на GTK 4 и интерактивный терминальный. Для каждого датчика ведётся история с интерактивными графиками, задаются пороги предупреждений, а накопленные данные выгружаются в CSV или JSON Lines. Помимо сборки из исходного кода опубликованы готовые пакеты для Arch Linux, Debian и дистрибутивов на базе RPM, а также AppImage с графическим приложением.
Иерархия датчиков по образцу HWiNFO64
Способ подачи данных в проекте объясняют влиянием HWiNFO64 – распространённой на Windows программы для сбора сведений об оборудовании и диагностики. Вместо набора сводных графиков в HWall сведены данные из ядра Linux, системной прошивки, драйверов оборудования и нескольких необязательных консольных программ, работающих только на чтение.
В списке показаний – температуры процессора и материнской платы, обороты вентиляторов, напряжения, уровни загрузки, тактовые частоты, активность накопителей, скорости передачи по сети и мощность. Для каждого датчика хранятся текущее, минимальное, максимальное и среднее значения плюс количество замеров.
Отдельно различаются устаревшие, недоступные и отключённые показания: по состоянию видно, продолжает ли значение обновляться или перед пользователем последний удачно собранный замер. В графическом приложении данные разложены по иерархическим разделам датчиков и оборудования, оформление берётся системное либо переключается на светлое и тёмное. У терминального монитора три режима – смешанный, датчики и оборудование, переключаются они на ходу, не выходя из программы.
Важная особенность самой концепции: программа работает только на чтение. Управления вентиляторами, изменения напряжений и тактовых частот, любой записи в оборудование здесь нет – только опознание и вывод того, что отдают операционная система и вспомогательные программы.
Эффективные частоты через счётчики APERF и MPERF
На поддерживаемых системах x86 средняя частота и частота каждого логического ядра вычисляются по счётчикам APERF и MPERF. Такая оценка ближе к реальной работе процессора, чем простой вывод запрошенных тактовых частот.
APERF и MPERF – счётчики в процессорах x86, по которым вычисляется эффективная частота, то есть средняя рабочая частота за интервал, а не запрошенная.
Мощность процессора берётся из интерфейса powercap или из энергетических счётчиков perf: пакет процессора, суммарный домен ядер, отдельные ядра, память DRAM, встроенная графика и платформа целиком. На многих современных системах доступ к общесистемным энергетическим счётчикам perf по умолчанию закрыт для обычных пользователей, поэтому каждый домен проверяется отдельно, а недоступные показания пропускаются. Открыть доступ до перезагрузки можно так:
sudo sysctl kernel.perf_event_paranoid=0
Нулевое значение разрешает локальным пользователям вести общесистемный сбор данных о производительности, поэтому в проекте советуют сначала свериться с описанием параметра perf_event_paranoid в документации ядра и идти на такое послабление осознанно.
История показаний, графики и выгрузка в CSV
История хранится в оперативной памяти, её объём настраивается. Накопленное показывается на интерактивных графиках: значения при наведении курсора, приближение и отдаление, панорамирование, просмотр меток времени, выбор произвольного отрезка. Собранное выгружается в CSV или JSON Lines для последующего анализа.
По умолчанию история держится минуту, общий предел поднимается до 24 часов. Сочетание очень короткого интервала опроса с длинным сроком хранения ожидаемо повышает расход процессорного времени и памяти.
Пороги, гистерезис и уведомления на рабочем столе
Для каждого датчика по отдельности задаются предупреждающий и критический пороги. У оповещения настраиваются длительность превышения, гистерезис и пауза перед повторным срабатыванием – всё это нужно, чтобы короткие всплески температуры или загрузки не превращались в поток уведомлений. Когда значение держится выше заданного предела, приходит уведомление на рабочий стол.
Опись оборудования, SMART и данные NVMe
Помимо живых датчиков ведётся опись процессоров, памяти, графических адаптеров, накопителей, сетевых интерфейсов, устройств USB и PCI, батарей, прошивки и поддерживаемых устройств безопасности. Необязательные интеграции добавляют сведения о здоровье накопителей по SMART и NVMe: предупреждения, счётчики наработки и прочие диагностические значения.
Часть данных появляется только при установленных вспомогательных программах. Их наличие определяется автоматически, а отсутствие любой из них не мешает запуску – пропадают лишь соответствующие сведения:
- lm-sensors – настроенные подписи датчиков, поправки под конкретную материнскую плату и более точное истолкование каналов hwmon; обычные датчики hwmon читаются напрямую из sysfs и без неё;
- hwdata – читаемые названия производителей и устройств PCI из локальной базы pci.ids;
- ethtool – сведения о сетевом драйвере и прошивке;
- smartmontools – подробные данные SMART о здоровье и наработке дисков SATA, SAS и родственных;
- nvme-cli – подробные предупреждения и счётчики наработки для накопителей NVMe;
- nvidia-smi – полная телеметрия видеокарт NVIDIA с проприетарными драйверами; название пакета зависит от дистрибутива и версии драйвера;
- dmidecode – подробности о материнской плате, прошивке, TPM, сокете процессора и модулях памяти; доступ может потребовать прав администратора, при их отсутствии этот шаг пропускается.
dmidecode используется только при первичном опознании оборудования, в обычном опросе датчиков он не участвует.
Драйверы hwmon, от которых зависит набор показаний
Напряжения, обороты вентиляторов и температуры материнской платы доступны только тогда, когда загружен подходящий драйвер hwmon. В HWall показания читаются из уже опубликованных файлов в /sys/class/hwmon, модули ядра при этом не загружаются и права администратора ради обычного наблюдения не запрашиваются.
hwmon – подсистема ядра Linux, через которую драйверы датчиков публикуют показания в файлах каталога /sys/class/hwmon, откуда их читают прикладные программы.
Набор каналов сильно зависит от материнской платы, микросхемы мониторинга, версии ядра и загруженного драйвера. Ниже приведены примеры распространённых драйверов, полным список не является.
| Драйвер | Типичное оборудование | Что обычно доступно |
|---|---|---|
| nct6775 | Современные микросхемы Super-I/O Nuvoton | напряжения, температуры, обороты вентиляторов, ШИМ |
| it87 | Микросхемы Super-I/O ITE | напряжения, температуры, обороты вентиляторов, ШИМ |
| asus-ec-sensors | Поддерживаемые платы ASUS | температуры платы, чипсета и VRM, дополнительные вентиляторы, часть показаний напряжения и тока |
| asus_wmi_sensors | Более старые платы ASUS | напряжения, температуры, вентиляторы, ток и разъёмы для водяного охлаждения |
| w83627ehf | Старые микросхемы Winbond и Nuvoton | напряжения, температуры, вентиляторы |
| f71882fg | Микросхемы Super-I/O Fintek | напряжения, температуры, вентиляторы |
Многие микросхемы мониторинга Nuvoton обслуживаются драйвером nct6775, загрузить его до перезагрузки можно так:
sudo modprobe nct6775
Консольная программа и HTTP-интерфейс с JSON
В комплекте идёт консольная программа: человекочитаемые отчёты, отбор датчиков по классу или типу, выгрузка в JSON и непрерывный поток JSON Lines. По команде serve поднимается небольшой HTTP-интерфейс, который отдаёт по настраиваемому локальному адресу последние показания датчиков, сводный снимок системы или опись оборудования; интервал обновления тоже настраивается.
Пакеты для Arch, Debian и RPM плюс AppImage
Готовые сборки на странице выпусков проекта опубликованы для 64-разрядных систем x86: пакет Arch Linux в формате pkg.tar.zst, пакет RPM для дистрибутивов соответствующего семейства, отдельные пакеты .deb для Debian 12 и Debian 13, а также AppImage с графическим приложением. Сборка из исходного кода по-прежнему возможна и требует Rust 1.92 или новее, файлов разработки GTK 4.8, pkg-config и обычного набора для сборки на C.
Чего не хватает на ранней стадии проекта
Проект находится на очень ранней стадии, и ограничения тут ожидаемы. Полнота опознания оборудования упирается в поддержку со стороны драйверов Linux, поведение прошивки, права доступа и набор установленных вспомогательных программ.
Автор проекта отдельно предостерегает от одновременного запуска нескольких низкоуровневых мониторов оборудования: у некоторых драйверов чтение выставленных ими файлов датчиков косвенно приводит к обращениям к прошивке или встроенным контроллерам. Подробное описание и исходный код выложены на странице проекта на GitHub.
Заключение
Связка из полной описи оборудования и подробной телеметрии с историей, порогами и выгрузкой на Linux до сих пор встречалась реже, чем на Windows. В HWall она собрана сразу в трёх видах: графическом, терминальном и программном через HTTP. Практическая отдача упирается в драйверы: на плате с загруженным nct6775 и установленными lm-sensors, smartmontools и nvme-cli картина получится подробной, на менее распространённом оборудовании – заметно беднее. Режим только на чтение снимает риск испортить настройки платы, но и управлять вентиляторами отсюда не выйдет.