Istoricul problemelor
Companiile mici, pe de o parte, au nevoie de o monitorizare de înaltă calitate a infrastructurii lor (în special în lumina virtualizării pe scară largă), pe de altă parte, le este dificil din punct de vedere financiar să achiziționeze echipamente noi. Problemele de server/hardware sunt, de asemenea, frecvente: adesea există 1-3 servere turn lângă stațiile de lucru ale utilizatorilor sau într-o nișă/dulap mic.
Este mai ușor să utilizați un ansamblu gata făcut (distribuție), pe care trebuie doar să îl încărcați pe un card microSD și să îl introduceți într-un computer obișnuit cu o singură placă (familiile beaglebone, raspberry pi și orange pi, placa asus tinker). În plus, un astfel de echipament este ieftin și poate fi instalat oriunde.
Declarație de problemă
În multe privințe, proiectul s-a dezvoltat ca un fel de lucru de laborator cu posibilitatea de a aplica rezultatele.
Zabbix a fost ales ca sistem de monitorizare deoarece este un sistem puternic, gratuit și bine documentat.
Problema cu platforma hardware a devenit acută Punerea unei mașini separate sub monitorizare, de asemenea, nu este o soluție foarte bună - fie este costisitor să achiziționați echipamente noi, fie să căutați echipamente vechi + în companiile mici apar probleme frecvente cu serverul/. hardware.
Utilizarea sistemului de compilare buildroot vă permite să creați soluții specializate care pot fi operate de personal cu cunoștințe minime despre sistemele de operare Linux. Acest sistem este prietenos pentru începători, dar oferă în același timp oportunități ample de personalizare în mâinile unui dezvoltator experimentat. Este perfect pentru rezolvarea problemei monitorizării ieftine, dar complet funcționale a infrastructurii IT, cu cerințe minime pentru pregătirea personalului care o operează.
Etape de rezolvare
S-a decis inițial să se creeze firmware pentru ca x86_64 să ruleze în qemu, deoarece aceasta este o soluție convenabilă și rapidă pentru depanare. Apoi porți-l pe un computer cu un singur braț (mi-a plăcut placa Asus Tinker).
buildroot a fost selectat ca sistem de construcție. Inițial, îi lipsește pachetul zabbix, așa că a trebuit să fie portat Au existat probleme cu localul rus, care au fost rezolvate prin aplicarea patch-urilor corespunzătoare (notă: în versiunile mai noi de buildroot, aceste patch-uri nu mai sunt necesare).
Portarea pachetului zabbix în sine va fi descrisă într-un articol separat.
Deoarece totul ar trebui să funcționeze ca firmware (imagine de sistem neschimbabilă + fișiere de configurare/bază de date recuperabile), a fost necesar să scrieți propriile ținte, servicii și cronometre de sistem (țintă, serviciu, temporizator).
S-a decis împărțirea media în 2 secțiuni - o secțiune cu fișiere de sistem și o secțiune cu configurații modificabile și fișiere de bază de date zabbix.
Rezolvarea problemelor legate de baza de date s-a dovedit a fi puțin mai dificilă. Nu am vrut să-l plasez direct pe mass-media. În același timp, dimensiunea bazei de date poate atinge o dimensiune care depășește dimensiunea unui posibil ramdisk. Prin urmare, s-a ales o soluție de compromis: baza de date se află pe a doua partiție a cardului SD (cardurile SLC moderne au până la 30 de cicluri de scriere), dar există o setare care permite utilizarea mediilor externe (de exemplu, usb- hdd).
Monitorizarea temperaturii a fost implementată prin intermediul dispozitivului RODOS-5. Desigur, puteți utiliza direct Dallas 1820, dar a fost mai rapid și mai ușor să conectați un USB.
grub86 a fost selectat ca bootloader pentru x64_2. A fost necesar să scrieți o configurație minimă pentru a o lansa.
După depanarea pe qemu, acesta a fost portat pe placa asus tinker. Structura suprapunerii mele a fost inițial destinată să fie cross-platform - alocarea de configurații specifice fiecărei plăci (board defconfig, bootloader, generarea unei imagini cu o partiție de sistem) și uniformitate maximă în personalizarea sistemului de fișiere/crearea unei imagini cu date. Datorită unei astfel de pregătiri, portarea a mers rapid.
Este foarte recomandat să citiți articolele introductive:
Cum se asamblează
După clonarea depozitului, se obține următoarea structură de fișiere:
[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.shbuildroot-2019.05.tar.gz - curăță arhiva buildroot
overlay este directorul meu cu external-tree. Aici este stocat tot ce aveți nevoie pentru a construi firmware-ul folosind buildroot.
README.md - descrierea proiectului și manualul în limba engleză.
run_me.sh este un script care pregătește sistemul de construire. Extinde buildroot din arhivă, îi atașează o suprapunere (prin intermediul mecanismului de arbore extern) și vă permite să selectați placa țintă pentru asamblare
[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Select defconfig, press A for abort. Default [0]După aceasta, mergeți la directorul buildroot-2019.05 și rulați comanda make.
Odată ce construirea este completă, toate rezultatele construcției vor fi în directorul de ieșire/imagini:
[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
updateFișiere necesare:
- sdcard.img - imagine media pentru înregistrarea pe un card SD (prin dd sau rufus sub wibdows).
- qemu.qcow2 - imagine media de rulat în qemu.
- external.qcow2 - imagine media externă pentru baza de date
- monitor-0.9-beta.tar.gz - arhivă pentru actualizare prin interfața web
Generarea Ghidurilor
Nu merită să scrieți aceleași instrucțiuni de mai multe ori. Și cel mai logic lucru este să îl scrieți o dată în markdown, apoi să îl convertiți în PDF pentru descărcare și html pentru interfața web. Acest lucru este posibil datorită pachetului pandoc.
În același timp, toate aceste fișiere trebuie generate înainte ca imaginea sistemului să fie asamblată, acele scripturi post-build sunt deja inutile. Prin urmare, generarea se face sub forma unui pachet de manuale. Puteți să vă uitați la suprapunere/pachet/manuale.
Fișierul manuals.mk (care face toată treaba)
################################################################################
#
# 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
Lumea Linux se mută activ la systemd și a trebuit să o fac și eu.
Una dintre inovațiile plăcute este prezența cronometrelor. În general, se scrie un articol separat despre ei (și nu numai despre ei), dar vă voi spune pe scurt.
Sunt acțiuni care trebuie efectuate periodic. Trebuia să rulez logrotate pentru a șterge jurnalele lighttpd și php-fpm. Lucrul obișnuit ar fi să scriu comenzile în cron, dar am decis să folosesc cronometrul monoton systemd. Deci logrotate rulează la un interval de timp strict.
Desigur, este posibil să creez cronometre care se declanșează la anumite date, dar nu aveam nevoie de asta.
Exemplu de cronometru:
- Fișier temporizator
[Unit] Description=RODOS temp daemon timer
OnUnitActiveSec=1min [Instalare] WantedBy=timers.target
- Файл сервиса, вызываемого таймером:
```bash
[Unit]
Description=RODOS temp daemon
[Service]
ExecStart=/usr/bin/rodos.shPlaci suportate
Placa Asus tinker este placa principală pe care ar trebui să funcționeze totul. Selectat ca ieftin și foarte puternic.
Beaglebone black este prima placă pe care a fost testată funcționarea (în timpul selecției unei plăci mai puternice).
Qemu x86_64 - folosit pentru dezvoltarea de depanare.
Cum funcționează
La pornire, are loc o restaurare în două etape a setărilor:
- rulează scriptul settings_restore (prin serviciu). Restabilește setările de bază ale sistemului - fus orar, local, setări de rețea etc.
- rulează scriptul de pregătire (prin intermediul serviciului) - aici sunt pregătite zabbix și baza de date, IP-ul este scos la consolă.
Când îl porniți pentru prima dată, este determinată dimensiunea celei de-a doua partiții a cardului SD. Dacă încă mai există spațiu nealocat, media este repartiționată, iar secțiunea de date ocupă tot spațiul liber. Acest lucru se face pentru a reduce dimensiunea imaginii de instalare (sdcard.img). În plus, directorul de lucru postgresql este creat în acest moment. De aceea, prima lansare cu un transportator nou va dura mai mult decât cele ulterioare.
Când conectează o unitate externă, în momentul pornirii, caută o unitate liberă și o formatează în ext4 cu eticheta externă.
Atenţie! Când conectați o unitate externă (precum și o deconectați sau o înlocuiți), trebuie să faceți o copie de rezervă și să restaurați setările!
Dispozitivul RODOS 5 este utilizat pentru monitorizarea temperaturii Producătorul furnizează codul sursă al utilitarului său pentru lucrul cu dispozitivul. Când porniți sistemul, pornește cronometrul rodos, care rulează acest utilitar o dată pe minut. Temperatura curentă este scrisă în fișierul /tmp/rodos_current_temp, după care zabbix poate monitoriza acest fișier ca senzor.
Suportul de stocare al configurației este montat în directorul /data.
Când porniți sistemul și îl pregătiți pentru funcționare, în consolă apare următorul mesaj:
System starting, please waitDupă finalizarea lucrărilor pregătitoare, se va schimba în afișarea adresei IP:
current ip 192.168.1.32
Ready to workConfigurarea zabbix pentru monitorizarea temperaturii
Pentru a monitoriza temperatura, faceți doar 2 pași:
- conectați dispozitivul RODOS la portul USB
- creați element de date în zabbix
Deschideți interfața web zabbix:
- Deschideți secțiunea Configurare → Gazde
- Faceți clic pe Elemente din linia serverului nostru zabbix
- Faceți clic pe Creare element
Introduceți următoarele date:
- nume - la discreția dvs. (de exemplu, serverRoomTemp )
- Tip - agent zabbix
- Cheie - Rodos
- Tip numeric
- Unități - C
- History storage period — perioada de stocare a istoricului. a ramas 10 zile
- Perioada de stocare a tendințelor — perioadă de stocare pentru dinamica modificărilor. Au mai rămas 30 de zile
- Aplicație nouă - Temp. cameră server
Și apăsați butonul ADAUGĂ.
Gestionați setările prin interfața web
Interfața web este scrisă în PHP. Există funcții principale:
- vizualizați starea dispozitivului
- modificarea setărilor de rețea
- schimbarea parolei utilizatorului
- selectarea fusului orar
- backup/restaurare/resetare din fabrică
- capacitatea de a conecta o unitate externă
- Actualizare de sistem
Conectarea la interfața web este protejată prin parolă. Pagina de pornire - manual.
Adresa interfeței Zabbix: ${ip/dns}/zabbix
Adresa interfeței de gestionare: ${ip/dns}/manage
Rulează în 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
Această comandă va porni un sistem cu 4 nuclee, 2048 RAM, KVM activat, o placă de rețea pe bridge0 și două discuri: unul pentru sistem și unul extern pentru postgresql.
Imaginile pot fi convertite și rulate în Virtualbox:
qemu-img convert -f qcow2 qemu.qcow2 -O vdi qcow2.vdi
qemu-img convert -f qcow2 external.qcow2 -O vdi external.vdiApoi importați-le în virtualbox și conectați-vă prin sata.
Concluzie
Pe parcursul procesului, am devenit interesat să fac un produs gata de utilizare - cu o interfață nu foarte frumoasă (nu-mi place să le scriu), dar una care funcționează și este ușor de configurat.
Ultima încercare de a instala zabbix-appliance în KVM a arătat că acest pas a fost corect (după finalizarea instalării, sistemul nu pornește). Poate că fac ceva greșit 😉
Sursa: www.habr.com