Probleem geskiedenis
Klein maatskappye het aan die een kant hoëgehalte-monitering van hul infrastruktuur nodig (veral in die lig van wydverspreide virtualisering), aan die ander kant is dit vir hulle finansieel moeilik om nuwe toerusting aan te koop. Bediener-/hardewareprobleme is ook algemeen: daar is dikwels 1-3 toringbedieners langs gebruikerswerkstasies of in 'n klein nis/kas.
Dit is makliker om 'n klaargemaakte samestelling (verspreiding) te gebruik wat jy net na 'n microSD-kaart moet oplaai en in 'n gewone enkelbord-rekenaar (beaglebone-, raspberry pi- en oranje pi-families, asus tinker-bord) plaas. Boonop is sulke toerusting goedkoop en kan dit oral geïnstalleer word.
Probleemstelling
In baie opsigte het die projek ontwikkel as 'n soort laboratoriumwerk met die moontlikheid om die resultate toe te pas.
Zabbix is as die moniteringstelsel gekies omdat dit 'n kragtige, gratis en goed gedokumenteerde stelsel is.
Die probleem met die hardeware platform het akuut geword.Om 'n aparte masjien onder monitering te plaas is ook nie 'n baie goeie oplossing nie - of dit is duur om nuwe toerusting aan te koop, of om ou toerusting te soek + in klein maatskappye is daar gereeld probleme met bediener/ hardeware.
Deur die buildroot-boustelsel te gebruik, kan u gespesialiseerde oplossings skep wat deur personeel met minimale kennis van Linux-bedryfstelsels bedryf kan word. Hierdie stelsel is vriendelik vir beginners, maar bied terselfdertyd genoegsame aanpassingsgeleenthede in die hande van 'n ervare ontwikkelaar. Dit is perfek om die probleem van goedkoop, maar ten volle funksionele monitering van IT-infrastruktuur op te los, met minimale vereistes vir die opleiding van die personeel wat dit bedryf.
Oplossingsstappe
Daar is besluit om aanvanklik firmware vir x86_64 te skep om in qemu te loop, aangesien dit 'n gerieflike en vinnige oplossing vir ontfouting is. Dra dit dan na 'n enkelbord-rekenaar met 'n arm (ek het van die asus tinker-bord gehou).
buildroot is gekies as die boustelsel. Aanvanklik het dit nie die zabbix-pakket nie, so dit moes oorgedra word.Daar was probleme met die Russiese ligging, wat opgelos is deur die toepaslike pleisters toe te pas (let wel: in nuwer weergawes van buildroot is hierdie pleisters nie meer nodig nie).
Die oordrag van die zabbix-pakket self sal in 'n aparte artikel beskryf word.
Aangesien alles as firmware behoort te werk (onveranderbare stelselbeeld + herwinbare konfigurasie/databasislêers), was dit nodig om jou eie sisteemteikens, dienste en timers (teiken, diens, timer) te skryf.
Daar is besluit om die media in 2 afdelings te verdeel - 'n afdeling met stelsellêers en 'n afdeling met veranderlike konfigurasies en zabbix databasislêers.
Die oplossing van probleme wat met die databasis verband hou, was 'n bietjie moeiliker. Ek wou dit nie direk op die media plaas nie. Terselfdertyd kan die grootte van die databasis 'n grootte bereik wat die grootte van 'n moontlike ramdisk oorskry. Daarom is 'n kompromie-oplossing gekies: die databasis is op die tweede afdeling van die SD-kaart geleë (moderne SLC-kaarte het tot 30 000 skryfsiklusse), maar daar is 'n instelling wat die gebruik van eksterne media toelaat (byvoorbeeld usb- hdd).
Temperatuurmonitering is deur die RODOS-5-toestel geïmplementeer. Natuurlik kan jy die Dallas 1820 direk gebruik, maar dit was vinniger en makliker om 'n USB aan te sluit.
grub86 is gekies as die selflaaiprogram vir x64_2. Dit was nodig om 'n minimale konfigurasie te skryf om dit te begin.
Nadat dit op qemu ontfout is, is dit na die asus-tinkbord oorgedra. Die struktuur van my oorleg was aanvanklik bedoel om kruisplatform te wees - toekenning van konfigurasies spesifiek aan elke bord (board defconfig, selflaaiprogram, generering van 'n prent met 'n stelselpartisie) en maksimum eenvormigheid in die pasmaak van die lêerstelsel / die skep van 'n prent met data. As gevolg van sulke voorbereiding het portering vinnig verloop.
Dit word sterk aanbeveel om die inleidende artikels te lees:
Hoe om te vergader
Nadat die bewaarplek gekloon is, word die volgende lêerstruktuur verkry:
[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.shbuildroot-2019.05.tar.gz - maak die bouwortel-argief skoon
overlay is my gids met eksterne-boom. Dit is waar alles wat jy nodig het om die firmware te bou met buildroot gestoor word.
README.md - beskrywing van die projek en handleiding in Engels.
run_me.sh is 'n skrip wat die boustelsel voorberei. Brei bouwortel uit die argief uit, heg 'n oorleg daaraan (via die eksterne boommeganisme) en laat jou toe om die teikenbord vir samestelling te kies
[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Select defconfig, press A for abort. Default [0]Hierna, gaan net na die buildroot-2019.05-gids en voer die make-opdrag uit.
Sodra die bou voltooi is, sal al die bouresultate in die uitvoer/beelde-gids wees:
[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
updateVereiste lêers:
- sdcard.img - mediabeeld vir opname op 'n SD-kaart (via dd of rufus onder wibdows).
- qemu.qcow2 - mediabeeld om in qemu uit te voer.
- external.qcow2 - eksterne media beeld vir die databasis
- monitor-0.9-beta.tar.gz - argief vir opdatering via die webkoppelvlak
Generasie van gidse
Dit is nie die moeite werd om dieselfde instruksies verskeie kere te skryf nie. En die mees logiese ding is om dit een keer in markdown te skryf, en dan om te skakel na PDF vir aflaai en html vir die webkoppelvlak. Dit is moontlik danksy die Pandoc-pakket.
Terselfdertyd moet al hierdie lêers gegenereer word voordat die stelselbeeld saamgestel word; daardie post-bou-skrifte is reeds nutteloos. Daarom word die generering in die vorm van 'n handleidingpakket gedoen. Jy kan kyk na oorleg/pakket/handleidings.
Die manuals.mk-lêer (wat al die werk doen)
################################################################################
#
# 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
Die Linux-wêreld beweeg aktief na systemd, en ek moes dit ook doen.
Een van die aangename innovasies is die teenwoordigheid van timers. Oor die algemeen word 'n aparte artikel oor hulle geskryf (en nie net oor hulle nie), maar ek sal jou kortliks vertel.
Daar is aksies wat periodiek uitgevoer moet word. Ek moes logrotate hardloop om die lighttpd en php-fpm logs skoon te maak. Die gewone ding sou wees om die opdragte in cron te skryf, maar ek het besluit om die systemd monotoniese timer te gebruik. Logrotate loop dus met 'n streng tydsinterval.
Dit is natuurlik moontlik om timers te skep wat op sekere datums brand, maar ek het dit nie nodig gehad nie.
Timer voorbeeld:
- Timer lêer
[Unit] Description=RODOS temp daemon timer
OnUnitActiveSec=1min [Install] WantedBy=timers.target
- Файл сервиса, вызываемого таймером:
```bash
[Unit]
Description=RODOS temp daemon
[Service]
ExecStart=/usr/bin/rodos.shOndersteunde borde
Asus tinkerbord is die hoofbord waarop alles moet werk. Gekies as goedkoop en baie kragtig.
Beaglebone black is die eerste bord waarop die werking getoets is (tydens die keuse van 'n kragtiger bord).
Qemu x86_64 - gebruik vir ontfouting ontwikkeling.
Hoe werk dit?
By opstart vind 'n twee-fase herstel van instellings plaas:
- hardloop die settings_restore script (via die diens). Dit herstel basiese stelselinstellings - tydsone, plek, netwerkinstellings, ens.
- hardloop die voorbereidingskrip (via die diens) - hier word zabbix en die databasis voorberei, die IP word na die konsole uitgevoer.
Wanneer jy dit die eerste keer begin, word die grootte van die tweede partisie van die SD-kaart bepaal. As daar nog nie-toegewysde spasie is, word die media herpartisioneer, en die data-afdeling neem al die vrye spasie op. Dit word gedoen om die grootte van die installasiebeeld (sdcard.img) te verminder. Boonop word die postgresql-werkgids op hierdie punt geskep. Daarom sal die eerste bekendstelling met 'n nuwe draer langer as daaropvolgendes wees.
Wanneer 'n eksterne skyf gekoppel word, soek dit op die oomblik van opstart na 'n gratis skyf en formateer dit in ext4 met die eksterne etiket.
Aandag! Wanneer jy 'n eksterne skyf koppel (sowel as jy dit ontkoppel of vervang), moet jy 'n rugsteun maak en die instellings herstel!
Die RODOS 5-toestel word gebruik vir temperatuurmonitering. Die vervaardiger verskaf die bronkode van sy nut om met die toestel te werk. Wanneer die stelsel aangeskakel word, begin die rodos-timer, wat hierdie nutsprogram een keer per minuut laat loop. Die huidige temperatuur word na die lêer /tmp/rodos_current_temp geskryf, waarna zabbix hierdie lêer as 'n sensor kan monitor.
Die konfigurasiebergingsmedia is in die /data-gids gemonteer.
Wanneer die stelsel begin en voorberei word vir werking, verskyn die volgende boodskap in die konsole:
System starting, please waitNadat die voorbereidende werk voltooi is, sal dit verander na die vertoon van die IP-adres:
current ip 192.168.1.32
Ready to workStel zabbix op vir temperatuurmonitering
Om die temperatuur te monitor, neem net 2 stappe:
- koppel die RODOS-toestel aan die USB-poort
- skep data-item in zabbix
Maak die zabbix-webkoppelvlak oop:
- Maak die afdeling Konfigurasie → Gashere oop
- Klik op Items in die lyn van ons zabbix-bediener
- Klik op Skep item
Voer die volgende data in:
- naam - na goeddunke (byvoorbeeld, serverRoomTemp )
- Tipe - zabbix agent
- Sleutel - Rodos
- Tipe-numeries
- Eenhede - C
- Geskiedenisbergingstydperk — geskiedenisbergingstydperk. oor 10 dae
- Tendensbergingstydperk—bergingstydperk vir die dinamika van veranderinge. 30 dae oor
- Nuwe toepassing - bediener Kamer Temp
En druk die ADD-knoppie.
Bestuur instellings via webkoppelvlak
Die webkoppelvlak is in PHP geskryf. Daar is hooffunksies:
- bekyk toestelstatus
- netwerkinstellings te verander
- gebruikerswagwoord verander
- tydsone keuse
- rugsteun/herstel/fabriekterugstelling
- vermoë om 'n eksterne skyf aan te sluit
- Stelsel opdatering
Aanmelding by die webkoppelvlak is wagwoordbeskerm. Begin bladsy - handleiding.
Zabbix-koppelvlakadres: ${ip/dns}/zabbix
Bestuurskoppelvlakadres: ${ip/dns}/manage
Hardloop in qemu
qemu-system-x86_64 -smp 4 -m 4026M -enable-kvm -masjien q35,accel=kvm -device intel-iommu -cpu host -net nic -net bridge,br=bridge0 -device virtio-scsi-pci,id= scsi0 -aandrywing lêer=afvoer/beelde/qemu.qcow2,formaat=qcow2,aio=drade -apparaat virtio-scsi-pci,id=scsi0 -aandrywer lêer=afvoer/beelde/ekstern.qcow2,formaat=qcow2,aio=drade
Hierdie opdrag sal 'n stelsel met 4 kerns, 2048 RAM, KVM geaktiveer, 'n netwerkkaart op bridge0 en twee skywe begin: een vir die stelsel en een ekstern vir postgresql.
Prente kan omgeskakel en in Virtualbox uitgevoer word:
qemu-img convert -f qcow2 qemu.qcow2 -O vdi qcow2.vdi
qemu-img convert -f qcow2 external.qcow2 -O vdi external.vdiVoer hulle dan in virtualbox in en koppel via sata.
Gevolgtrekking
In die proses het ek begin belangstel om 'n gereed-vir-gebruik-produk te maak - met 'n nie baie mooi koppelvlak nie (ek hou nie daarvan om dit te skryf nie), maar een wat werk en maklik is om te konfigureer.
Die laaste poging om zabbix-toestel in KVM te installeer het getoon dat hierdie stap korrek was (nadat die installasie voltooi is, begin die stelsel nie). Miskien doen ek iets verkeerd 😉
Bron: will.com