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.

Korzystanie z systemu kompilacji buildroot pozwala na tworzenie specjalistycznych rozwiązań, które mogą być obsługiwane przez personel posiadający minimalną wiedzę na temat systemów operacyjnych Linux. System ten jest przyjazny dla początkujących, ale jednocześnie zapewnia szerokie możliwości personalizacji w rękach doświadczonego programisty. Doskonale nadaje się do rozwiązania problemu niedrogiego, ale w pełni funkcjonalnego monitoringu infrastruktury IT, przy minimalnych wymaganiach dotyczących przeszkolenia obsługującego ją personelu.

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 Linuksa aktywnie przenosi 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

[Timer] OnBootSec=1min
OnUnitActiveSec=1min

[Zainstaluj] 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