Мониторинг температуры сервера linux

Как узнать температуру оборудования в Linux?

Трудно не согласиться с тем, что современное оборудование, не имеющее «на борту» температурные датчики может считаться «современным» и вообще полноценным. Ведь именно от температурных параметров зависит эффективная работа самого «железа». В Linux-системах существует масса свободных инструментов для доступа к температурным характеристикам работы оборудования и их мониторинга. О них более подробно и будет изложено в данной статье.

Зачем следить за температурой оборудования?

Обычных пользователей этот вопрос, конечно, может совсем и не волновать. За температурами следят администраторы, геймеры, тестеры и оверклокеры. Представитель из каждой из обозначенных категорий деятельности делает это в целях, непосредственно связанных с родом деятельности. Так, например, для администратора критически важно не допустить перегрева, иначе велик риск завалить систему. Для тестеров важно выявить стабильные характеристики режимов работы оборудования в различных режимах использования. В том числе и температурных. Практически во всех случаях, когда речь идёт о комнатном использовании оборудования, в частности, компьютерного железа, важно не допускать именно высоких температур. Ведь вся современная электроника построена на полупроводниках. Для которых «комфортным» для рабочих температур является диапазон от -40 до +60 градусов по Цельсию. По этой причине все геймеры и оверклокеры так стремятся оснастить свои системы максимально эффективными системами охлаждения. Подобный подход позволяет существенно компенсировать температурный нагрев в самых требовательных приложениях и играх. А также при разгоне тех же процессоров и графических чипов.

Утилиты в Linux для доступа к температурным датчикам

В настоящее время среди всего разнообразия, для Linux существует лишь одна по-настоящему универсальная и свободная утилита, предоставляющая доступ к целому комплексу доступных в системе датчиков. И не только температурных. Это Lm-sensors. Кроме неё также полезно использовать HDDTemp и Udisks2. Которые, как понятно из названий, работают с накопителями — HDD и/или SSD. Эти утилиты дополняют функционал Lm-sensors, предоставляя доступ к температурам накопителей. С чем сама Lm-sensors справляется плохо.

Lm-Sensors

Хотя Lm-sensors и не может полноценно читать информацию о температуре накопителей, но всё же обладает довольно мощными возможностями. Она позволяет также узнать данные о частоте вращения установленных в системе вентиляторов. При этом доступ возможен в том числе и к датчикам на периферийных устройствах. А не только на основной (материнской) плате.

Эта утилита обновляется разработчиками не так часто, но всё-таки ещё поддерживается. Далеко не всегда можно поспеть за самыми новыми веяниями в сфере компьютерного «железа», получить доступ к его спецификации, разработать и протестировать соответствующие обновления. Однако, даже в таких условиях Lm-sensors позволяет получить данные о температурах всех критически важных компонентах системы. Таких как CPU, GPU и основных параметрах чипсета.

Lm-sensors доступна практически в любом дистрибутиве Linux в стандартном репозитории. Обычно соответствующий пакет называется lm-sensors. Для его установки, например, в системах Ubuntu следует выполнить команду:

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

Дальше необходимо на все выдаваемые запросы отвечать утвердительно, т. е. «yes». Поскольку в этом случае сканирование будет полноценным. Следует отметить одну важную деталь: иногда запросы предлагают разное написание ответов, это может быть «yes», «YES» или даже «Yes». Вводить ответ нужно в точности как он предложен в конкретном запросе — это влияет на результат сканирования. В завершении утилита предложит установить модуль ядра, содержащий оптимальный драйвер для считывания показаний датчиков для конкретной системы:

В данном случае, как можно видеть, lm-sensors в качестве оптимального драйвера определила «nct7802». Также приведены инструкции для ручного добавления модуля этого драйвера в сценарий загрузки ядром. Вместе с тем также возможна автоматическая правка файла /etc/modules. Что более предпочтительнее и рекомендуется поступать именно таким образом. Далее необходимо перезагрузить систему и далее, выполнив следующую команду, убедиться, что модуль «nct7802» загружен:

Данный вывод говорит о том, что модуль загружен. Теперь, для просмотра значений всех доступных для утилиты lm-sensors (тех, что она смогла обнаружить ранее при сканировании) достаточно выполнить команду:

Как видно, набор обнаруженных датчиков довольно внушительный. Есть даже показания температуры для модуля Wi-Fi. Не хватает, правда, значений оборотов охлаждающего вентилятора процессора и значений температур зон VRM. Но это уже издержки свободного ПО.

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

Здесь ключ -n задаёт периодичность обновления вывода, в данном случае это 3 секунды. Если он не задан, то по-умолчанию обновление будет происходить каждые 2 секунды. Для выхода из непрерывного режима нужно нажать сочетание клавиш .

HDDTemp

Для мониторинга температур устройств хранения. Например жестких дисков и/или твердотельных накопителей удобно использовать утилиту hddtemp. Соответствующий пакет «hddtemp» также доступен для большинства Linux-дистрибутивов. Для доступа к показаниям температуры конкретного устройства нужно выполнить команду:

Здесь, как можно догадаться, в качестве параметра передаётся интересующее устройство. В данном случае это /dev/sdb.
Для того, чтобы данные получаемые утилитой hddtemp могли использовать другие программы мониторинга (например psensor), необходимо запустить hddtemp в качестве демона:

Это команду необходимо выполнить для всех устройств, для которых необходимо мониторить значения температур.

Psensor – GUI-мониторинг температур в Linux

После того, как установлены и настроены все основные инструменты для мониторинга температур. Такие как lm-sensors и hddtemp, можно (и даже нужно) для удобства вывести это в одном приложении с использованием графиков и лог-файлов. Для этого предназначена очень популярная в среде Linux утилита psensor. Она обладает графическим пользовательским интерфейсом и способна агрегировать данные от всех самых популярных утилит-провайдеров всевозможных системных параметров, таких как температуры, обороты вентиляторов, объём RAM и т. д. Пакет для установки также доступен практически в каждом дистрибутиве Linux и обычно называется «psensor».
Psensor умеет довольно гибко управлять настройкой и отображением значений датчиков. Разобраться в пользовательском интерфейсе не составляет особого труда, он довольно прост:

Рис. 1: Графическая утилита psensor — мониторинг температур, оборотов вентиляторов и других системных параметров в Linux .

При запуске psensor обычно располагается в системном трее в виде значка термометра. Вызов главного окна psensor осуществляется из контекстного меню значка.

Заключение

В заключение стоит напомнить, что утилиты lm-sensors и hddtemp на сегодняшний день являются основными и самыми универсальными инструментами для мониторинга системных параметров в Linux. Эти утилиты консольные и являются поставщиками данных для инструментов с графическим интерфейсом: виджеты рабочего стола, сторонние утилиты-агрегаторы, такие как psensor. Ещё одним очень мощным агрегатором является Сonky. Но это куда более сложный в настройке инструмент, заслуживающий отдельного рассмотрения.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Как посмотреть температуру Linux и мониторить ее

Часто ли вам приходится беспокоиться и температуре компьютера? Наверняка, нет, если машина исправна и работает без перебоев. Температура не подымится выше максимального значения, установленного производителем, если в нем отсутствуют заводские дефекты. Однако, все же, перегрев может произойти, не только по причине аппаратной проблемы, но и в результате сбоя в драйвере графической карты или неправильно настроенной программы управления системой охлаждения. Нередко причина перегрева кроется в скоплениях пыли и грязи, которая препятствует нормальному охлаждению системы и отводу тепла. Такое обычно можно наблюдать на старых машинах.

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

Что необходимо

Итак, для выполнения поставленной задачи понадобятся следующие штатные инструменты:

1. lm-sensors – извлекает данные из аппаратных датчиков на материнской плате для мониторинга температуры, напряжения.
2. hddtemp – измеряет температуру жестких дисков.
3. psensor – графическая утилита для мониторинга температуры, которая позволяет посмотреть температуру Linux, для процессора, видеокарты, жестких дисков.

Дальнейшая наша задача – выполнить установку компонентов.

Устанавливаем компоненты

Поскольку lm-sensors работает на основании информации, предоставляемой lm-sensors и hddtemp, то в первую очередь необходима установка именно этих компонентов. Для этого выполняем такую команду:

$ sudo apt install lm-sensors hddtemp psensor

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

sudo apt update

sudo apt install lm-sensors hddtemp psensor

То есть, необходимо добавить PPA от разработчиков в систему.

Установка psensor в Fedora и других дистрибутивах, основанных на Red Hat, выглядит примерно так же:

$ sudo yum install lm_sensors hddtemp psensor

Настраиваем мониторинг температур

В первую очередь настраиваем низкоуровневые инструменты, предназначенные для считывания информации, к тому числу относятся lm_sensors и hddtemp. Установив их, можно обеспечить систему мониторингом температуры:

Этой командой запускается мастер настройки ls_sensors. На все вопросы пользователь должен отвечать Y. Дальше она обнаружит в системе встроенные аппаратные датчики, а также автоматически определит подходящие драйвера.

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

В Ubuntu или Debian модули будут добавлены в /etc/modeuls. Для автоматической загрузки нужных модулей достаточно добавить lm_sensors в автозагрузку:

$ sudo systemctl enable lm-sensors

Дальше мы можем посмотреть температуру процессора и других аппаратных компонентов при помощи следующей команды:

Настраиваем DDTEMP

Для запуска мониторинга температуры жестких дисков необходимо запустить hddtemp в качестве демона, /dev/sda замените на адрес своего диска:

Повторите эту операцию для каждого системного диска. Еще один важный нюанс – программу следует добавить в список автозагрузки.

Измерение и мониторинг температур

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

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

Для установки тревоги для определенного датчика перейдите на вкладку Alarm. По умолчанию температура в psensor измеряется в градусах Цельсия. В последних версиях также есть поддержка конвертации в градусы по Фаренгейту.

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

Источник

Мониторинг показателей linux сервера в Home Assistant через mqtt

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

Вводные: мониторить будем загрузку и температуру процессора, загрузку оперативной памяти и свопа, свободное место на дисках, продолжительность аптайма, общую загрузку системы, температуру и состояние smart дисков по отдельности, и состояние raid (на сервере с ubuntu server 20 поднят простой софтовый raid1). Диски WD Green, материнская плата GA-525 со встроенным atom525.

На сервере умного дома уже поднят брокер mosquitto, поэтому в качестве метода передачи данных выбран mqtt.

В первых разделах сего труда приведены принципы примененных методов сбора данных, а в конце — скрипты передачи данных и настройки HA.

Все команды в примерах выполняются от пользователя root

Оглавление

Показания системных датчиков

Для получения встроенных датчиков воспользуемся утилитой sensors

Если она не установлена, поставим ее: apt-get install lm-sensors

Сначала надо найти все имеющиеся датчики. Запускаем команду sensors-detect
и отвечаем y на все вопросы. После этого можно поглядеть что получилось: sensors

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

Надо бы как то формализовать вывод. К счастью у sensors есть удобный режим вывода в json, и можно скрыть название адаптора. sensors -A -u -j выдаст длинный json. Вот мой, например.

Ну вот, с этим работать удобнее. Для передачи показаний дальше надо разобрать данные. Для разбора json прямо в консоли есть шикарнейшая утилита — jp. Если она не установлена — для ubuntu она есть в пакетах:

apt-get install jq

Определяем xpath нужного параметра. Можно глазами, можно с помощью например этого удобного онлайн-инструмента.

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

sensors -A -u -j | jq ‘.[«coretemp-isa-0000»][«Core 0»].temp2_input’
sensors -A -u -j | jq ‘.[«it8720-isa-0290»].fan1.fan1_input’
sensors -A -u -j | jq ‘.[«it8720-isa-0290»].temp3.temp3_input’

Нагруженность системы

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

Утилизация памяти. Самый простой способ по моему — воспользоваться командой free. Чтобы не ломать глаза, есть параметр -m, выводящий все значения в мегабайтах.

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

free -m | grep «Mem» | awk ‘‘

Соответственно в параметр grep отдаем название строки, а в параметр awk — номер столбца, в результате получаем готовую цифру. Дальше по аналогии можно получить остальные данные, а процент вычислить по формуле. В разделе передача данных в скрипте можно найти алгоритм расчета.

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

df | grep «/dev/md127p1» | awk ‘‘ | sed ‘s/%$//’
df | grep «/dev/md126p1» | awk ‘‘ | sed ‘s/%$//’

Суммированную загрузку системы можно получить в файле /proc/loadavg. Надо понимать, что цифры там — показатель, измеренный в попугаях. Первые три строки означают среднее количество процессов или потоков, которые выполняются, находятся в очереди на выполнение или ждут завершения операций ввода/вывода за 1, 5 и 15 минут. То есть это не процент и не доля от целого. Просто если это значение представить в виде числа, то большое (больше единицы) число там это плохо, п’нятненько? Я буду брать за 15 минут:

cat /proc/loadavg | awk ‘‘

Аптайм нам даст команда uptime:

Ну и наконец загрузку процессора возьмем у программы mpstat. Я использую именно эту программу, потому что она по умолчанию суммирует ядра, кроме того выдает информацию и тут же заканчивает свой процесс. Тут тоже потребуются арифметические вычисления, потому что все распространенные утилиты отдельно считают задачи пользователя и системы, но зато суммируют время простоя. Таким образом, если мы хотим получить просто цифру загруженности, то надо или из единицы вычесть простой, или сложить все направления. Если mpstat у вас не установлена, то это можно сделать командой apt install sysstat. Итак,

mpstat | grep all | awk ‘‘

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

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

cpuidle=$(mpstat | grep all | awk ‘‘)
cpuload=$(echo «100-$cpuidle» | bc -l)
echo «Текущая загрузка процессора: $cpuload»

Показания состояния жестких дисков

Для получения температуры дисков воспользуемся утилитой hddtemp. Если ее нет, ставим:

apt-get install hddtemp

Работать вообще просто: для получения температуры ей указывается устройство, и с параметром -n не будет лишних данных:

Для получения данных со SMART воспользуемся smartmontools

apt-get install smartmontools

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

smartctl -a /dev/sda

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

Raw_Read_Error_Rate — количество ошибок чтения. Ненулевые значения уже требуют внимания, а большие говорят о скором выходе диска из строя. В интернетах пишут, что у некоторых моделей большое значение в этом поле является нормальным. В общем случае значение должно быть равно нулю. А поскольку мы все таки мониторим, нас будет волновать увеличение этого числа;

Reallocated_Sector_Ct — количество перераспределённых секторов. Большое значение говорит о большом количестве ошибок диска;

Seek_Error_Rate — количество ошибок позиционирования. Большое значение говорит о плохом состоянии диска;

Spin_Retry_Count — количество попыток повторной раскрутки. Большое значение говорит о плохом состоянии диска;

Reallocated_Event_Count — количество операций перераспределения секторов;

Offline_Uncorrectable — количество неисправных секторов. Большое значение говорит о повреждённой поверхности.

Чтобы их вытащить из ответа утилиты, можно воспользоваться удобной функцией — вывод значений в формате json. Для этого к строке запуска добавляем параметр -j, вот так:

smartctl -a -j /dev/sda

В ответ получим длинный json, для удобства анализа сохраняем в файл. Вот мой. Ваш, скорее всего будет несколько иным. В этом внушительном файле надо глазами или иным образом получить json xpath к интересующим параметрам.

Получив xpath, выделяем конкретную цифру с помощью той же утилиты jq, вот так (в конце в комментарии имя параметра):

smartctl -a /dev/sda -j | jq ‘.ata_smart_attributes.table[0].raw.value’ #Raw_Read_Error_Rate
smartctl -a /dev/sda -j | jq ‘.ata_smart_attributes.table[3].raw.value’ #Reallocated_Sector_Ct
smartctl -a /dev/sda -j | jq ‘.ata_smart_attributes.table[4].raw.value’ #Seek_Error_Rate
smartctl -a /dev/sda -j | jq ‘.ata_smart_attributes.table[6].raw.value’ #Spin_Retry_Count
smartctl -a /dev/sda -j | jq ‘.ata_smart_attributes.table[12].raw.value’ #Reallocated_Event_Count
smartctl -a /dev/sda -j | jq ‘.ata_smart_attributes.table[14].raw.value’ #Offline_Uncorrectable

Кроме того, есть такой ответ на вопрос типа «ты нормально скажи — здоров ты или нет» — запустив утилиту с параметром -H, можно получить суммарный вывод о здоровье диска. У режима тоже есть параметр -j, выводящий структурированный json.

Также выделям его из json:

smartctl -a /dev/sda -j | jq ‘.smart_status.passed’ #smart_status

Не забываем о необходимости вовремя тестировать диск, само себя оно не протестирует (наверное)

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

smartctl -t short /dev/sda

быстрое тестирование, занимает около 2 минут

smartctl -t long /dev/sda

расширенный тест, занимает около 1 часа.

Если этот вариант не нравится, у программы есть режим демона, smartd, который сам будет запускать тестирование, и может даже слать отчеты. Отчетов нам не нужно, а вот автотестирование пригодится. Настройку smartd легко нагуглить.

Показания состояния RAID

На контролируемом сервере поднят просто raid на mdadm. На разделах дисков создано два массива, для системы и для /var. Рассматривается мониторинг именно такой конфигурации, для иной конфигурации на mdadm можно адаптировать, а про аппаратный raid ничего не знаю.

Самый простой способ узнавать что происходит, что я нашел — это брать уже готовые данные в виртуальной файловой системе sys. [1] [2]

Тут есть определённая проблема — я не нашел способа проверить работоспособность этого метода. Буду исходить из мысли что все хорошо.

Итак, получаем названия разделов cat /proc/mdstat

Вижу что-то такое:

Сначала надо вызвать проверку

echo ‘check’ >/sys/block/md126/md/sync_action
echo ‘check’ >/sys/block/md127/md/sync_action

А потом просто взять готовое

cat /sys/block/md126/md/mismatch_cnt
cat /sys/block/md127/md/mismatch_cnt

если команды возвращают 0, то все ок.

Команды запуска проверки запускаем из крона периодически, иначе данные будут неактуальны.

Сбор и передача данных

Если на сервере не установлен клиент mosquitto, то ставим его:

apt-get install mosquitto-clients

Создаем где-нибудь скрипты, куда сведем все команды сбора и публикации. Я разделил все операции на три группы — частые (показатели системы), средние (состяние raid и свободного места), и редкие (данные smart):

touch system.sh && touch drives.sh && touch smart.sh
chmod u+x system.sh && chmod u+x drives.sh && chmod u+x smart.sh

В созданные файлы пишем:

Запускаем, убеждаемся что в логах Mosquitto broker в Home Assistant светятся обращения

Если не светятся, то или неверно заданы параметры подключения, или брокер закрыт для обращения извне, или не знаю.

Настройка в Home Assistant

Ну, почти все. Осталось в конфиге Home Assistant добавить датчики.

Длинный кусок конфига

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

Убедившись что все работает, добавляем скрипты в крон. Системные показатели я передаю раз в полчаса, состояние дисков раз в час, а состояние smart раз в сутки.

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

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

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

На скриншоте видно, что обсуждаемый сервер запланирован под nextcloud. Его внутренние показатели тоже можно прекрасно добавить в HA, для этого там есть чудесный api. А у HA есть встроенная интеграция.

Upd1: В комментариях посоветовали утилиту Glances, имеющую встроенную интеграцию с Home Assistant. Из плюсов — готовый работающий вариант. Из минусов — открытый веб-интерфейс на сервере, если это имеет для вас значение.

Умеет собирать значительную часть системной информации из этой статьи

For each detected disk (or mount point) the following sensors will be created:

disk_use_percent: The used disk space in percent.

disk_use: The used disk space.

disk_free: The free disk space.

memory_use_percent: The used memory in percent.

memory_use: The used memory.

memory_free: The free memory.

swap_use_percent: The used swap space in percent.

swap_use: The used swap space.

swap_free: The free swap space.

processor_load: The load.

process_running: The number of running processes.

process_total: The total number of processes.

process_thread: The number of threads.

process_sleeping: The number of sleeping processes.

cpu_use_percent: The used CPU in percent.

sensor_temp: A temperature sensor for each device that provides temperature (depends on platform).

docker_active: The count of active Docker containers.

docker_cpu_use: The total CPU usage in percent of Docker containers.

docker_memory_use: The total memory used by Docker containers.

Upd2: Если речь идет о сервере именно для Nextcloud, то действительно есть встроенная интеграция, которая умеет собирать много информации. Кроме данных о состоянии системы nextcloud, также немного системных данных, таких как объем занятой и всего памяти, свопа, статистическую загрузку из файла /proc/loadavg.

Upd3: Установка и использование Glances

Утилита работает на python, так что он должен быть установлен.
Запускаем установку
pip install glances
или
wget -O- https://bit.ly/glances | /bin/bash
или
apt-get install glances

Все три способа равнозначны, но в последнем еще и зависимости подтянутся. При выборе второго способа рекомендую убедиться что за сокращателем ссылок по прежнему скрипт установки.
После установки запускаем веб-сервер:
glances -w
Теперь если открыть http://ip:61208/ то увидете в браузере все что собирает утилита.

Ну а теперь нужно подключить интеграцию — в HA добавляете новую интеграцию, ищете в списке Glances, в открывшемся окне вводите адрес сервера, порт (по умолчанию 61208), логин/пароль, и готово.

Если результат вас устраивает, то нужно настроить автозапуск веб-сервера, вот инструкция от автора программы.

Лично мне не понравилось. Во первых — утилита сама по себе добавляет немалую загрузку системе. На двухядерном атоме, который является подопытным в этой статье, это до 20% само по себе. Во вторых — лишние зависимости.
Но, если питон используется для чего то еще, зависимости это не проблема, а достаточно мощный сервер такую нагрузку даже не заметит. Кроме того утилита кроссплатформенная, и тот же подход можно использовать для мониторинга и других систем.

Источник