Buildroot: platformonafhankelijke firmware maken met zabbix-server

Buildroot: platformonafhankelijke firmware maken met zabbix-server

Probleem geschiedenis

Kleine bedrijven hebben enerzijds hoogwaardige monitoring van hun infrastructuur nodig (vooral in het licht van de wijdverbreide virtualisatie), maar anderzijds is het voor hen financieel moeilijk om nieuwe apparatuur aan te schaffen. Server-/hardwareproblemen komen ook vaak voor: vaak staan ​​er 1-3 torenservers naast gebruikerswerkstations of in een kleine nis/kast.

Het is gemakkelijker om een ​​kant-en-klare assemblage (distributie) te gebruiken, die u alleen maar hoeft te uploaden naar een microSD-kaart en in een gewone computer met één bord hoeft te plaatsen (families Beaglebone, Raspberry Pi en Orange Pi, Asus Tinker Board). Bovendien is dergelijke apparatuur goedkoop en kan deze overal worden geïnstalleerd.

Formulering van het probleem

In veel opzichten ontwikkelde het project zich als een soort laboratoriumwerk met de mogelijkheid om de resultaten toe te passen.

Er werd gekozen voor Zabbix als monitoringsysteem omdat het een krachtig, gratis en goed gedocumenteerd systeem is.

Het probleem met het hardwareplatform is acuut geworden. Een aparte machine onder toezicht zetten is ook geen erg goede oplossing - het is óf duur om nieuwe apparatuur aan te schaffen, óf om naar oude apparatuur te zoeken + in kleine bedrijven zijn er regelmatig problemen met server/ hardware.

Met behulp van het buildroot-buildsysteem kunt u gespecialiseerde oplossingen creëren die kunnen worden bediend door personeel met minimale kennis van Linux-besturingssystemen. Dit systeem is vriendelijk voor beginners, maar biedt tegelijkertijd ruime aanpassingsmogelijkheden in de handen van een ervaren ontwikkelaar. Het is perfect voor het oplossen van het probleem van goedkope, maar volledig functionele monitoring van de IT-infrastructuur, met minimale vereisten voor de training van het personeel dat de infrastructuur bedient.

Oplossing stappen

Er werd besloten om in eerste instantie firmware te maken voor x86_64 om in qemu te draaien, omdat dit een handige en snelle oplossing is voor foutopsporing. Port het vervolgens naar een arm-single-board computer (ik vond het Asus Tinker Board leuk).

buildroot werd geselecteerd als het buildsysteem. In eerste instantie ontbreekt het zabbix-pakket, dus moest het worden geport.Er waren problemen met de Russische landinstelling, die werden opgelost door de juiste patches toe te passen (let op: in nieuwere versies van buildroot zijn deze patches niet langer nodig).

Het porten van het zabbix-pakket zelf wordt in een apart artikel beschreven.

Omdat alles als firmware zou moeten werken (onveranderlijk systeemimage + herstelbare configuratie-/databasebestanden), was het noodzakelijk om uw eigen systeemdoelen, services en timers (doel, service, timer) te schrijven.

Er werd besloten om de media in twee secties te splitsen: een sectie met systeembestanden en een sectie met veranderlijke configuraties en zabbix-databasebestanden.

Het oplossen van problemen met betrekking tot de database bleek iets moeilijker. Ik wilde het niet rechtstreeks op de media plaatsen. Tegelijkertijd kan de omvang van de database een omvang bereiken die groter is dan de grootte van een mogelijke ramdisk. Daarom is gekozen voor een compromisoplossing: de database bevindt zich op het tweede deel van de SD-kaart (moderne SLC-kaarten hebben maximaal 30 schrijfcycli), maar er is een instelling die het gebruik van externe media mogelijk maakt (bijvoorbeeld usb- hdd).

Temperatuurmonitoring werd geïmplementeerd via het RODOS-5-apparaat. Natuurlijk kun je de Dallas 1820 direct gebruiken, maar het was sneller en gemakkelijker om een ​​USB aan te sluiten.

grub86 werd geselecteerd als de bootloader voor x64_2. Het was nodig om een ​​minimale configuratie te schrijven om het te starten.

Na het debuggen op qemu, werd het overgezet naar het asus tinkerboard. De structuur van mijn overlay was aanvankelijk bedoeld om platformonafhankelijk te zijn - het toewijzen van configuraties die specifiek zijn voor elk bord (board defconfig, bootloader, het genereren van een image met een systeempartitie) en maximale uniformiteit bij het aanpassen van het bestandssysteem/het maken van een image met gegevens. Dankzij een dergelijke voorbereiding verliep het porten snel.

Het wordt sterk aanbevolen om de inleidende artikelen te lezen:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Hoe te monteren

Het project wordt opgeslagen op github
Na het klonen van de repository wordt de volgende bestandsstructuur verkregen:

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

buildroot-2019.05.tar.gz - maak het buildroot-archief schoon
overlay is mijn map met externe boom. Hier wordt alles opgeslagen wat u nodig hebt om de firmware te bouwen met buildroot.
README.md - projectbeschrijving en handleiding in het Engels.
run_me.sh is een script dat het buildsysteem voorbereidt. Breidt buildroot uit het archief uit, voegt er een overlay aan toe (via het externe boommechanisme) en stelt u in staat het doelbord te selecteren voor montage

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

Ga hierna gewoon naar de map buildroot-2019.05 en voer de opdracht make uit.
Zodra de build is voltooid, bevinden alle buildresultaten zich in de map 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

Vereiste bestanden:

  • sdcard.img - media-afbeelding voor opname op een SD-kaart (via dd of rufus onder wibdows).
  • qemu.qcow2 - media-afbeelding om in qemu uit te voeren.
  • external.qcow2 - externe media-afbeelding voor de database
  • monitor-0.9-beta.tar.gz - archief voor updates via de webinterface

Generatie van gidsen

Het is niet de moeite waard om meerdere keren dezelfde instructies te schrijven. En het meest logische is om het één keer in markdown te schrijven en het vervolgens naar PDF te converteren om te downloaden en naar HTML voor de webinterface. Dit is mogelijk dankzij het pandoc-pakket.

Tegelijkertijd moeten al deze bestanden worden gegenereerd voordat het systeemimage wordt samengesteld; die scripts na het bouwen zijn al nutteloos. Daarom gebeurt het genereren in de vorm van een handleidingenpakket. U kunt kijken naar overlay/pakket/handleidingen.

Het manuals.mk-bestand (dat al het werk doet)

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

De Linux-wereld is actief bezig met de overstap naar systemd, en ik moest het ook doen.
Een van de prettige innovaties is de aanwezigheid van timers. Over het algemeen wordt er een apart artikel over geschreven (en niet alleen over hen), maar ik zal het je kort vertellen.

Er zijn acties die periodiek moeten worden uitgevoerd. Ik moest logrotate uitvoeren om de lighttpd- en php-fpm-logboeken te wissen. Het gebruikelijke zou zijn om de commando's in cron te schrijven, maar ik besloot de systemd monotone timer te gebruiken. Logrotate werkt dus met een strikt tijdsinterval.

Natuurlijk is het mogelijk om timers te maken die op bepaalde data afgaan, maar dit had ik niet nodig.
Timervoorbeeld:

  • Timerbestand
    
    [Unit]
    Description=RODOS temp daemon timer

[Timer] AanBootSec=1min
AanEenheidActiveSec=1min

[Installeren] WantedBy=timers.target

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

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

Ondersteunde planken

Asus tinkerboard is het moederbord waarop alles zou moeten werken. Geselecteerd als goedkoop en zeer krachtig.

Beaglebone zwart is het eerste bord waarop de werking is getest (tijdens de selectie van een krachtiger bord).

Qemu x86_64 - gebruikt voor het debuggen van de ontwikkeling.

Hoe het werkt

Bij het opstarten vindt een herstel van de instellingen in twee fasen plaats:

  • het script settings_restore uitvoeren (via de service). Het herstelt de basissysteeminstellingen - tijdzone, landinstelling, netwerkinstellingen, enz.
  • het voorbereidingsscript uitvoeren (via de service) - hier worden zabbix en de database voorbereid, het IP-adres wordt naar de console uitgevoerd.

Wanneer u het voor het eerst start, wordt de grootte van de tweede partitie van de SD-kaart bepaald. Als er nog steeds niet-toegewezen ruimte is, worden de media opnieuw gepartitioneerd en neemt de gegevenssectie alle vrije ruimte in beslag. Dit wordt gedaan om de grootte van de installatie-image (sdcard.img) te verkleinen. Bovendien wordt op dit punt de postgresql-werkmap gemaakt. Daarom zal de eerste lancering met een nieuwe vervoerder langer duren dan de daaropvolgende.

Wanneer u een externe schijf aansluit, zoekt deze op het moment van opstarten naar een vrije schijf en formatteert deze in ext4 met het externe label.

Aandacht! Wanneer u een externe schijf aansluit (en deze loskoppelt of vervangt), moet u een back-up maken en de instellingen herstellen!

Het RODOS 5-apparaat wordt gebruikt voor temperatuurbewaking. De fabrikant levert de broncode van het hulpprogramma voor het werken met het apparaat. Wanneer het systeem wordt ingeschakeld, start de rodos-timer, die dit hulpprogramma eenmaal per minuut uitvoert. De huidige temperatuur wordt naar het bestand /tmp/rodos_current_temp geschreven, waarna zabbix dit bestand als sensor kan monitoren.

Het configuratie-opslagmedium wordt aangekoppeld in de map /data.

Bij het opstarten van het systeem en het gereedmaken voor gebruik verschijnt de volgende melding in de console:

System starting, please wait

Na voltooiing van de voorbereidende werkzaamheden verandert het in het weergeven van het IP-adres:

current ip 192.168.1.32
Ready to work

Zabbix instellen voor temperatuurmonitoring

Om de temperatuur te controleren, voert u slechts 2 stappen uit:

  • sluit het RODOS-apparaat aan op de USB-poort
  • maak een gegevensitem in zabbix

Open de zabbix-webinterface:

  • Open de sectie Configuratie → Hosts
  • Klik op Items in de regel van onze zabbix-server
  • Klik op Artikel aanmaken

Buildroot: platformonafhankelijke firmware maken met zabbix-server

Voer de volgende gegevens in:

  • naam - naar eigen goeddunken (bijvoorbeeld serverRoomTemp )
  • Type - zabbix-agent
  • Sleutel - Rodos
  • Type-numeriek
  • Eenheden - C
  • Opslagperiode geschiedenis — opslagperiode geschiedenis. 10 dagen vertrokken
  • Trendopslagperiode: opslagperiode voor de dynamiek van veranderingen. 30 dagen vertrokken
  • Nieuwe applicatie - server Kamertemp

En druk op de TOEVOEGEN-knop.
Buildroot: platformonafhankelijke firmware maken met zabbix-server

Beheer instellingen via webinterface

De webinterface is geschreven in PHP. Er zijn hoofdfuncties:

  • apparaatstatus bekijken
  • netwerkinstellingen wijzigen
    Buildroot: platformonafhankelijke firmware maken met zabbix-server
  • gebruikerswachtwoord wijzigen
  • tijdzone selectie
  • back-up/herstel/fabrieksreset
  • mogelijkheid om een ​​externe schijf aan te sluiten
  • Systeem update
    Buildroot: platformonafhankelijke firmware maken met zabbix-server

Inloggen op de webinterface is beveiligd met een wachtwoord. Startpagina - handleiding.

Zabbix-interfaceadres: ${ip/dns}/zabbix
Adres beheerinterface: ${ip/dns}/manage
Buildroot: platformonafhankelijke firmware maken met zabbix-server

Rennen in 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

Deze opdracht start een systeem met 4 kernen, 2048 RAM, KVM ingeschakeld, een netwerkkaart op bridge0 en twee schijven: één voor het systeem en één extern voor postgresql.

Afbeeldingen kunnen worden geconverteerd en uitgevoerd in Virtualbox:

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

Importeer ze vervolgens in virtualbox en maak verbinding via sata.

Conclusie

Gaandeweg raakte ik geïnteresseerd in het maken van een kant-en-klaar product - met een niet erg mooie interface (ik houd er niet van om ze te schrijven), maar wel een die werkt en gemakkelijk te configureren is.

De laatste poging om zabbix-appliance in KVM te installeren toonde aan dat deze stap correct was (nadat de installatie is voltooid, start het systeem niet op). Misschien doe ik iets verkeerd 😉

materialen

https://buildroot.org/

Bron: www.habr.com

Voeg een reactie