Problemgeschichte
Einerseits benötigen kleine Unternehmen eine qualitativ hochwertige Überwachung ihrer Infrastruktur (insbesondere angesichts der weit verbreiteten Virtualisierung), andererseits ist es für sie finanziell schwierig, neue Geräte anzuschaffen. Auch Server-/Hardwareprobleme kommen häufig vor: Oft stehen 1-3 Tower-Server neben Benutzerarbeitsplätzen oder in einer kleinen Nische/einem Schrank.
Es ist einfacher, eine vorgefertigte Baugruppe (Distribution) zu verwenden, die Sie nur auf eine microSD-Karte hochladen und in einen gängigen Einplatinencomputer (Beaglebone-, Raspberry Pi- und Orange Pi-Familien, Asus Tinker Board) einsetzen müssen. Darüber hinaus sind solche Geräte kostengünstig und können überall installiert werden.
Formulierung des Problems
Das Projekt entwickelte sich in vielerlei Hinsicht zu einer Art Laborarbeit mit der Möglichkeit, die Ergebnisse anzuwenden.
Als Überwachungssystem wurde Zabbix ausgewählt, da es sich um ein leistungsstarkes, kostenloses und gut dokumentiertes System handelt.
Das Problem mit der Hardwareplattform ist akut geworden. Auch die Überwachung einer separaten Maschine ist keine sehr gute Lösung – entweder ist die Anschaffung neuer Geräte teuer oder die Suche nach alten Geräten + in kleinen Unternehmen gibt es häufig Probleme mit Servern/ Hardware.
Mithilfe des Buildroot-Buildsystems können Sie spezielle Lösungen erstellen, die von Personal mit minimalen Kenntnissen über Linux-Betriebssysteme bedient werden können. Dieses System ist für Anfänger geeignet, bietet aber gleichzeitig in den Händen eines erfahrenen Entwicklers zahlreiche Anpassungsmöglichkeiten. Es eignet sich perfekt zur Lösung des Problems einer kostengünstigen, aber voll funktionsfähigen Überwachung der IT-Infrastruktur mit minimalen Anforderungen an die Schulung des Bedienpersonals.
Lösungsschritte
Es wurde beschlossen, zunächst Firmware für x86_64 für die Ausführung in qemu zu erstellen, da dies eine bequeme und schnelle Lösung zum Debuggen ist. Portieren Sie es dann auf einen Arm-Einplatinencomputer (ich mochte das Asus-Tinker-Board).
Als Buildsystem wurde buildroot ausgewählt. Zunächst fehlte das Zabbix-Paket, daher musste es portiert werden. Es gab Probleme mit dem russischen Gebietsschema, die durch die Anwendung der entsprechenden Patches behoben wurden (Hinweis: In neueren Versionen von Buildroot werden diese Patches nicht mehr benötigt).
Die Portierung des Zabbix-Pakets selbst wird in einem separaten Artikel beschrieben.
Da alles als Firmware funktionieren sollte (unveränderliches Systemabbild + wiederherstellbare Konfigurations-/Datenbankdateien), war es notwendig, eigene Systemd-Ziele, Dienste und Timer (Ziel, Dienst, Timer) zu schreiben.
Es wurde beschlossen, die Medien in zwei Abschnitte aufzuteilen – einen Abschnitt mit Systemdateien und einen Abschnitt mit veränderbaren Konfigurationen und Zabbix-Datenbankdateien.
Etwas schwieriger gestaltete sich die Lösung von Problemen im Zusammenhang mit der Datenbank. Ich wollte es nicht direkt auf den Medien platzieren. Gleichzeitig kann die Größe der Datenbank eine Größe erreichen, die die Größe einer möglichen Ramdisk übersteigt. Daher wurde eine Kompromisslösung gewählt: Die Datenbank befindet sich auf dem zweiten Abschnitt der SD-Karte (moderne SLC-Karten haben bis zu 30 Schreibzyklen), es gibt jedoch eine Einstellung, die die Verwendung externer Medien (z. B. USB-Sticks) ermöglicht. Festplatte).
Die Temperaturüberwachung wurde über das RODOS-5-Gerät implementiert. Natürlich kann man den Dallas 1820 auch direkt verwenden, aber schneller und einfacher ging es, einen USB-Anschluss anzuschließen.
Als Bootloader für x86_64 wurde grub2 ausgewählt. Es war notwendig, eine minimale Konfiguration zu schreiben, um es zu starten.
Nach dem Debuggen auf qemu wurde es auf das Asus-Tinker-Board portiert. Die Struktur meines Overlays sollte ursprünglich plattformübergreifend sein – Zuweisung spezifischer Konfigurationen für jedes Board (Board-Defconfig, Bootloader, Generieren eines Images mit einer Systempartition) und maximale Einheitlichkeit bei der Anpassung des Dateisystems/Erstellung eines Images mit Daten. Aufgrund dieser Vorbereitung ging die Portierung schnell vonstatten.
Es wird dringend empfohlen, die Einführungsartikel zu lesen:
Montageanleitung
Nach dem Klonen des Repositorys wird die folgende Dateistruktur erhalten:
[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.shbuildroot-2019.05.tar.gz – bereinigtes Buildroot-Archiv
Overlay ist mein Verzeichnis mit external-tree. Hier ist alles gespeichert, was Sie zum Erstellen der Firmware mit Buildroot benötigen.
README.md – Beschreibung des Projekts und Handbuch auf Englisch.
run_me.sh ist ein Skript, das das Build-System vorbereitet. Erweitert Buildroot aus dem Archiv, fügt ein Overlay hinzu (über den External-Tree-Mechanismus) und ermöglicht Ihnen die Auswahl der Zielplatine für die Montage
[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Select defconfig, press A for abort. Default [0]Gehen Sie danach einfach in das Verzeichnis buildroot-2019.05 und führen Sie den Befehl make aus.
Sobald der Build abgeschlossen ist, befinden sich alle Build-Ergebnisse im Verzeichnis „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
updateErforderliche Dateien:
- sdcard.img – Medienbild zum Aufzeichnen auf einer SD-Karte (über dd oder rufus unter wibdows).
- qemu.qcow2 – Medienbild zur Ausführung in qemu.
- external.qcow2 – externes Medienbild für die Datenbank
- monitor-0.9-beta.tar.gz – Archiv zur Aktualisierung über die Weboberfläche
Generierung von Reiseführern
Es lohnt sich nicht, dieselben Anweisungen mehrmals zu schreiben. Und am logischsten ist es, es einmal im Markdown zu schreiben und es dann zum Herunterladen in PDF und für die Weboberfläche in HTML zu konvertieren. Dies ist dank des Pandoc-Pakets möglich.
Gleichzeitig müssen alle diese Dateien generiert werden, bevor das Systemabbild zusammengestellt wird; diese Post-Build-Skripte sind bereits nutzlos. Daher erfolgt die Generierung in Form eines Handbuchpakets. Sie können sich Overlay/Paket/Handbücher ansehen.
Die Datei „manuals.mk“ (die die ganze Arbeit erledigt)
################################################################################
#
# 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-Welt bewegt sich aktiv zu systemd, und ich musste es auch tun.
Eine der angenehmen Neuerungen ist das Vorhandensein von Timern. Im Allgemeinen wird über sie (und nicht nur über sie) ein separater Artikel geschrieben, aber ich werde es Ihnen kurz erzählen.
Es gibt Aktionen, die regelmäßig durchgeführt werden müssen. Ich musste logrotate ausführen, um die Lighttpd- und PHP-FPM-Protokolle zu löschen. Üblich wäre es, die Befehle in Cron zu schreiben, aber ich habe mich für die Verwendung des monotonen Timers systemd entschieden. Logrotate wird also in einem strengen Zeitintervall ausgeführt.
Natürlich ist es möglich, Timer zu erstellen, die zu bestimmten Terminen ausgelöst werden, aber ich brauchte das nicht.
Timer-Beispiel:
- Timer-Datei
[Unit] Description=RODOS temp daemon timer
OnUnitActiveSec=1min [Installieren] WantedBy=timers.target
- Файл сервиса, вызываемого таймером:
```bash
[Unit]
Description=RODOS temp daemon
[Service]
ExecStart=/usr/bin/rodos.shUnterstützte Boards
Das Asus Tinker Board ist das Hauptboard, auf dem alles funktionieren sollte. Ausgewählt als preiswert und sehr leistungsstark.
Beaglebone Black ist das erste Board, dessen Betrieb getestet wurde (bei der Auswahl eines leistungsstärkeren Boards).
Qemu x86_64 – wird zum Debuggen der Entwicklung verwendet.
Wie es funktioniert
Beim Start erfolgt eine zweistufige Wiederherstellung der Einstellungen:
- Ausführen des Skripts „settings_restore“ (über den Dienst). Es stellt grundlegende Systemeinstellungen wieder her – Zeitzone, Gebietsschema, Netzwerkeinstellungen usw.
- Ausführen des Prepare-Skripts (über den Dienst) – hier werden Zabbix und die Datenbank vorbereitet, die IP wird an die Konsole ausgegeben.
Beim ersten Start wird die Größe der zweiten Partition der SD-Karte ermittelt. Wenn noch nicht zugewiesener Speicherplatz vorhanden ist, wird das Medium neu partitioniert und der Datenabschnitt belegt den gesamten freien Speicherplatz. Dies geschieht, um die Größe des Installationsimages (sdcard.img) zu reduzieren. Außerdem wird an dieser Stelle das Postgresql-Arbeitsverzeichnis erstellt. Aus diesem Grund wird der erste Start mit einem neuen Carrier länger dauern als die folgenden.
Beim Anschließen eines externen Laufwerks sucht es beim Start nach einem freien Laufwerk und formatiert es in ext4 mit der externen Bezeichnung.
Aufmerksamkeit! Wenn Sie ein externes Laufwerk anschließen (sowie es trennen oder austauschen), müssen Sie ein Backup erstellen und die Einstellungen wiederherstellen!
Das Gerät RODOS 5 dient zur Temperaturüberwachung. Der Hersteller stellt den Quellcode seines Dienstprogramms für die Arbeit mit dem Gerät zur Verfügung. Wenn das System eingeschaltet wird, startet der Rodos-Timer, der dieses Dienstprogramm einmal pro Minute ausführt. Die aktuelle Temperatur wird in die Datei /tmp/rodos_current_temp geschrieben, woraufhin zabbix diese Datei als Sensor überwachen kann.
Das Konfigurationsspeichermedium wird im Verzeichnis /data bereitgestellt.
Beim Starten und Betriebsbereiten des Systems erscheint in der Konsole folgende Meldung:
System starting, please waitNach Abschluss der Vorarbeiten wechselt es zur Anzeige der IP-Adresse:
current ip 192.168.1.32
Ready to workEinrichten von Zabbix für die Temperaturüberwachung
Um die Temperatur zu überwachen, führen Sie einfach zwei Schritte aus:
- Schließen Sie das RODOS-Gerät an den USB-Anschluss an
- Erstellen Sie ein Datenelement in Zabbix
Öffnen Sie die Zabbix-Weboberfläche:
- Öffnen Sie den Abschnitt Konfiguration → Hosts
- Klicken Sie auf Artikel in der Zeile unseres Zabbix-Servers
- Klicken Sie auf Artikel erstellen
Geben Sie folgende Daten ein:
- Name – nach Ihrem Ermessen (z. B. serverRoomTemp )
- Typ – Zabbix-Agent
- Schlüssel - Rodos
- Typ-numerisch
- Einheiten - C
- Speicherdauer des Verlaufs – Speicherzeitraum des Verlaufs. 10 Tage übrig
- Trendspeicherzeitraum – Speicherzeitraum für die Dynamik von Änderungen. 30 Tage übrig
- Neue Anwendung – Server-Raumtemperatur
Und drücken Sie die ADD-Taste.
Verwalten Sie die Einstellungen über die Weboberfläche
Das Webinterface ist in PHP geschrieben. Es gibt Hauptfunktionen:
- Gerätestatus anzeigen
- Ändern der Netzwerkeinstellungen
- Benutzerpasswort ändern
- Zeitzonenauswahl
- Sichern/Wiederherstellen/Werksreset
- Möglichkeit, ein externes Laufwerk anzuschließen
- Systemupdate
Die Anmeldung an der Weboberfläche ist passwortgeschützt. Startseite - Handbuch.
Zabbix-Schnittstellenadresse: ${ip/dns}/zabbix
Adresse der Verwaltungsschnittstelle: ${ip/dns}/manage
Laufen 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=threads -device virtio-scsi-pci,id=scsi0 -drive file=output/images/external.qcow2,format=qcow2,aio=threads
Dieser Befehl startet ein System mit 4 Kernen, 2048 RAM, aktiviertem KVM, einer Netzwerkkarte auf Bridge0 und zwei Festplatten: eine für das System und eine externe für Postgresql.
Bilder können konvertiert und in Virtualbox ausgeführt werden:
qemu-img convert -f qcow2 qemu.qcow2 -O vdi qcow2.vdi
qemu-img convert -f qcow2 external.qcow2 -O vdi external.vdiDann importieren Sie sie in Virtualbox und verbinden Sie sie über SATA.
Abschluss
Dabei entwickelte ich ein Interesse daran, ein gebrauchsfertiges Produkt zu entwickeln – mit einer nicht sehr schönen Benutzeroberfläche (ich schreibe sie nicht gern), aber einer, die funktioniert und einfach zu konfigurieren ist.
Der letzte Versuch, zabbix-appliance in KVM zu installieren, zeigte, dass dieser Schritt korrekt war (nach Abschluss der Installation startet das System nicht). Vielleicht mache ich etwas falsch 😉
Source: habr.com