Problemhistorie
Små virksomheder har på den ene side brug for overvågning af høj kvalitet af deres infrastruktur (især i lyset af udbredt virtualisering), på den anden side er det økonomisk vanskeligt for dem at købe nyt udstyr. Server/hardware problemer er også almindelige: ofte er der 1-3 tårnservere ved siden af brugerens arbejdsstationer eller i en lille niche/skab.
Det er nemmere at bruge en færdiglavet samling (distribution), som du bare skal uploade til et microSD-kort og indsætte i en almindelig single-board computer (beaglebone, raspberry pi og orange pi familier, asus tinker board). Derudover er sådant udstyr billigt og kan installeres hvor som helst.
Formulering af problemet
Projektet udviklede sig på mange måder som en slags laboratoriearbejde med mulighed for at anvende resultaterne.
Zabbix blev valgt som overvågningssystem, fordi det er et kraftfuldt, gratis og veldokumenteret system.
Problemet med hardwareplatformen er blevet akut, At sætte en separat maskine under overvågning er heller ikke en særlig god løsning - enten er det dyrt at anskaffe nyt udstyr, eller at lede efter gammelt udstyr + i små virksomheder er der hyppige problemer med server/ hardware.
Ved at bruge buildroot-byggesystemet kan du skabe specialiserede løsninger, der kan betjenes af personale med minimal viden om Linux-operativsystemer. Dette system er venligt for begyndere, men giver samtidig rigelige tilpasningsmuligheder i hænderne på en erfaren udvikler. Det er perfekt til at løse problemet med billig, men fuldt funktionel overvågning af it-infrastruktur, med minimale krav til uddannelse af personalet, der driver den.
Løsningstrin
Det blev besluttet i første omgang at oprette firmware til x86_64 til at køre i qemu, da dette er en bekvem og hurtig løsning til fejlfinding. Port den derefter til en enkeltarmscomputer (jeg kunne godt lide asus tinker-kortet).
buildroot blev valgt som byggesystemet. I starten mangler den zabbix-pakken, så den skulle porteres. Der var problemer med den russiske lokalitet, som blev løst ved at anvende de passende patches (bemærk: i nyere versioner af buildroot er disse patches ikke længere nødvendige).
Portering af selve zabbix-pakken vil blive beskrevet i en separat artikel.
Da alt skulle fungere som firmware (uforanderligt systembillede + gendanbare konfigurations-/databasefiler), var det nødvendigt at skrive dine egne systemd targets, services og timere (target, service, timer).
Det blev besluttet at opdele mediet i 2 sektioner - en sektion med systemfiler og en sektion med udskiftelige konfigurationer og zabbix-databasefiler.
At løse problemer relateret til databasen viste sig at være lidt sværere. Jeg ville ikke placere det direkte på medierne. Samtidig kan størrelsen af databasen nå en størrelse, der overstiger størrelsen af en mulig ramdisk. Derfor blev der valgt en kompromisløsning: databasen er placeret på den anden sektion af SD-kortet (moderne SLC-kort har op til 30 skrivecyklusser), men der er en indstilling, der tillader brug af eksterne medier (f.eks. usb- hdd).
Temperaturovervågning blev implementeret gennem RODOS-5-enheden. Selvfølgelig kan du bruge Dallas 1820 direkte, men det var hurtigere og nemmere at tilslutte en USB.
grub86 blev valgt som bootloader til x64_2. Det var nødvendigt at skrive en minimal konfiguration for at starte den.
Efter debugging på qemu, blev det overført til asus tinker board. Strukturen af mit overlay var oprindeligt beregnet til at være på tværs af platforme - tildeling af konfigurationer, der er specifikke for hvert board (board defconfig, bootloader, generering af et billede med en systempartition) og maksimal ensartethed i tilpasning af filsystemet/oprettelse af et billede med data. På grund af sådan forberedelse gik porteringen hurtigt.
Det kan varmt anbefales at læse de indledende artikler:
Sådan samles
Efter kloning af depotet opnå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
overlay er min mappe med eksternt træ. Det er her alt hvad du behøver for at bygge firmwaren ved hjælp af buildroot er gemt i.
README.md - beskrivelse af projektet og manual på engelsk.
run_me.sh er et script, der forbereder byggesystemet. Udvider buildroot fra arkivet, vedhæfter et overlay til det (via den eksterne træmekanisme) og giver dig mulighed for at vælge målbrættet til samling
[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Select defconfig, press A for abort. Default [0]Efter dette skal du bare gå til buildroot-2019.05-mappen og køre make-kommandoen.
Når opbygningen er færdig, vil alle byggeresultater være i mappen 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
updateNødvendige filer:
- sdcard.img - mediebillede til optagelse på et SD-kort (via dd eller rufus under wibdows).
- qemu.qcow2 - mediebillede til at køre i qemu.
- external.qcow2 - eksternt mediebillede til databasen
- monitor-0.9-beta.tar.gz - arkiv til opdatering via webgrænsefladen
Generering af guider
Det er ikke værd at skrive de samme instruktioner flere gange. Og det mest logiske er at skrive det én gang i markdown, og derefter konvertere det til PDF til download og html til webgrænsefladen. Dette er muligt takket være Pandoc-pakken.
Samtidig skal alle disse filer genereres, før systembilledet samles; disse post-build scripts er allerede ubrugelige. Derfor sker genereringen i form af en manualpakke. Du kan se på overlay/pakke/manualer.
Manuals.mk filen (som gør alt arbejdet)
################################################################################
#
# 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 bevæger sig aktivt til systemd, og jeg var også nødt til at gøre det.
En af de behagelige innovationer er tilstedeværelsen af timere. Generelt bliver der skrevet en separat artikel om dem (og ikke kun om dem), men jeg vil fortælle dig kort.
Der er handlinger, der skal udføres med jævne mellemrum. Jeg var nødt til at køre logrotate for at rydde lighttpd- og php-fpm-logfilerne. Det sædvanlige ville være at skrive kommandoerne i cron, men jeg besluttede at bruge den systemd monotone timer. Så logrotate kører med et strengt tidsinterval.
Det er selvfølgelig muligt at lave timere, der udløses på bestemte datoer, men det havde jeg ikke brug for.
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.shUnderstøttede tavler
Asus tinker board er hovedkortet, hvor alt skal fungere. Udvalgt som billig og meget kraftfuld.
Beaglebone black er det første bræt, hvor operationen blev testet (under valget af et kraftigere bræt).
Qemu x86_64 - bruges til debugging udvikling.
Sådan virker det
Ved opstart sker en to-trins gendannelse af indstillinger:
- kører settings_restore-scriptet (via tjenesten). Det gendanner grundlæggende systemindstillinger - tidszone, lokalitet, netværksindstillinger osv.
- kører prepare scriptet (via tjenesten) - her forberedes zabbix og databasen, IP'en udsendes til konsollen.
Når du starter det første gang, bestemmes størrelsen af den anden partition på SD-kortet. Hvis der stadig er ikke-allokeret plads, ompartitioneres mediet, og datasektionen optager al den ledige plads. Dette gøres for at reducere størrelsen af installationsbilledet (sdcard.img). Derudover oprettes postgresql-arbejdsmappen på dette tidspunkt. Derfor vil den første lancering med en ny transportør være længere end de efterfølgende.
Når du tilslutter et eksternt drev, søger det i opstartsøjeblikket efter et ledigt drev og formaterer det til ext4 med den eksterne etiket.
Opmærksomhed! Når du tilslutter et eksternt drev (samt afbrydelse eller udskiftning af det), skal du lave en sikkerhedskopi og gendanne indstillingerne!
RODOS 5-enheden bruges til temperaturovervågning. Producenten leverer kildekoden til dets hjælpeprogram til at arbejde med enheden. Når systemet er tændt, starter rodos-timeren, som kører dette værktøj en gang i minuttet. Den aktuelle temperatur skrives til filen /tmp/rodos_current_temp, hvorefter zabbix kan overvåge denne fil som en sensor.
Konfigurationslagermediet er monteret i mappen /data.
Når du starter systemet og gør det klar til drift, vises følgende meddelelse i konsollen:
System starting, please waitEfter at have afsluttet det forberedende arbejde, vil det skifte til at vise IP-adressen:
current ip 192.168.1.32
Ready to workOpsætning af zabbix til temperaturovervågning
For at overvåge temperaturen skal du blot tage 2 trin:
- tilslut RODOS-enheden til USB-porten
- oprette dataelement i zabbix
Åbn zabbix-webgrænsefladen:
- Åbn afsnittet Konfiguration → Værter
- Klik på Elementer i linjen på vores zabbix-server
- Klik på Opret element
Indtast følgende data:
- navn - efter eget skøn (f.eks. serverRoomTemp )
- Type - zabbix agent
- Nøgle - Rodos
- Type-numerisk
- Enheder - C
- Historik lagringsperiode — historik lagringsperiode. tilbage 10 dage
- Trendlagringsperiode – lagerperiode for ændringers dynamik. 30 dage tilbage
- Ny applikation - server Rumtemp
Og tryk på knappen TILFØJ.
Administrer indstillinger via webgrænseflade
Webgrænsefladen er skrevet i PHP. Der er hovedfunktioner:
- se enhedens status
- ændring af netværksindstillinger
- ændring af brugeradgangskode
- valg af tidszone
- backup/gendannelse/gendannelse af fabriksindstillinger
- mulighed for at tilslutte et eksternt drev
- Systemopdatering
Login til webgrænsefladen er beskyttet med adgangskode. Startside - manual.
Zabbix-grænsefladeadresse: ${ip/dns}/zabbix
Administrationsgrænsefladeadresse: ${ip/dns}/manage
Løber 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 -drev fil=output/billeder/qemu.qcow2,format=qcow2,aio=tråde -enhed virtio-scsi-pci,id=scsi0 -drev fil=output/billeder/ekstern.qcow2,format=qcow2,aio=tråde
Denne kommando starter et system med 4 kerner, 2048 RAM, KVM aktiveret, et netværkskort på bridge0 og to diske: en til systemet og en ekstern til postgresql.
Billeder kan konverteres og kø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 derefter til virtualbox og tilslut via sata.
Konklusion
I processen blev jeg interesseret i at lave et produkt, der er klar til brug - med en ikke særlig smuk grænseflade (jeg kan ikke lide at skrive dem), men en der virker og er nem at konfigurere.
Det sidste forsøg på at installere zabbix-apparatet i KVM viste, at dette trin var korrekt (efter at installationen er afsluttet, starter systemet ikke). Måske gør jeg noget forkert 😉
Kilde: www.habr.com