История на проблема
Малките компании, от една страна, се нуждаят от висококачествен мониторинг на своята инфраструктура (особено в светлината на широко разпространената виртуализация), от друга страна, за тях е финансово трудно да закупят ново оборудване. Проблемите със сървъра/хардуера също са често срещани: често има 1-3 сървъра тип кула до потребителски работни станции или в малка ниша/килер.
По-лесно е да използвате готов монтаж (дистрибуция), който просто трябва да качите на microSD карта и да поставите в обикновен едноплатков компютър (семейства beaglebone, raspberry pi и orange pi, asus tinker board). Освен това такова оборудване е евтино и може да се инсталира навсякъде.
Проблем изявление
В много отношения проектът се разви като вид лабораторна работа с възможност за прилагане на резултатите.
Zabbix беше избрана като система за мониторинг, защото е мощна, безплатна и добре документирана система.
Изостря се въпросът с хардуерната платформа.Поставянето на отделна машина под наблюдение също не е много добро решение - или е скъпо да се купува ново оборудване, или да се търси старо оборудване + в малките фирми често има проблеми със сървъра/ хардуер.
Използването на системата за изграждане на buildroot ви позволява да създавате специализирани решения, които могат да се управляват от персонал с минимални познания за операционните системи Linux. Тази система е удобна за начинаещи, но в същото време предоставя достатъчно възможности за персонализиране в ръцете на опитен разработчик. Той е идеален за решаване на проблема с евтин, но напълно функционален мониторинг на ИТ инфраструктура, с минимални изисквания за обучение на персонала, който я управлява.
Стъпки на решението
Беше решено първоначално да се създаде фърмуер за x86_64, който да работи в qemu, тъй като това е удобно и бързо решение за отстраняване на грешки. След това го пренесете към едноплатков компютър с рамо (харесах платката на asus).
buildroot беше избран като система за изграждане. Първоначално липсва пакетът zabbix, така че трябваше да бъде пренесен.Имаше проблеми с руския локал, които бяха решени чрез прилагане на съответните пачове (забележка: в по-новите версии на buildroot тези пачове вече не са необходими).
Пренасянето на самия пакет zabbix ще бъде описано в отделна статия.
Тъй като всичко трябва да работи като фърмуер (непроменливо системно изображение + възстановими файлове за конфигурация/база данни), беше необходимо да напишете свои собствени systemd цели, услуги и таймери (target, service, timer).
Беше решено медията да се раздели на 2 секции - секция със системни файлове и секция с променливи конфигурации и файлове на базата данни на zabbix.
Решаването на проблеми, свързани с базата данни, се оказа малко по-трудно. Не исках да го пускам директно в медиите. В същото време размерът на базата данни може да достигне размер, който надвишава размера на възможен ramdisk. Затова беше избрано компромисно решение: базата данни се намира на втория дял на SD картата (съвременните SLC карти имат до 30 000 цикъла на запис), но има настройка, която позволява използването на външни носители (например usb- hdd).
Мониторингът на температурата е реализиран чрез уред RODOS-5. Разбира се, можете да използвате Dallas 1820 директно, но беше по-бързо и лесно да включите USB.
grub86 беше избран като зареждащ механизъм за x64_2. Беше необходимо да се напише минимална конфигурация, за да се стартира.
След отстраняване на грешки на qemu, той беше пренесен към платката на asus. Структурата на моето наслагване първоначално беше предназначена да бъде междуплатформена - разпределяне на конфигурации, специфични за всяка платка (defconfig на платка, зареждащо устройство, генериране на изображение със системен дял) и максимална еднородност при персонализиране на файловата система/създаване на изображение с данни. Благодарение на такава подготовка пренасянето мина бързо.
Препоръчително е да прочетете уводните статии:
Как да се съберат
След клониране на хранилището се получава следната файлова структура:
[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.shbuildroot-2019.05.tar.gz - чист buildroot архив
overlay е моята директория с външно дърво. Това е мястото, където се съхранява всичко необходимо за изграждане на фърмуера с помощта на buildroot.
README.md - описание на проекта и ръководство на английски език.
run_me.sh е скрипт, който подготвя системата за изграждане. Разширява buildroot от архива, прикрепя наслагване към него (чрез механизма за външно дърво) и ви позволява да изберете целевата платка за сглобяване
[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 - изображение на външен носител за базата данни
- monitor-0.9-beta.tar.gz - архив за актуализиране през уеб интерфейса
Генериране на ръководства
Не си струва да пишете едни и същи инструкции няколко пъти. И най-логичното нещо е да го напишете веднъж в markdown и след това да го конвертирате в PDF за изтегляне и html за уеб интерфейса. Това е възможно благодарение на пакета pandoc.
В същото време всички тези файлове трябва да бъдат генерирани преди системното изображение да бъде сглобено; тези скриптове след компилирането вече са безполезни. Следователно генерирането се извършва под формата на пакет с ръководства. Можете да разгледате оверлей/пакет/ръководства.
Файлът 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
OnUnitActiveSec=1мин [Инсталиране] 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 (чрез услугата). Възстановява основните системни настройки - часова зона, локал, мрежови настройки и др.
- стартиране на подготвителния скрипт (чрез услугата) - тук zabbix и базата данни се подготвят, IP се извежда към конзолата.
Когато го стартирате за първи път, се определя размерът на втория дял на SD картата. Ако все още има неразпределено място, носителят се преразпределя и секцията с данни заема цялото свободно пространство. Това се прави, за да се намали размера на инсталационното изображение (sdcard.img). Освен това в този момент се създава работната директория postgresql. Ето защо първото изстрелване с нов носител ще бъде по-дълго от следващите.
При свързване на външен диск, в момента на стартиране търси свободен диск и го форматира в ext4 с външен етикет.
внимание! При свързване на външно устройство (както и при изключване или замяна) трябва да направите резервно копие и да възстановите настройките!
За наблюдение на температурата се използва устройството 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 порта
- създайте елемент с данни в zabbix
Отворете уеб интерфейса на zabbix:
- Отворете секцията Конфигурация → Хостове
- Кликнете върху Елементи в реда на нашия zabbix сървър
- Кликнете върху Създаване на елемент
Въведете следните данни:
- име - по ваша преценка (например serverRoomTemp )
- Тип - zabbix агент
- Ключ - Родос
- Тип-числов
- Единици - C
- Период на съхранение на историята — период на съхранение на историята. остават 10 дни
- Период на съхранение на тенденцията - период на съхранение на динамиката на промените. Остават 30 дни
- Ново приложение - сървър 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 -устройство intel-iommu -cpu host -net nic -net bridge,br=bridge0 -устройство 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 и два диска: един за системата и един външен за 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-устройство в KVM показа, че тази стъпка е правилна (след като инсталацията приключи, системата не стартира). Може би правя нещо нередно 😉
Източник: www.habr.com