Historique du problème
Les petites entreprises, d'une part, ont besoin d'une surveillance de haute qualité de leur infrastructure (surtout à la lumière de la virtualisation généralisée), d'autre part, il leur est financièrement difficile d'acheter de nouveaux équipements. Les problèmes de serveur/matériel sont également courants : il y a souvent 1 à 3 serveurs tour à côté des postes de travail des utilisateurs ou dans une petite niche/placard.
Il est plus facile d'utiliser un assemblage prêt à l'emploi (distribution), qu'il vous suffit de télécharger sur une carte microSD et de l'insérer dans un ordinateur monocarte commun (familles beaglebone, raspberry pi et orange pi, asus tinker board). De plus, un tel équipement est peu coûteux et peut être installé n’importe où.
Formulation du problème
À bien des égards, le projet s'est développé comme une sorte de travail de laboratoire avec la possibilité d'appliquer les résultats.
Zabbix a été choisi comme système de surveillance car il s'agit d'un système puissant, gratuit et bien documenté.
Le problème avec la plate-forme matérielle est devenu aigu. Mettre une machine séparée sous surveillance n'est pas non plus une très bonne solution - soit l'achat de nouveaux équipements coûte cher, soit il faut rechercher des équipements anciens + dans les petites entreprises, il y a des problèmes fréquents avec le serveur/ matériel.
L'utilisation du système de build buildroot vous permet de créer des solutions spécialisées qui peuvent être exploitées par du personnel ayant une connaissance minimale des systèmes d'exploitation Linux. Ce système est convivial pour les débutants, mais offre en même temps de nombreuses possibilités de personnalisation entre les mains d'un développeur expérimenté. Il est parfait pour résoudre le problème d'une surveillance peu coûteuse mais entièrement fonctionnelle de l'infrastructure informatique, avec des exigences minimales pour la formation du personnel qui l'exploite.
Étapes de la solution
Il a été décidé de créer initialement un firmware pour x86_64 afin qu'il s'exécute dans qemu, car il s'agit d'une solution pratique et rapide pour le débogage. Portez-le ensuite sur un ordinateur monocarte Arm (j'ai aimé la carte Asus Tinker).
buildroot a été sélectionné comme système de construction. Au départ, il lui manquait le paquet zabbix, il a donc dû être porté. Il y a eu des problèmes avec la locale russe, qui ont été résolus en appliquant les correctifs appropriés (remarque : dans les versions plus récentes de buildroot, ces correctifs ne sont plus nécessaires).
Le portage du package zabbix lui-même sera décrit dans un article séparé.
Puisque tout devrait fonctionner comme un firmware (image système immuable + fichiers de configuration/base de données récupérables), il était nécessaire d'écrire vos propres cibles, services et minuteries systemd (cible, service, minuterie).
Il a été décidé de diviser le média en 2 sections : une section avec les fichiers système et une section avec les configurations modifiables et les fichiers de base de données Zabbix.
Résoudre les problèmes liés à la base de données s'est avéré un peu plus difficile. Je ne voulais pas le placer directement dans les médias. Dans le même temps, la taille de la base de données peut atteindre une taille qui dépasse la taille d'un éventuel disque virtuel. Par conséquent, une solution de compromis a été choisie : la base de données est située sur la deuxième section de la carte SD (les cartes SLC modernes ont jusqu'à 30 000 cycles d'écriture), mais il existe un paramètre qui permet l'utilisation de supports externes (par exemple, USB- disque dur).
La surveillance de la température a été mise en œuvre via le dispositif RODOS-5. Bien sûr, vous pouvez utiliser directement le Dallas 1820, mais il était plus rapide et plus simple de brancher une clé USB.
grub86 a été sélectionné comme chargeur de démarrage pour x64_2. Il a fallu écrire une config minimale pour le lancer.
Après le débogage sur qemu, il a été porté sur la carte Asus Tinker. La structure de ma superposition était initialement prévue pour être multiplateforme - allouant des configurations spécifiques à chaque carte (defconfig de la carte, bootloader, génération d'une image avec une partition système) et une uniformité maximale dans la personnalisation du système de fichiers/création d'une image avec des données. Grâce à une telle préparation, le portage s’est déroulé rapidement.
Il est fortement recommandé de lire les articles d'introduction :
Comment assembler
Après avoir cloné le référentiel, la structure de fichiers suivante est obtenue :
[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.shbuildroot-2019.05.tar.gz - archive buildroot propre
la superposition est mon répertoire avec une arborescence externe. C'est ici que tout ce dont vous avez besoin pour créer le firmware à l'aide de buildroot est stocké.
README.md - description du projet et manuel en anglais.
run_me.sh est un script qui prépare le système de build. Développe buildroot à partir de l'archive, y attache une superposition (via le mécanisme d'arborescence externe) et vous permet de sélectionner la carte cible pour l'assemblage.
[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Select defconfig, press A for abort. Default [0]Après cela, accédez simplement au répertoire buildroot-2019.05 et exécutez la commande make.
Une fois la construction terminée, tous les résultats de la construction seront dans le répertoire 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
updateFichiers requis :
- sdcard.img - image multimédia pour l'enregistrement sur une carte SD (via dd ou rufus sous wibdows).
- qemu.qcow2 - image multimédia à exécuter dans qemu.
- external.qcow2 - image média externe pour la base de données
- monitor-0.9-beta.tar.gz - archive pour mise à jour via l'interface Web
Génération de guides
Cela ne vaut pas la peine d’écrire plusieurs fois les mêmes instructions. Et le plus logique est de l'écrire une fois en markdown, puis de le convertir en PDF pour le téléchargement et en html pour l'interface web. Ceci est possible grâce au package pandoc.
Dans le même temps, tous ces fichiers doivent être générés avant que l'image système ne soit assemblée ; ces scripts de post-construction sont déjà inutiles. La génération se fait donc sous la forme d’un package de manuels. Vous pouvez consulter la superposition/le package/les manuels.
Le fichier manuals.mk (qui fait tout le travail)
################################################################################
#
# 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
Le monde Linux migre activement vers systemd, et je devais le faire aussi.
L'une des innovations agréables est la présence de minuteries. En général, un article séparé est en cours d'écriture à leur sujet (et pas seulement à leur sujet), mais je vais vous le dire brièvement.
Certaines actions doivent être effectuées périodiquement. Je devais exécuter logrotate pour effacer les journaux lighttpd et php-fpm. La chose habituelle serait d'écrire les commandes en cron, mais j'ai décidé d'utiliser le timer monotone systemd. Logrotate s'exécute donc à un intervalle de temps strict.
Bien sûr, il est possible de créer des minuteries qui se déclenchent à certaines dates, mais je n'en avais pas besoin.
Exemple de minuterie :
- Fichier de minuterie
[Unit] Description=RODOS temp daemon timer
OnUnitActiveSec=1min [Installer] WantedBy=timers.target
- Файл сервиса, вызываемого таймером:
```bash
[Unit]
Description=RODOS temp daemon
[Service]
ExecStart=/usr/bin/rodos.shCartes prises en charge
Asus Tinker Board est la carte principale sur laquelle tout devrait fonctionner. Sélectionné comme peu coûteux et très puissant.
Beaglebone black est la première carte sur laquelle le fonctionnement a été testé (lors de la sélection d'une carte plus puissante).
Qemu x86_64 - utilisé pour le développement du débogage.
Comment ça marche
Au démarrage, une restauration des paramètres en deux étapes s'effectue :
- exécuter le script settings_restore (via le service). Il restaure les paramètres de base du système : fuseau horaire, paramètres régionaux, paramètres réseau, etc.
- exécuter le script de préparation (via le service) - ici zabbix et la base de données sont préparés, l'adresse IP est affichée sur la console.
Lorsque vous le démarrez pour la première fois, la taille de la deuxième partition de la carte SD est déterminée. S'il reste encore de l'espace non alloué, le média est réparti et la section de données occupe tout l'espace libre. Ceci est fait afin de réduire la taille de l'image d'installation (sdcard.img). De plus, le répertoire de travail postgresql est créé à ce stade. C'est pourquoi le premier lancement avec un nouveau transporteur sera plus long que les suivants.
Lors de la connexion d'un disque externe, au moment du démarrage, il recherche un disque libre et le formate en ext4 avec l'étiquette externe.
Attention! Lors de la connexion d'un disque externe (ainsi que de sa déconnexion ou de son remplacement), vous devez effectuer une sauvegarde et restaurer les paramètres !
Pour la surveillance de la température, l'appareil RODOS 5 est utilisé. Le fabricant fournit le code source de son utilitaire pour travailler avec l'appareil. Lorsque le système est allumé, la minuterie rodos démarre, qui exécute cet utilitaire une fois par minute. La température actuelle est écrite dans le fichier /tmp/rodos_current_temp, après quoi zabbix peut surveiller ce fichier en tant que capteur.
Le support de stockage de configuration est monté dans le répertoire /data.
Lors du démarrage du système et de sa préparation au fonctionnement, le message suivant apparaît dans la console :
System starting, please waitUne fois les travaux préparatoires terminés, l'affichage de l'adresse IP s'affichera :
current ip 192.168.1.32
Ready to workConfiguration de Zabbix pour la surveillance de la température
Pour surveiller la température, il suffit de suivre 2 étapes :
- connectez l'appareil RODOS au port USB
- créer un élément de données dans Zabbix
Ouvrez l'interface Web de Zabbix :
- Ouvrez la section Configuration → Hôtes
- Cliquez sur Articles dans la ligne de notre serveur zabbix
- Cliquez sur Créer un article
Saisissez les données suivantes :
- nom - à votre discrétion (par exemple, serverRoomTemp )
- Type : agent Zabbix
- Clé - Rhodes
- Type-numérique
- Unités - C
- Période de stockage de l'historique — période de stockage de l'historique. il reste 10 jours
- Période de stockage des tendances : période de stockage de la dynamique des changements. Parti 30 jours
- Nouvelle application - serveur Room Temp
Et appuyez sur le bouton AJOUTER.
Gérer les paramètres via l'interface Web
L'interface Web est écrite en PHP. Il y a des fonctions principales :
- afficher l'état de l'appareil
- modification des paramètres réseau
- changer le mot de passe de l'utilisateur
- sélection du fuseau horaire
- sauvegarde/restauration/réinitialisation d'usine
- possibilité de connecter un disque externe
- Mise à jour du système
La connexion à l'interface Web est protégée par mot de passe. Page de démarrage - manuel.
Adresse de l'interface Zabbix : ${ip/dns}/zabbix
Adresse de l'interface de gestion : ${ip/dns}/manage
Courir en 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
Cette commande démarrera un système avec 4 cœurs, 2048 RAM, KVM activé, une carte réseau sur bridge0 et deux disques : un pour le système et un externe pour postgresql.
Les images peuvent être converties et exécutées dans Virtualbox :
qemu-img convert -f qcow2 qemu.qcow2 -O vdi qcow2.vdi
qemu-img convert -f qcow2 external.qcow2 -O vdi external.vdiImportez-les ensuite dans Virtualbox et connectez-vous via SATA.
Conclusion
Dans la foulée, je me suis intéressé à créer un produit prêt à l'emploi - avec une interface pas très belle (je n'aime pas les écrire), mais qui fonctionne et est facile à configurer.
La dernière tentative d'installation de l'appliance zabbix dans KVM a montré que cette étape était correcte (une fois l'installation terminée, le système ne démarre pas). Peut-être que je fais quelque chose de mal 😉
Source: habr.com