Buildroot: Zbuduj wieloplatformowe oprogramowanie układowe za pomocą zabbix-server

Historia problemów

Małe firmy z jednej strony potrzebują wysokiej jakości monitoringu swojej infrastruktury (szczególnie w świetle powszechnej wirtualizacji), z drugiej strony mają trudności finansowe z zakupem nowego sprzętu. Częste są również problemy z serwerem/sprzętem: często obok stacji roboczych użytkowników lub w małej niszy/szafie znajdują się 1-3 serwery typu tower.

Łatwiej skorzystać z gotowego zestawu (dystrybucji), który wystarczy wgrać na kartę microSD i włożyć do zwykłego komputera jednopłytkowego (rodziny beaglebone, raspberry pi i orange pi, asus tinker board). Ponadto taki sprzęt jest niedrogi i można go zainstalować w dowolnym miejscu.

Stwierdzenie problemu

Projekt pod wieloma względami rozwinął się jako rodzaj pracy laboratoryjnej z możliwością zastosowania wyników.

Na system monitorowania wybrano Zabbix, ponieważ jest to potężny, darmowy i dobrze udokumentowany system.

Problem z platformą sprzętową stał się poważny. Monitorowanie osobnej maszyny też nie jest zbyt dobrym rozwiązaniem - albo zakup nowego sprzętu jest drogi, albo szukanie starego sprzętu + w małych firmach często zdarzają się problemy z serwerem/ sprzęt komputerowy.

Użycie systemu buildroot umożliwia tworzenie specjalistycznych rozwiązań, które mogą być obsługiwane przez personel dysponujący minimalną wiedzą na temat rodziny systemów operacyjnych. LinuxTen system jest przyjazny dla początkujących, a jednocześnie oferuje rozbudowane możliwości personalizacji dla doświadczonych programistów. Idealnie nadaje się do niedrogiego, a jednocześnie w pełni funkcjonalnego monitorowania infrastruktury IT, z minimalnymi wymaganiami szkoleniowymi dla personelu obsługującego.

Kroki rozwiązania

Zdecydowano się początkowo stworzyć oprogramowanie układowe dla x86_64 do działania w qemu, ponieważ jest to wygodne i szybkie rozwiązanie do debugowania. Następnie przenieś go do komputera jednopłytkowego z ramieniem (spodobała mi się płyta asus tinker board).

Jako system kompilacji wybrano buildroot. Początkowo brakowało mu pakietu zabbix, więc trzeba było go przenieść.Wystąpiły problemy z rosyjskim locale, które rozwiązano poprzez zastosowanie odpowiednich łatek (uwaga: w nowszych wersjach buildroot te łatki nie są już potrzebne).

Samo przeniesienie pakietu zabbix zostanie opisane w osobnym artykule.

Ponieważ wszystko powinno działać jako oprogramowanie sprzętowe (niezmienny obraz systemu + odzyskiwalne pliki konfiguracyjne/bazy danych), konieczne było napisanie własnych celów systemowych, usług i timerów (target, service, timer).

Zdecydowano się podzielić nośnik na 2 sekcje - sekcję z plikami systemowymi oraz sekcję ze zmienialnymi konfiguracjami i plikami bazy danych Zabbix.

Nieco trudniejsze okazało się rozwiązanie problemów związanych z bazą danych. Nie chciałem umieszczać tego bezpośrednio w mediach. Jednocześnie rozmiar bazy danych może osiągnąć rozmiar przekraczający rozmiar możliwego ramdysku. Dlatego wybrano rozwiązanie kompromisowe: baza danych znajduje się na drugiej partycji karty SD (nowoczesne karty SLC mają do 30 000 cykli zapisu), ale jest ustawienie umożliwiające korzystanie z nośników zewnętrznych (np. dysk twardy).

Monitoring temperatury zrealizowano za pomocą urządzenia RODOS-5. Oczywiście można używać bezpośrednio Dallas 1820, ale szybciej i łatwiej było podłączyć USB.

Grub86 został wybrany jako program ładujący dla x64_2. Aby go uruchomić, konieczne było napisanie minimalnej konfiguracji.

Po debugowaniu na qemu został przeniesiony na asus tinker board. Struktura mojej nakładki początkowo miała być wieloplatformowa - przydzielanie konfiguracji specyficznych dla każdej płyty (defconfig płyty, bootloader, generowanie obrazu z partycją systemową) i maksymalna jednolitość w dostosowywaniu systemu plików/tworzeniu obrazu z danymi. Dzięki takiemu przygotowaniu porting przebiegł szybko.

Gorąco polecamy zapoznanie się z artykułami wprowadzającymi:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Jak złożyć

Projekt jest przechowywany na githubie
Po sklonowaniu repozytorium uzyskuje się następującą strukturę plików:

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

buildroot-2019.05.tar.gz - wyczyść archiwum buildroot
nakładka to mój katalog z drzewem zewnętrznym. Tutaj przechowywane jest wszystko, czego potrzebujesz do zbudowania oprogramowania sprzętowego za pomocą buildroot.
README.md - opis projektu i instrukcja w języku angielskim.
run_me.sh to skrypt przygotowujący system kompilacji. Rozwija buildroot z archiwum, dołącza do niego nakładkę (poprzez mechanizm zewnętrznego drzewa) i pozwala wybrać płytkę docelową do montażu

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

Następnie przejdź do katalogu buildroot-2019.05 i uruchom polecenie make.
Po zakończeniu kompilacji wszystkie wyniki kompilacji znajdą się w katalogu 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

Wymagane pliki:

• sdcard.img - obraz multimediów do zapisania na karcie SD (przez dd lub rufus w wibdows).
• qemu.qcow2 - obraz nośnika do uruchomienia w qemu.
• external.qcow2 - obraz nośnika zewnętrznego dla bazy danych
• monitor-0.9-beta.tar.gz - archiwum do aktualizacji poprzez interfejs WWW

Generacja przewodników

Nie warto pisać tej samej instrukcji kilka razy. Najbardziej logiczną rzeczą jest zapisanie tego raz w Markdown, a następnie przekonwertowanie go na format PDF do pobrania i HTML dla interfejsu internetowego. Jest to możliwe dzięki pakietowi pandoc.

Jednocześnie wszystkie te pliki należy wygenerować przed złożeniem obrazu systemu; te skrypty po kompilacji są już bezużyteczne. Dlatego generowanie odbywa się w formie pakietu podręczników. Możesz zajrzeć do nakładki/pakietu/podręczników.

Plik manuals.mk (który wykonuje całą pracę)

################################################################################
#
# 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

Świat Linux aktywnie przełącza się na systemd i ja też musiałem to zrobić.
Jedną z przyjemnych innowacji jest obecność timerów. W sumie pisze się o nich (i nie tylko) osobny artykuł, ale opowiem krótko.

Istnieją czynności, które należy wykonywać okresowo. Musiałem uruchomić logrotate, aby wyczyścić dzienniki lighttpd i php-fpm. Typową rzeczą byłoby pisanie poleceń w cronie, ale zdecydowałem się użyć systemowego zegara monotonicznego. Zatem logrotate działa w ściśle określonych odstępach czasu.

Oczywiście możliwe jest utworzenie timerów uruchamiających się w określonych dniach, ale nie było mi to potrzebne.
Przykład timera:

• Plik timera

  
  [Unit]
  Description=RODOS temp daemon timer

[Regulator czasowy]
OnBootSec = 1 min
OnUnitActiveSec=1min

[Zainstalować]
WantedBy=timers.target

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

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

Obsługiwane płyty

Tinker Board firmy Asus to płyta główna, na której wszystko powinno działać. Wybrany jako niedrogi i bardzo mocny.

Beaglebone black to pierwsza deska, na której sprawdzono działanie (przy wyborze deski o większej mocy).

Qemu x86_64 - używany do debugowania programowania.

Jak działa

Podczas uruchamiania następuje dwuetapowe przywracanie ustawień:

• uruchomienie skryptu settings_restore (poprzez usługę). Przywraca podstawowe ustawienia systemu - strefę czasową, ustawienia regionalne, ustawienia sieciowe itp.
• uruchomienie skryptu przygotowującego (poprzez usługę) - tutaj przygotowywany jest zabbix i baza danych, adres IP jest wyprowadzany na konsolę.

Przy pierwszym uruchomieniu określany jest rozmiar drugiej partycji karty SD. Jeśli nadal jest nieprzydzielone miejsce, nośnik jest ponownie dzielony na partycje, a sekcja danych zajmuje całe wolne miejsce. Odbywa się to w celu zmniejszenia rozmiaru obrazu instalacyjnego (sdcard.img). Dodatkowo w tym momencie tworzony jest katalog roboczy postgresql. Dlatego pierwszy start z nowym przewoźnikiem będzie dłuższy niż kolejne.

Podłączając dysk zewnętrzny, w momencie uruchomienia wyszukuje wolny dysk i formatuje go do ext4 z etykietą zewnętrzną.

Uwaga! Podłączając dysk zewnętrzny (a także odłączając go lub wymieniając), należy wykonać kopię zapasową i przywrócić ustawienia!

Do monitorowania temperatury służy urządzenie RODOS 5. Producent udostępnia kod źródłowy swojego narzędzia do pracy z urządzeniem. Po włączeniu systemu uruchamia się licznik czasu rodos, który uruchamia to narzędzie raz na minutę. Aktualna temperatura jest zapisywana w pliku /tmp/rodos_current_temp, po czym Zabbix może monitorować ten plik jako czujnik.

Nośnik przechowywania konfiguracji jest montowany w katalogu /data.

Podczas uruchamiania systemu i przygotowania go do pracy w konsoli pojawia się komunikat:

System starting, please wait

Po zakończeniu prac przygotowawczych zmieni się na wyświetlanie adresu IP:

current ip 192.168.1.32
Ready to work

Konfigurowanie Zabbix do monitorowania temperatury

Aby monitorować temperaturę, wykonaj 2 kroki:

• podłącz urządzenie RODOS do portu USB
• utwórz element danych w Zabbix

Otwórz interfejs sieciowy Zabbix:

• Otwórz sekcję Konfiguracja → Hosty
• Kliknij Elementy w wierszu naszego serwera Zabbix
• Kliknij opcję Utwórz element

Wprowadź następujące dane:

• nazwa - według własnego uznania (na przykład serverRoomTemp )
• Typ - agent zabbix
• Klucz - Rodos
• Typ-numeryczny
• Jednostki - C
• Okres przechowywania historii — okres przechowywania historii. pozostało 10 dni
• Okres przechowywania trendów – okres przechowywania dynamiki zmian. Pozostało 30 dni
• Nowa aplikacja - serwer Temperatura pokojowa

I naciśnij przycisk DODAJ.

Zarządzaj ustawieniami za pośrednictwem interfejsu internetowego

Interfejs sieciowy napisany jest w języku PHP. Istnieją główne funkcje:

• przeglądać stan urządzenia
• zmiana ustawień sieciowych
  
• zmiana hasła użytkownika
• wybór strefy czasowej
• kopia zapasowa/przywracanie/reset fabryczny
• możliwość podłączenia dysku zewnętrznego
• Aktualizacja systemu
  

Logowanie do interfejsu internetowego jest chronione hasłem. Strona startowa - instrukcja.

Adres interfejsu Zabbix: ${ip/dns}/zabbix
Adres interfejsu zarządzania: ${ip/dns}/manage

Działa w Qemu

qemu-system-x86_64 -smp 4 -m 4026M -enable-kvm -machine q35,accel=kvm -device intel-iommu -cpu host -net nic -net most,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

To polecenie uruchomi system z 4 rdzeniami, 2048 RAM, włączoną obsługą KVM, kartą sieciową na mostku 0 i dwoma dyskami: jednym dla systemu i jednym zewnętrznym dla postgresql.

Obrazy można konwertować i uruchamiać w Virtualboxie:

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

Następnie zaimportuj je do wirtualnej skrzynki i połącz się przez sata.

wniosek

Przy okazji zainteresowałem się stworzeniem produktu gotowego do użycia - z niezbyt pięknym interfejsem (nie lubię ich pisać), ale takim, który działa i jest łatwy w konfiguracji.

Ostatnia próba instalacji zabbix-appliance w KVM pokazała, że ​​ten krok był prawidłowy (po zakończeniu instalacji system nie uruchamia się). Być może robię coś źle 😉

materiały

https://buildroot.org/

Źródło: www.habr.com