Problemhistorie
Små bedrifter trenger på den ene siden høykvalitets overvåking av sin infrastruktur (spesielt i lys av utbredt virtualisering), på den andre siden er det økonomisk vanskelig for dem å kjøpe nytt utstyr. Server/maskinvareproblemer er også vanlig: ofte er det 1-3 tårnservere ved siden av brukerarbeidsstasjoner eller i en liten nisje/skap.
Det er lettere å bruke en ferdig sammenstilling (distribusjon), som du bare trenger å laste opp til et microSD-kort og sette inn i en vanlig enkeltbrettsdatamaskin (beaglebone, raspberry pi og orange pi-familier, asus tinker board). I tillegg er slikt utstyr billig og kan installeres hvor som helst.
Formulering av problemet
På mange måter utviklet prosjektet seg som et slags laboratoriearbeid med mulighet for å anvende resultatene.
Zabbix ble valgt som overvåkingssystem fordi det er et kraftig, gratis og godt dokumentert system.
Problemet med hardwareplattformen har blitt akutt.Å sette en egen maskin under overvåking er heller ikke en veldig god løsning - enten er det dyrt å kjøpe nytt utstyr, eller å lete etter gammelt utstyr + i små bedrifter er det hyppige problemer med server/ maskinvare.
Ved å bruke buildroot-byggesystemet kan du lage spesialiserte løsninger som kan betjenes av personell med minimal kunnskap om Linux-operativsystemer. Dette systemet er vennlig for nybegynnere, men gir samtidig store tilpasningsmuligheter i hendene på en erfaren utvikler. Den er perfekt for å løse problemet med billig, men fullt funksjonell overvåking av IT-infrastruktur, med minimale krav til opplæring av personellet som driver den.
Løsningstrinn
Det ble besluttet å opprette fastvare for x86_64 for å kjøre i qemu, siden dette er en praktisk og rask løsning for feilsøking. Porter den deretter til en enkeltarms datamaskin (jeg likte asus tinker-kortet).
buildroot ble valgt som byggesystem. I utgangspunktet mangler den zabbix-pakken, så den måtte porteres. Det var problemer med den russiske lokaliteten, som ble løst ved å bruke de riktige oppdateringene (merk: i nyere versjoner av buildroot er disse oppdateringene ikke lenger nødvendige).
Portering av selve zabbix-pakken vil bli beskrevet i en egen artikkel.
Siden alt skulle fungere som fastvare (uforanderlig systembilde + utvinnbare konfigurasjons-/databasefiler), var det nødvendig å skrive dine egne systemd-mål, tjenester og tidtakere (mål, tjeneste, timer).
Det ble besluttet å dele opp mediene i 2 seksjoner - en seksjon med systemfiler og en seksjon med skiftbare konfigurasjoner og zabbix databasefiler.
Å løse problemer knyttet til databasen viste seg å være litt vanskeligere. Jeg ønsket ikke å plassere den direkte på media. Samtidig kan størrelsen på databasen nå en størrelse som overstiger størrelsen på en mulig ramdisk. Derfor ble en kompromissløsning valgt: databasen er plassert på den andre partisjonen på SD-kortet (moderne SLC-kort har opptil 30 000 skrivesykluser), men det er en innstilling som tillater bruk av eksterne medier (for eksempel usb- hdd).
Temperaturovervåking ble implementert gjennom RODOS-5-enheten. Selvfølgelig kan du bruke Dallas 1820 direkte, men det var raskere og enklere å koble til en USB.
grub86 ble valgt som bootloader for x64_2. Det var nødvendig å skrive en minimal konfigurasjon for å starte den.
Etter feilsøking på qemu, ble den portert til asus tinker board. Strukturen til overlegget mitt var opprinnelig ment å være på tvers av plattformer - allokering av konfigurasjoner som er spesifikke for hvert bord (board defconfig, bootloader, generering av et bilde med en systempartisjon) og maksimal enhetlighet i å tilpasse filsystemet/opprette et bilde med data. På grunn av slike forberedelser gikk porteringen raskt.
Det anbefales sterkt å lese de innledende artiklene:
Slik monteres du
Etter kloning av depotet, oppnås følgende filstruktur:
[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.shbuildroot-2019.05.tar.gz - rent buildroot-arkiv
overlegg er katalogen min med eksternt-tre. Det er her alt du trenger for å bygge fastvaren med buildroot er lagret i.
README.md - prosjektbeskrivelse og manual på engelsk.
run_me.sh er et skript som forbereder byggesystemet. Utvider buildroot fra arkivet, fester et overlegg til det (via den eksterne tremekanismen) og lar deg velge måltavle for bygget
[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Select defconfig, press A for abort. Default [0]Etter dette, bare gå til buildroot-2019.05-katalogen og kjør make-kommandoen.
Når byggingen er fullført, vil alle konstruksjonsresultatene være i output/images-katalogen:
[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
updateNødvendige filer:
- sdcard.img - mediebilde for opptak på et SD-kort (via dd eller rufus under wibdows).
- qemu.qcow2 - mediebilde som skal kjøres i qemu.
- external.qcow2 - eksternt mediebilde for databasen
- monitor-0.9-beta.tar.gz - arkiv for oppdatering via webgrensesnittet
Generering av guider
Det er ikke verdt å skrive de samme instruksjonene flere ganger. Og det mest logiske er å skrive det en gang i markdown, og deretter konvertere det til PDF for nedlasting og html for webgrensesnittet. Dette er mulig takket være Pandoc-pakken.
Samtidig må alle disse filene genereres før systembildet settes sammen; disse post-build-skriptene er allerede ubrukelige. Derfor gjøres genereringen i form av en manualpakke. Du kan se på overlegg/pakke/manualer.
Manuals.mk-filen (som gjør alt arbeidet)
################################################################################
#
# 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
Linux-verdenen går aktivt over til systemd, og jeg måtte også gjøre det.
En av de hyggelige nyvinningene er tilstedeværelsen av tidtakere. Generelt blir det skrevet en egen artikkel om dem (og ikke bare om dem), men jeg skal fortelle deg kort.
Det er handlinger som må utføres med jevne mellomrom. Jeg trengte å kjøre logrotate for å fjerne lighttpd- og php-fpm-loggene. Det vanlige ville være å skrive kommandoene i cron, men jeg bestemte meg for å bruke den systemd monotone timeren. Så logrotate kjører med et strengt tidsintervall.
Selvfølgelig er det mulig å lage timere som går av på bestemte datoer, men jeg trengte ikke dette.
Eksempel på timer:
- Timer-fil
[Unit] Description=RODOS temp daemon timer
OnUnitActiveSec=1min [Installer] WantedBy=timers.target
- Файл сервиса, вызываемого таймером:
```bash
[Unit]
Description=RODOS temp daemon
[Service]
ExecStart=/usr/bin/rodos.shStøttede brett
Asus tinker board er hovedkortet som alt skal fungere på. Valgt som rimelig og veldig kraftig.
Beaglebone black er det første brettet som operasjonen ble testet på (under valg av et kraftigere brett).
Qemu x86_64 - brukes til feilsøkingsutvikling.
Slik fungerer det
Ved oppstart skjer en to-trinns gjenoppretting av innstillingene:
- kjører settings_restore-skriptet (via tjenesten). Den gjenoppretter grunnleggende systeminnstillinger - tidssone, lokalitet, nettverksinnstillinger, etc.
- kjører prepare-skriptet (via tjenesten) - her forberedes zabbix og databasen, IP-en sendes ut til konsollen.
Når du først starter den, bestemmes størrelsen på den andre partisjonen på SD-kortet. Hvis det fortsatt er uallokert plass, partisjoneres mediet på nytt, og datadelen tar opp all ledig plass. Dette gjøres for å redusere størrelsen på installasjonsbildet (sdcard.img). I tillegg opprettes postgresql arbeidskatalogen på dette tidspunktet. Derfor vil den første lanseringen med en ny transportør være lengre enn de påfølgende.
Når du kobler til en ekstern stasjon, søker den i oppstartsøyeblikket etter en ledig stasjon og formaterer den til ext4 med den eksterne etiketten.
Merk følgende! Når du kobler til en ekstern stasjon (i tillegg til å koble fra eller erstatte den), må du ta en sikkerhetskopi og gjenopprette innstillingene!
RODOS 5-enheten brukes til temperaturovervåking. Produsenten oppgir kildekoden til verktøyet for arbeid med enheten. Når systemet er slått på, starter rodos-timeren, som kjører dette verktøyet en gang i minuttet. Gjeldende temperatur skrives til filen /tmp/rodos_current_temp, hvoretter zabbix kan overvåke denne filen som en sensor.
Konfigurasjonslagringsmediet er montert i /data-katalogen.
Når du starter systemet og klargjør det for drift, vises følgende melding i konsollen:
System starting, please waitEtter å ha fullført det forberedende arbeidet, vil det endres til å vise IP-adressen:
current ip 192.168.1.32
Ready to workSette opp zabbix for temperaturovervåking
For å overvåke temperaturen, ta bare 2 trinn:
- koble RODOS-enheten til USB-porten
- opprette dataelement i zabbix
Åpne zabbix nettgrensesnitt:
- Åpne seksjonen Konfigurasjon → Verter
- Klikk på Elementer i linjen på zabbix-serveren vår
- Klikk på Opprett element
Skriv inn følgende data:
- navn - etter eget skjønn (for eksempel serverRoomTemp )
- Type - zabbix agent
- Nøkkel - Rodos
- Type-numerisk
- Enheter - C
- Historikklagringsperiode — historikklagringsperiode. igjen 10 dager
- Trendlagringsperiode – lagringsperiode for dynamikken til endringer. Gjenstående 30 dager
- Ny applikasjon - server Room Temp
Og trykk på ADD-knappen.
Administrer innstillinger via webgrensesnitt
Nettgrensesnittet er skrevet i PHP. Det er hovedfunksjoner:
- se enhetsstatus
- endre nettverksinnstillinger
- endre brukerpassord
- valg av tidssone
- sikkerhetskopiering/gjenoppretting/fabrikktilbakestilling
- muligheten til å koble til en ekstern stasjon
- System oppdatering
Innlogging til nettgrensesnittet er passordbeskyttet. Startside - manual.
Zabbix-grensesnittadresse: ${ip/dns}/zabbix
Administrasjonsgrensesnittadresse: ${ip/dns}/manage
Løper i 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 -stasjon fil=utgang/bilder/qemu.qcow2,format=qcow2,aio=tråder -enhet virtio-scsi-pci,id=scsi0 -stasjon fil=utgang/bilder/ekstern.qcow2,format=qcow2,aio=tråder
Denne kommandoen vil starte et system med 4 kjerner, 2048 RAM, KVM aktivert, et nettverkskort på bridge0 og to disker: en for systemet og en ekstern for postgresql.
Bilder kan konverteres og kjøres i Virtualbox:
qemu-img convert -f qcow2 qemu.qcow2 -O vdi qcow2.vdi
qemu-img convert -f qcow2 external.qcow2 -O vdi external.vdiImporter dem deretter til virtualbox og koble til via sata.
Konklusjon
I prosessen ble jeg interessert i å lage et ferdig-til-bruk-produkt - med et ikke veldig vakkert grensesnitt (jeg liker ikke å skrive dem), men et som fungerer og er enkelt å konfigurere.
Det siste forsøket på å installere zabbix-apparatet i KVM viste at dette trinnet var riktig (etter at installasjonen er fullført, starter ikke systemet). Kanskje jeg gjør noe galt 😉
Kilde: www.habr.com