🥇Buildroot: crea firmware multipiattaforma con zabbix-server

Cronologia attività

Da un lato, le aziende di piccole dimensioni necessitano di un monitoraggio di alta qualità della propria infrastruttura (soprattutto alla luce della diffusa virtualizzazione), dall'altro è finanziariamente difficile per loro acquistare nuove apparecchiature. Inoltre spesso ci sono problemi con il server/hardware: spesso ci sono 1-3 tower-server accanto alle postazioni degli utenti o in una piccola nicchia/armadio.

È più semplice utilizzare un assemblaggio già pronto (kit di distribuzione), che è sufficiente caricare su una scheda microSD e inserirlo in un comune computer a scheda singola (famiglie beaglebone, raspberry pi e orange pi, asus tinker board). Inoltre, tali apparecchiature sono economiche e possono essere installate ovunque.

Formulazione del problema

Per molti versi, il progetto si è sviluppato come una sorta di lavoro di laboratorio con la possibilità di applicare i risultati.

Zabbix è stato scelto come sistema di monitoraggio, in quanto è un sistema potente, gratuito e ben documentato.

La domanda è sorta con piattaforma hardware... Anche mettere sotto controllo una macchina separata non è una buona soluzione: o è costoso acquistare nuove apparecchiature o cercare vecchie apparecchiature + nelle piccole imprese ci sono frequenti problemi con il server / hardware.

L'utilizzo del sistema di compilazione buildroot consente di creare soluzioni personalizzate che possono essere gestite da personale con una conoscenza minima della famiglia di sistemi operativi Linux. Questo sistema è adatto ai principianti, ma allo stesso tempo offre ampie opportunità di personalizzazione nelle mani di uno sviluppatore esperto. È perfetto per risolvere il problema di un monitoraggio non costoso ma completo dell'infrastruttura IT, che richiede una formazione minima per il personale che la gestisce.

Passaggi della soluzione

Si è deciso di creare inizialmente un firmware per x86_64 da eseguire in qemu, poiché si tratta di una soluzione di debug comoda e veloce. Quindi trasferiscilo su un computer a scheda singola (mi è piaciuta la scheda asus tinker).

buildroot è stato scelto come sistema di compilazione. Inizialmente mancava il pacchetto zabbix, quindi ho dovuto portarlo.Ci sono stati problemi con la localizzazione russa, che sono stati risolti applicando le patch appropriate (nota: nelle versioni buildroot più recenti, queste patch non sono più necessarie).

Il porting del pacchetto zabbix stesso sarà descritto in un articolo separato.

Poiché tutto dovrebbe funzionare come un firmware (immagine di sistema immutabile + file di configurazione / database recuperabili), è stato necessario scrivere i propri target, servizi e timer systemd (target, servizio, timer).

È stato deciso di dividere il supporto in 2 sezioni: una sezione con file di sistema e una sezione con configurazioni modificabili e file di database zabbix.

Si è rivelato un po' più difficile risolvere i problemi relativi al database. C'era poco desiderio di posizionarlo direttamente sul corriere. Allo stesso tempo, la dimensione della base può raggiungere una dimensione che supera la dimensione di un eventuale ramdisk. Pertanto, è stata scelta una soluzione di compromesso: il database si trova nella seconda sezione della scheda sd (le moderne schede SLC hanno fino a 30 cicli di scrittura), ma esiste un'impostazione che consente di utilizzare supporti esterni (ad esempio, usb- HDD).

Il monitoraggio della temperatura è stato implementato tramite il dispositivo RODOS-5. Certo, puoi usare direttamente il dallas 1820, ma è stato più veloce e più facile collegare l'USB.

grub86 è stato scelto come bootloader per x64_2. Era necessario scrivere una configurazione minima per l'esecuzione.

Dopo il debug su qemu, è stato eseguito il porting su asus tinker board. Nella struttura del mio overlay, inizialmente era prevista la multipiattaforma: l'assegnazione di configurazioni specifiche per ciascuna scheda (board defconfig, bootloader, generazione di immagini con una partizione di sistema) e la massima uniformità nella configurazione del file system / creazione di un'immagine con i dati . Alla luce di questa preparazione, il porting è andato rapidamente.

Si consiglia vivamente di leggere gli articoli introduttivi:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Come assemblare

Il progetto è memorizzato su github
Dopo aver clonato il repository, si ottiene la seguente struttura di file:

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

buildroot-2019.05.tar.gz - pulisce l'archivio buildroot
overlay è la mia directory ad albero esterno. È in esso che viene memorizzato tutto ciò di cui hai bisogno per assemblare il firmware usando buildroot
README.md - descrizione del progetto e manuale in inglese.
run_me.sh è uno script che prepara il sistema di compilazione. Espande la buildroot dall'archivio, le allega un overlay (tramite il meccanismo dell'albero esterno) e consente di selezionare la scheda di destinazione per la build

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

Successivamente, vai alla directory buildroot-2019.05 ed esegui il comando make.
Al termine della compilazione, tutti i risultati della compilazione saranno nella directory 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

File richiesti:

sdcard.img - immagine multimediale per la scrittura sulla scheda SD (tramite dd o rufus sotto wibdows).
qemu.qcow2 - immagine multimediale da eseguire in qemu.
external.qcow2 - immagine multimediale esterna per il database
monitor-0.9-beta.tar.gz - archivio per l'aggiornamento tramite l'interfaccia web

Generazione manuale

Non vale la pena scrivere più volte la stessa istruzione. E la cosa più logica è scriverlo una volta in markdown, quindi convertirlo in PDF per il download e html per l'interfaccia web. Questo è possibile grazie al pacchetto pandoc.

Allo stesso tempo, è necessario generare tutti questi file prima che l'immagine del sistema venga assemblata, quegli script post-compilazione sono già inutili. Pertanto, la generazione viene effettuata sotto forma di un pacchetto manuali. Puoi vederlo in overlay/pacchetto/manuali.

Il file manuals.mk (che fa tutto il lavoro)

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

Il mondo Linux si sta spostando attivamente su systemd, dovevo farlo anch'io.
Delle piacevoli innovazioni: la presenza di timer. In generale, viene scritto un articolo a parte su di loro (e non solo su di loro), ma ne parlerò brevemente.

Ci sono azioni che devono essere eseguite periodicamente. Avevo bisogno di eseguire logrotate per ripulire i log lighttpd e php-fpm. Il più comune sarebbe scrivere comandi in cron, ma ho deciso di utilizzare il timer monotono di systemd. Quindi logrotate viene eseguito dopo un intervallo di tempo rigoroso.

Certo, è possibile creare timer che si attivano in determinate date, ma non ne avevo bisogno.
Esempio di timer:

File del temporizzatore


[Unit]
Description=RODOS temp daemon timer

[Timer] OnBootSec=1min
SuUnitàAttivaSec=1min

[Installa] WantedBy=timer.target

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

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

Schede supportate

Asus tinker board è la scheda principale su cui tutto dovrebbe funzionare. Scelto come economico e molto potente.

Beaglebone black è la prima tavola su cui è stato testato il lavoro (durante la selezione di una tavola più potente).

Qemu x86_64 - Utilizzato per lo sviluppo del debug.

Come funziona

All'avvio, c'è un ripristino delle impostazioni in due fasi:

avviando lo script settings_restore (tramite un servizio). Ripristina le impostazioni di base del sistema: fuso orario, impostazioni locali, impostazioni di rete, ecc.
avvio dello script di preparazione (tramite il servizio) - zabbix, il database viene preparato qui, l'IP viene visualizzato nella console.

Al primo avvio, viene determinata la dimensione della seconda sezione della scheda SD. Se c'è ancora spazio non allocato, il supporto viene ripartizionato, la partizione dati occupa tutto lo spazio libero. Questo viene fatto per ridurre le dimensioni dell'immagine di installazione (sdcard.img). Inoltre, a questo punto viene creata la directory di lavoro postgresql. Ecco perché il primo lancio con un nuovo supporto sarà più lungo dei successivi.

Quando si collega un'unità esterna, al momento dell'avvio cerca un'unità libera e la formatta in ext4 con l'etichetta external.

Attenzione! Quando si collega un'unità esterna (oltre a scollegarla o sostituirla), è necessario eseguire un backup e ripristinare le impostazioni!

Per monitorare la temperatura viene utilizzato il dispositivo RODOS 5. Il produttore fornisce i codici sorgente della sua utilità per lavorare con il dispositivo. Quando accendi il sistema, si avvia il timer Rodos, che esegue questa utility una volta al minuto. La temperatura corrente viene scritta nel file /tmp/rodos_current_temp, dopodiché zabbix può monitorare questo file come sensore.

Il supporto di memorizzazione della configurazione viene montato nella directory /data.

Quando il sistema si avvia e lo prepara per il funzionamento, nella console viene visualizzato il seguente messaggio:

System starting, please wait

Al termine del lavoro preparatorio, cambierà nell'output dell'indirizzo IP:

current ip 192.168.1.32
Ready to work

Configurazione di zabbix per il monitoraggio della temperatura

Per monitorare la temperatura, è sufficiente eseguire 2 passaggi:

collegare il dispositivo RODOS alla porta USB
creare elementi di dati in zabbix

Apri l'interfaccia web di zabbix:

Apri la sezione Configurazione → Host
Fai clic su Articoli nella riga del nostro server zabbix
Fare clic su Crea elemento

Inserisci i seguenti dati:

il nome dipende da te (ad esempio, serverRoomTemp )
Tipo: agente zabbix
Chiave - rodi
Tipo-numerico
Unità-C
Periodo di archiviazione della cronologia - periodo di archiviazione della cronologia. lasciato 10 giorni
Periodo di archiviazione delle tendenze: periodo di archiviazione per la dinamica delle modifiche. Lasciato 30 giorni
Nuovo application server Room Temp

E premi il pulsante AGGIUNGI.

Gestisci le impostazioni tramite l'interfaccia web

L'interfaccia web è scritta in php. Ci sono funzioni principali:

visualizzare lo stato del dispositivo
modificare le impostazioni di rete
cambio password utente
selezione del fuso orario
backup/ripristino/ripristino impostazioni di fabbrica
la possibilità di collegare un'unità esterna
Aggiornamento del sistema

L'accesso all'interfaccia web è protetto da una password. Pagina iniziale - manuale.

indirizzo dell'interfaccia zabbix: ${ip/dns}/zabbix
Indirizzo dell'interfaccia di gestione: ${ip/dns}/manage

Correre 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=thread -device virtio-scsi-pci,id=scsi0 -drive file=output/images/external.qcow2,format=qcow2,aio=thread

Questo comando avvierà un sistema con 4 core, 2048 RAM, KVM abilitato, scheda di rete bridge0 e due dischi: per il sistema ed esterno per postgresql.

Le immagini possono essere convertite ed eseguite in Virtualbox:

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

Quindi importali in virtualbox e connettiti tramite sata.

conclusione

Nel processo, è diventato interessante per me realizzare un prodotto pronto per il lavoro, con un'interfaccia non molto bella (non mi piace scriverli), ma funziona ed è facile da configurare.

L'ultimo tentativo di installare zabbix-appliance in KVM ha mostrato la correttezza di questo passaggio (al termine dell'installazione, il sistema non si avvia). Forse sbaglio qualcosa 😉

materiale

https://buildroot.org/

Fonte: habr.com

Buildroot: crea firmware multipiattaforma con zabbix-server