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


Небольшие по размеру фирмы с одной стороны, нуждаются в качественном мониторинге своей инфраструктуры (особенно в свете повсеместной виртуализации ), с другой стороны, для них финансово тяжело закупать новое оборудование. Также часто встречаются проблемы с серверной/аппаратной: зачастую стоит 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/

Комментарии (2)


  1. AlexGluck
    29.11.2019 13:37

    Прекрасная работа, спасибо.


  1. iig
    30.11.2019 20:15

    Как минимум для raspberry есть raspbian. sudo apt install zabbix-server решит проблему ;)
    Buildroot конечно сила, но для одной единственной программы собирать всю операционную систему — это как-то странно.
    И ещё есть легенда, которая гласит, что sd карта, на которую много пишут (мониторинг — тот самый кейс), долго не живёт. Подтверждается это?