История задачи

Небольшие по размеру фирмы с одной стороны, нуждаются в качественном мониторинге своей инфраструктуры (особенно в свете повсеместной виртуализации ), с другой стороны, для них финансово тяжело закупать новое оборудование. Также часто встречаются проблемы с серверной/аппаратной: зачастую стоит 1-3 tower-сервера рядом с пользовательскими рабочими местами или в небольшой нише/чулане.

Проще использовать уже готовую сборку(дистрибутив), который достаточно залить на microSD-карту и вставить в распространенный одноплатный компьютер (beaglebone, семейства raspberry pi и orange pi, asus tinker board). Кроме того, такое оборудование стоит недорого и может быть установлено в любом месте.

Постановка задачи

Во многом проект развивался как некая лабораторная работа с возможность применения результатов.

В качестве системы мониторинга был выбран zabbix, тк это мощная, бесплатная и хорошо документированная система.

Остро встал вопрос с аппаратной платформой.Ставить отдельную машину под мониторинг тоже не очень хорошее решение — либо дорого закупать новое оборудование, либо искать старое + в небольших фирмах частые проблемы с серверной/аппаратной.

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

Шаги решения

Решено было изначально создать прошивку под x86_64 для запуска в qemu, поскольку это удобное и быстрое решение для отладки. После чего портировать на одноплатный компьютер arm (мне понравилась asus tinker board).

В качестве системы сборки был выбран buildroot. Изначально в нем отсутствует пакет zabbix, поэтому пришлось его портировать Были проблемы с русской локалью, которые решились наложением соответствующих патчей (примечание: в более новых версиях buildroot эти патчи уже не нужны).

Портирование самого пакета zabbix будет описано в отдельной статье.

Так как всё должно работать как прошивка (неизменяемый образ системы + восстанавливаемые файлы конфигураций/базы данных), то потребовалось написать свои systemd таргеты, сервисы и таймеры (target, service, timer).

Было принято решение о разбиении носителя на 2 раздела — раздел с файлами системы и раздел с изменяемыми конфигами и файлами базы данных zabbix.

Немного сложнее оказалось решение задач, связанных с базой данных. Размещать её прямо на носителе мало хотелось. В то же время, размер базы может достигнуть размера, превышающего размеры возможного ramdisk'а. Поэтому было выбрано компромиссное решение: база данных размещается на втором разделе sd-карточки(современные SLC-карточки имеют до 30 000 циклов записи), но есть настройка, позволяющая использовать внешний носитель (например, usb-hdd).

Мониторинг температуры был реализован через устройство RODOS-5. Конечно, можно использовать dallas 1820 напрямую, но быстрее и проще было воткнуть USB.

В качестве загрузчика для x86_64 был выбран grub2. Потребовалось написать минимальный конфиг для запуска.

После отладки на qemu было выполнено портирование на asus tinker board. В структуре моего оверлея изначально закладывалась кроссплатформаенность — выделение специфичных для каждой платы конфигов (defconfig платы, загрузчик, генерация образа с разделом системы) и максимальное однообразие в донастройке файловой системы/создание образа с данными. Ввиду такой подготовки портирование прошло быстро.

Настоятельно рекомендуется прочитать вводные статьи:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Как собрать

Проект хранится на github
После клонирования репозитория получается следующая структура файлов:

[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.sh

buildroot-2019.05.tar.gz — архив чистого buildroot
overlay — мой каталог с external-tree. Именно в нем хранится всё нужное, что бы собрать прошивку с помощью buildroot
README.md — описание проекта и руковдство на английском.
run_me.sh — скрипт, подгтовляивающий систему сборки. Разворачивает buildroot из архива, прикрепляет к нему overlay (через механизм external-tree) и позволяет выбрать целевую плату для сборки

[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Select defconfig, press A for abort. Default [0]

После этого достаточно перейти в каталог buildroot-2019.05 и выполнить команду make.
После завершения сборки все результаты сборки будут в каталоге output/images:

[alexey@comp buildroot-2019.05]$ ls -1 output/images/
boot.img
boot.vfat
bzImage
data
data.img
external.img
external.qcow2
grub-eltorito.img
grub.img
intel-ucode
monitor-0.9-beta.tar.gz
qemu.qcow2
rootfs.cpio
sdcard.img
sys
update

Нужные файлы:

• sdcard.img — образ носителя для записи на sd-карту (через dd или rufus под wibdows).
• qemu.qcow2 — образ носителя для запуска в qemu.
• external.qcow2 — образ external-носителя для базы данных
• monitor-0.9-beta.tar.gz — архив для обновления через web-интерфейс

Генерация руководств

Писать несколько раз одну и ту же инструкцию не стоит. И логичнее всего написать один раз в markdown, после чего конвертировать в PDF для скачивания и html для веб-интерфейса. Это возможно благодаря пакету pandoc.

Вместе с тем, генерировать все эти файлы нужно до того, как соберётся образ системы, те post-build скрипты уже бесполезны. Поэтому генерация выполнена в виде пакета manuals. Посмотреть можно в overlay/package/manuals.

Файл manuals.mk (который и выполняет всю работу)

################################################################################
#
# manuals
#
################################################################################

MANUALS_VERSION:= 1.0.0
MANUALS_SITE:= ${BR2_EXTERNAL_monitorOverlay_PATH}/package/manuals
MANUALS_SITE_METHOD:=local

define MANUALS_BUILD_CMDS
    pandoc -s -o ${TARGET_DIR}/var/www/manual_en.pdf ${BR2_EXTERNAL_monitorOverlay_PATH}/../README.md
    pandoc -f markdown -t html -o ${TARGET_DIR}/var/www/manual_en.html ${BR2_EXTERNAL_monitorOverlay_PATH}/../README.md
endef

$(eval $(generic-package))

systemd

Мир Linux активно переходит на systemd, пришлось это сделать и мне.
Из приятных новшеств — наличие таймеров. Вообще о них (и не только о них) пишется отдельная статья, но коротко расскажу.

Есть действия, которые надо выполнять периодически. Мне потребовалось запускать logrotate для очистки журналов lighttpd и php-fpm. Привычнее всего было бы написать команды в cron, но я решил использовать монотонный таймер systemd. Таким образом, logrotate запускается через строгий временной интервал.

Конечно, есть возможность создания таймеров, срабатывающих в определённые даты, но мне это не потребовалось.
Пример таймера:

• Файл таймера
  

  
  [Unit]
  Description=RODOS temp daemon timer

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

- Файл сервиса, вызываемого таймером:
```bash
[Unit]
Description=RODOS temp daemon

[Service]
ExecStart=/usr/bin/rodos.sh

Поддерживаемые платы

Asus tinker board — основная плата, на которой всё должно работать. Выбрана как недорогая и весьма мощная.

Beaglebone black — первая плата, на которой проверялась работа(в период подбора более мощной платы).

Qemu x86_64 — используется для разработки отладки.

Как работает

При старте происходит двухэтапное восстановление настроек:

• запуск скрипта settings_restore(через сервис). Он восстанавливает основные настройки системы — часовой пояс, локаль, настройки сети и тп.
• запуск скрипта prepare (через сервис) — здесь подготовливается zabbix, база данных, выводится IP в консоль.

При первом запуске происходит определение размера второго раздела sd-карты. В случае, если ещё есть не размеченное место — носитель переразбивается, раздел под данные занимает всё свободное место. Это сделано в целях уменьшения размера установочного образа(sdcard.img). Кроме того, в этот момент создается рабочий каталог postgresql. Именно поэтому первый запуск с новым носителем будет дольше последующих.

При подключении внешнего диска, в момент старта ищет свободный диск и форматирует его в ext4 с меткой external.

Внимание! При подключении внешнего диска( а так же отключении или его замене), необходимо сделать бэкап и восстановление настроек!

Для мониторинга температуры используется устройство RODOS 5. Производитель дает исходники своей утилиты для работы с устройством. При включении системы стартует таймер rodos, который запускает эту утилиту раз в минуту. Текущая температура записывается в файл /tmp/rodos_current_temp, после чего zabbix может мониторить этот файл как датчик.

Носитель для хранения конфигурации монтируется в каталог /data.

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

System starting, please wait

После завершения подготовительных работ, оно сменится на вывод IP-адреса:

current ip 192.168.1.32
Ready to work

Настройка zabbix для мониторинга температуры

Для мониторинга температуры достаточно сделать 2 шага:

• подключить устройство RODOS к usb-порту
• создать data item в zabbix

Открываем веб-интерфейс zabbix:

• Открываем раздел Configuration > Hosts
• Нажимаем на Items в строке нашего zabbix сервера
• Нажимаем на Create item

Вводим следующие данные:

• name — на ваше усмотрение (например, serverRoomTemp )
• Type — zabbix agent
• Key — rodos
• Type- numeric
• Units — C
• History storage period — срок хренения истории. оставил 10 дней
• Trend storage period — срок хранения динамики изменений. Оставил 30 дней
• New application — server Room Temp

И нажимаем кнопку ADD.

Управление настройками через веб-интерфейс

Веб-интерфейс написан на php. Есть основные функции:

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

Вход в веб-интерфейс закрыт паролем. Стартовая страница — руководство.

Адрес интерфейса zabbix: \${ip/dns}/zabbix
Адрес интерфейса управления: \${ip/dns}/manage

Запуск в qemu

qemu-system-x86_64 -smp 4 -m 4026M -enable-kvm -machine q35,accel=kvm -device intel-iommu -cpu host -net nic -net bridge,br=bridge0 -device virtio-scsi-pci,id=scsi0 -drive file=output/images/qemu.qcow2,format=qcow2,aio=threads -device virtio-scsi-pci,id=scsi0 -drive file=output/images/external.qcow2,format=qcow2,aio=threads

Эта команда запустит систему с 4 ядрами, 2048 RAM, активированным KVM, сетевой картой на мосту bridge0 и двумя дисками: для системы и external для postgresql.

Образы можно конвертировать и запускать в Virtualbox:

qemu-img convert -f qcow2  qemu.qcow2 -O vdi qcow2.vdi
qemu-img convert -f qcow2  external.qcow2 -O vdi external.vdi

После чего импортировать их в virtualbox и подключить по sata.

Заключение

В процессе мне стало интересно сделать готовый к работе продукт — с не очень красивым интерфейсом(не люблю их писать), но работающий и простой в настройке.

Последняя попытка установить zabbix-appliance в KVM показала правильность этого шага (после завершения инсталляции система не стартует). Возможно, я что-то делаю не так ;)

Материалы

https://buildroot.org/