История на задачата
Небольшите фирми от една страна, се нуждаят от качествен мониторинг на своята инфраструктура (особено в контекста на всеобхватната виртуализация), от друга страна, финансово им е трудно да закупят ново оборудване. Често възникват и проблеми със сървърното/хардуерното: обикновено има 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 на платката, зареждач, генериране на образ с дял на системата) и максимално единство в донастройването на файловата система/създаването на образ с данни. Поради това подготвяне, портването премина бързо.
Настоятелно се препоръчва да прочетете въведителните статии:
Как да сглобим
След клонирането на репозитория получавате следната структура на файловете:
[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.shbuildroot-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
Изберете defconfig, натиснете A за прекратяване. По подразбиране [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 под Windows).
- qemu.qcow2 — образ на носителя за стартиране в qemu.
- external.qcow2 — образ на external-носителя за база данни
- monitor-0.9-beta.tar.gz — архив за актуализация чрез уеб интерфейс
Генериране на ръководства
Не е необходимо да пишете една и съща инструкция многократно. Логично е да напишете веднъж в 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.
При стартиране на системата и подготвяне на работата й в консолата се появява съобщение:
Системата стартира, моля изчакайтеСлед завършване на подготовката, то ще бъде заменено с показване на IP адреса:
текущ ip 192.168.1.32
Готов за работаНастройка на zabbix за мониторинг на температурата
За мониторинг на температурата са достатъчни само 2 стъпки:
- свържете устройството RODOS към USB порта
- създайте елемент данни в zabbix
Отваряме уеб-интерфейса на zabbix:
- Отваряме раздела Конфигурация → Хостове
- Щракваме върху Items в реда на нашия zabbix сървър
- Натискаме да създадем елемент
Въвеждаме следните данни:
- име — по ваше усмотрение (например, serverRoomTemp )
- Тип — zabbix агент
- Ключ — rodos
- Тип — числов
- Единици — C
- Период на съхранение на историята — срок за съхранение на историята. Оставих 10 дни
- Период на съхранение на тенденциите — срок на съхранение на динамиката на промените. Оставих 30 дни
- Ново приложение — server Room Temp
И натискаме бутона ДА.
Управление на настройките през уеб-интерфейса
Уеб-интерфейсът е написан на 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 показа правилността на този ход (след приключването на инсталацията системата не стартира). Може би правя нещо неправилно 😉
Източник: habr.com
