В HWall иерархию датчиков построили по образцу HWiNFO64 из Windows
В Linux появился HWall - открытый монитор "железа", написанный на Rust, который объединяет подробную инвентаризацию компонентов и живые показания датчиков в одном месте. Разработчики явно ориентировались на подход HWiNFO64: данные не свалены в набор разрозненных сводок, а разложены по понятной иерархии устройств и сенсоров, чтобы быстро находить нужный параметр - от температуры конкретного ядра до активности NVMe-накопителя.
Что именно показывает HWall
Приложение собирает сведения о процессорах, памяти, видеоустройствах, накопителях, сетевых интерфейсах, USB- и PCI-устройствах, батареях, прошивке, а также о поддерживаемых механизмах безопасности. Параллельно выводятся актуальные показатели датчиков: температуры CPU и материнской платы, обороты вентиляторов, напряжения, уровни загрузки, тактовые частоты, мощность, дисковая активность, сетевые скорости передачи.
Для каждого сенсора HWall хранит не только текущее значение, но и минимум/максимум/среднее, а также количество выполненных замеров. Отдельно отмечаются "проблемные" показания - устаревшие, недоступные или отключённые: по статусу видно, обновляется ли параметр прямо сейчас или перед вами последний успешно считанный результат.
Два интерфейса: GTK-приложение и терминальный монитор
У HWall два способа работы. Первый - графический интерфейс на GTK 4, где показатели и описание оборудования разнесены по разделам и подкатегориям, а оформление можно оставить системным или переключать между светлой и тёмной темой. Второй - интерактивный терминальный режим, полезный для серверов и удалённых сессий: там есть три представления (смешанное, "датчики" и "оборудование"), и переключаться между ними можно на лету, не выходя из программы.
При этом концепция у проекта принципиальная: HWall работает только на чтение. Здесь нет управления вентиляторами, разгона, изменения напряжений или частот - приложение лишь аккуратно собирает и отображает то, что уже отдают ядро Linux, прошивка, драйверы и несколько необязательных консольных утилит, используемых исключительно для чтения.
Эффективные частоты: расчёт через APERF/MPERF
На поддерживаемых системах x86 HWall вычисляет среднюю (эффективную) частоту процессора и частоты по логическим ядрам на основе счётчиков APERF и MPERF. Такой подход ближе к реальному поведению CPU, чем простая демонстрация "запрошенной" частоты: эффективная частота отражает, как процессор фактически работал на интервале измерений, а не то, что было выставлено политиками энергосбережения.
Мощность и энергосчётчики: powercap и perf
Показатели потребления процессора берутся из интерфейса powercap либо из энергетических счётчиков perf. В зависимости от платформы это может быть мощность пакета CPU, суммарный домен ядер, отдельные ядра, DRAM, встроенная графика и даже вся платформа целиком.
Важно, что на многих современных системах доступ к общесистемным счётчикам perf по умолчанию закрыт для обычного пользователя. Поэтому HWall проверяет домены по отдельности, а недоступные значения просто пропускает, чтобы не ломать общую картину. При необходимости доступ можно открыть, изменив параметр `perf_event_paranoid` (послабление стоит делать осознанно - он влияет на возможности сбора системных метрик).
История, графики и выгрузка
HWall ведёт историю показаний в оперативной памяти - объём буфера настраивается. Накопленные данные отображаются на интерактивных графиках: доступны подсказки при наведении, масштабирование, панорамирование, просмотр временных меток и выделение произвольного отрезка.
Экспорт предусмотрен в CSV и JSON Lines - удобно для последующего анализа, построения отчётов или сопоставления с событиями в системе. По умолчанию история хранится минуту, а верхний предел можно поднять до 24 часов. Разумеется, сочетание очень частого опроса и длинного хранения логично увеличит расход памяти и процессорного времени - это стоит учитывать при настройке.
Пороговые уведомления: предупреждения, критические значения и гистерезис
Для каждого датчика отдельно задаются два уровня - предупреждающий и критический. Уведомления можно "загрубить" настройками: указать, сколько времени параметр должен удерживаться выше порога, включить гистерезис и поставить паузу перед повторным срабатыванием. Это защищает от ситуации, когда кратковременный всплеск температуры превращается в нескончаемую очередь сообщений. Если значение действительно держится выше предела, HWall отправит уведомление на рабочий стол.
SMART и NVMe: здоровье накопителей
Помимо общего списка устройств, дополнительные интеграции добавляют информацию о состоянии дисков по SMART и данным NVMe: предупреждения, показатели здоровья и прочие диагностические параметры. Полнота информации при этом зависит от конкретного накопителя, драйвера и доступности соответствующих интерфейсов.
От чего зависит набор датчиков: роль hwmon и драйверов
В Linux набор доступных сенсоров во многом определяется подсистемой hwmon и тем, какие драйверы реально работают на вашей машине. Поэтому на разных ноутбуках и материнских платах список показаний может заметно отличаться: где-то будут доступны напряжения и обороты всех вентиляторов, а где-то - только температуры и базовая телеметрия CPU. HWall это не "исправляет", а честно отображает то, что система способна отдать.
Консольная утилита и HTTP-интерфейс
Проект включает консольную программу и HTTP-интерфейс, который возвращает данные в JSON. Такой вариант полезен, если нужно подключить HWall к собственным панелям мониторинга, собирать метрики скриптами или отдавать показатели на внутренние дашборды без использования графической оболочки.
Установка и форматы распространения
Кроме сборки из исходников, доступны готовые пакеты для Arch Linux, Debian и RPM-дистрибутивов, а также AppImage с графическим приложением. Это упрощает знакомство с проектом: можно выбрать формат, который лучше вписывается в конкретную систему и политику обновлений.
---
Дополнения по теме: как выжать из HWall максимум (и что учитывать)
1) Кому особенно пригодится HWall.
Он полезен не только энтузиастам, но и тем, кто ищет причину троттлинга, нестабильности, перегрева или внезапных просадок производительности. Когда в одном окне есть и "паспорт" железа, и живые графики, проще сопоставлять события: рост температуры → падение эффективной частоты → скачок потребления → реакция системы охлаждения.
2) Почему "только чтение" - это плюс.
Отсутствие функций управления снижает риск случайно "сломать" настройки, особенно на рабочих машинах. HWall выступает как диагностический прибор: наблюдает, фиксирует, предупреждает - но не вмешивается. Для администрирования это часто предпочтительнее универсальных комбайнов, которые умеют менять параметры системы.
3) Как настроить историю без лишней нагрузки.
Если нужен "черный ящик" на сутки, разумнее увеличить интервал опроса или ограничить набор отслеживаемых датчиков. Для диагностики редких проблем достаточно более редких замеров, зато запись будет длиннее и стабильнее по потреблению ресурсов.
4) Практика с порогами: начинать стоит с предупреждений.
Хорошая стратегия - сначала настроить предупреждающие пороги чуть ниже критичных, добавить задержку срабатывания и гистерезис. Так уведомления будут сигналом "обратить внимание", а не постоянным шумом. Критический порог имеет смысл делать действительно критическим - чтобы он срабатывал редко и по делу.
5) Что делать, если не показывается мощность или часть датчиков.
Чаще всего причина не в HWall, а в правах доступа или отсутствии нужных источников данных. Для энергометрик иногда требуется открыть доступ к perf-счётчикам через `perf_event_paranoid`, а для некоторых сенсоров - корректная загрузка драйверов hwmon. Итоговый набор показаний в Linux всегда зависит от связки "железо + ядро + драйвер".
6) Как использовать выгрузку CSV/JSON Lines с пользой.
Экспорт удобен для сравнения "до/после" (например, после чистки системы охлаждения или смены термопасты), для анализа поведения под нагрузкой и для фиксации кратких инцидентов. Даже простой график температуры и частоты в связке часто даёт ответ, почему система "тупит" в конкретные моменты.
7) Сценарий для серверов и headless-систем.
Терминальный режим и HTTP-интерфейс закрывают типичную потребность: мониторить состояние узла без графики. Можно смотреть показатели в консоли, а можно забирать JSON и строить собственные отчёты или уведомления в инфраструктуре - при этом сам HWall остаётся лёгким "сборщиком" и витриной данных.
8) Ограничения ранней стадии проекта - нормальная часть роста.
На старте неизбежны шероховатости: где-то не хватает датчиков, где-то отличается поведение на разных платформах, а часть метрик может быть недоступна из-за ограничений ядра или политики безопасности. Важно, что архитектура уже выглядит зрелой: есть и GUI, и TUI, и экспорт, и уведомления, и понятная модель данных.
В результате HWall воспринимается как попытка принести в Linux тот самый "структурный порядок" HWiNFO64: когда и инвентаризация, и телеметрия, и история с графиками находятся в одном инструменте - без лишнего вмешательства в систему, но с достаточной глубиной для диагностики.