47. Proxmox + Home Assistant. Мониторинг ресурсов сервера.

Одним из главных моментов поддержки сервера (да и вообще всей инфраструктуры в целом), кроме безопасности и резервного копирования является мониторинг ресурсов. Грамотный мониторинг позволяет избежать проблем не только с программной, но и с аппаратной частью. А использование его вместе с системой автоматизации, позволит выполнять и проактивные действия, направленные на упреждение возникающих проблем.
    Итак, у нас имеется в наличии мини-пк с установленной и работающей на нём операционной системой семейства Linux Debian. Эта система так же является гипервизором, а значит в ней могут быть запущены другие виртуальные машины  и контейнеры типа LXC. Говоря проще, у нас есть железка с Proxmox'ом, в котором крутится Home Assistant, в котором мы и будем мониторить состояние железки и ресурсов проксмокса.

Для начала стоит задаться вопросом: "А что именно я хочу мониторить?".

Имея ответ на этот вопрос можно определиться с набором инструментов и способов, которые будут использованы.

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

Приступим.

Мониторинг Home Assistant изнутри.

В нём есть много сенсоров, и они уже были перечислены здесь ранее.

В самом начале файла configuration.yaml есть блок с директориями и файлами шаблонов сенсоров и платформ. Добавим туда строку: .

sensor: !include_dir_merge_list includes/sensors

Теперь остаётся создать указанные директории (если они не были созданы ранее).

С помощью файлового редактора создадим в домашней папке config подпапку includes в которой создадим поддиректорию sensors. В ней создадим файл с названием, например, systemmonitor.yaml

и укажем содержимое этого файла:

  - platform: systemmonitor

    resources:

      - type: disk_use_percent

        arg: /config

      - type: disk_use

      - type: disk_free

      - type: memory_use_percent

      - type: memory_use

      - type: memory_free

      - type: swap_use_percent

      - type: swap_use

      - type: swap_free

      - type: processor_use

      - type: last_boot

После проверки конфигурации и перезагрузки эти сенсоры станут доступны. 

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

Для полноты картины можно создать так же сенсор отслеживающий размер файла базы данных. Однако, архитектура саго ХА такова, что для того чтобы сенсор получил доступ к файлу внутри системы, надо для этого открыть доступ к системным директориям. Поэтому в файле configuration.yaml указываем:

# Allow external dirs for DB size sensor

homeassistant:

  allowlist_external_dirs:

    - /config

и не забываем перезапустить систему.

Теперь можно воспользоваться встроенной интеграцией "Размер файла"

в которой нужно указать путь к файлу базы данных: /config/home-assistant_v2.db.

 

Так же можно воспользоваться переносом базы данных на полноценный и самостоятельный движок, например MariaDB. Установка и настройка которой рассматривалась в отдельной статье ранее.

После всех манипуляций можно выстроить отдельную панель (дашборд) с мониторингом системы. Один из вариантов в качестве примера:

Мониторинг Proxmox'а.

Встроенная интеграция.

Самым простым и очевидным шагом будет использование уже имеющихся инструментов. А именно использовать в Home Assistant интеграцию Proxmox VE. Подробная информация об её использовании и настройке есть на страничке на официальном сайте ХА ->  здесь.

Важно отметить, что данный способ позволяет видеть статус виртуалки или контейнера (вкл или выкл), но не более того. При том, что если была поднята новая система (машина/контейнер), то её номер необходимо добавить вручную в файл конфигурации. Так что этот способ применим для мониторинга статуса жив/не жив других систем работающих в том же(или другом) гипервизоре.

Сторонняя интеграция.

Теоретическая часть.

Операционная Система Proxmox позволяет пользователю как получать информацию о хосте, его ресурсах, и виртуалках с контейнерами, так и управлять этим.
Пользователь, с которым большинство новичков работают это root@pam. В чём его особенности?

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

Поэтому для задач мониторинга будет использоваться отдельный пользователь, обладающий правами "только для чтения" на всю систему, но при этом без возможности подключаться через консоль (@pve).
С одной стороны конечно не желательно раздавать его пароль налево и направо. С другой, возможности этого юзера ограничены системой, и навредить из под него физически невозможно.

 

Т.е. создание такого пользователя и назначение ему прав это единственная настройка, которая делается со стороны проксмокса.
Со стороны Home Assistant же ставится репозиторий интеграции через HACS, сама интеграция настраивается и на этом всё.

Практика.

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

 

 

Назначаем новому пользователю права доступа - аудитор на уровне всего хоста.

Что такое HACS и как его ставить уже было рассказано ранее. Открываем его, переходим в интеграции, справа вверху три точки - добавить репозиторий.
Добавляем https://github.com/dougiteixeira/proxmoxve и устанавливаем его же через поиск интеграций здесь же, не выходя из HACS.
По завершении установки рекомендуется проверить конфигурацию и перезагрузить систему.
После загрузки системы переходим в обычные настройки и интеграции, и в поиске выбираем Proxmox VE.

 

Осталось указать адрес нужного хоста, имя нового пользователя с паролем и сохранить настройки.

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

В итоге, после установки нас ожидает вот такой набор сенсоров для самого хоста (возможность управления отключена изначально):

 

И вот такой набор сенсоров на каждую виртуалку (новые будут появляться сами):

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

Glances - веб сервер и API.

Это программа, у которой есть одноимённая интеграция для Home Assistant.

Страничка проекта на GitHUB -> https://github.com/nicolargo/glances

По сути это очень лёгкий веб-сервер с одной стороны, и система сбора данных об оборудовании с другой.

Вот так выглядит оригинальная веб страничка монитора Glances

А вот такой набор сенсоров можно получить сразу "из коробки" используя соответствующую интеграцию в ХА.

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

Перейдём к установке.

В консоли проксмокса запускаем скрипт установки Glances:

curl -L https://bit.ly/glances | /bin/bash.

После установки убедимся что всё работает как надо запустив сам сервер и его веб интерфейс:

glances -w

Теперь можно зайти в браузере на следующий адрес: http://proxmox_ip:61208 и полюбоваться на страницу похожую на приведённую выше. Здесь же можно с ней и попрощаться, т.к. она будет отключена, для экономии ресурсов. А данные сервер всё равно продолжит передавать.

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

nano /etc/systemd/system/glances.service

Содержимое файла:

[Unit]

Description=Glances After=network.target [Service] ExecStart=/usr/local/bin/glances -w --disable-webui Restart=on-abort RemainAfterExit=yes [Install] WantedBy=multi-user.target systemctl enable --now glances.service

Нажимаем CTRL+X для выхода и Y для подтверждения сохранения изменений в файле.

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

systemctl enable glances.service

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

Created symlink /etc/systemd/system/multi-user.target.wants/glances.service → /etc/systemd/system/glances.service.

Осталось только запустить свежесозданный сервис, с помощью команды:

systemctl start glances.service

И на этом настройка серверной части будет завершена.

Настройка со стороны Home Assistant делается до неприличия просто.

Добавляем интеграцию Glances вручную, или с помощью соответствующей кнопки прямо отсюда:

И указываем необходимые данные:

• IP адрес проксмокса в домашней сети
• имя пользователя к нему
• его пароль
• порт самой службы
• версия API
• и отмечаем проверку и использование сертификатов, если таковые были установлены

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

Внимательный читатель мог заметить что эта интеграция не создаёт сенсора времени работы сервера (uptime). Эта проблема решается максимально просто.

Открываем документацию Glances и видим что такой параметр как аптайм всё же есть. Можно даже проверить что сервер проксмокса его выдаёт, зайдя браузером по адресу: http://proxmox_ip:61208/api/3/uptime (да, api работает при отключенном веб интерфейсе).

Для создания сенсора в Home Assistant, можно обратиться к его официальной документации.

По аналогии указанной выше, создадим ещё один файл в папке /includes/sensors и назовём его произвольным образом, например pveuptime.yaml.

Содержимое файла:

  - platform: rest

    resource: http://proxmox_ip:61208/api/3/uptime

    name: Proxmox uptime

    value_template: "{{ value_json }}"

Сохраняем, проверяем конфигурацию, перезапускаем систему.

После загрузки проверяем наличие нового объекта и его состояние.

Таким нехитрым образом можно настроить отслеживание использования ресурсов системы. Н у а уж как распоряжаться этими данными и какие автоматизации можно сделать на их основе - тема для отдельной статьи.