Buildroot: zabbix-server を使用したクロスプラットフォーム ファームウェアの作成

問題履歴

中小企業は、インフラストラクチャの高品質な監視を必要としています (特に仮想化の普及を考慮して) が、一方では新しい機器を購入するのが経済的に困難です。 サーバー/ハードウェアの問題もよくあります。多くの場合、ユーザーのワークステーションの隣または小さな隙間/クローゼットに 1 ～ 3 台のタワー サーバーが設置されています。

既製のアセンブリ (ディストリビューション) を使用する方が簡単です。これを microSD カードにアップロードして、一般的なシングルボード コンピューター (beaglebone、raspberry pi、orange pi ファミリ、asus tinker board) に挿入するだけです。 さらに、このような装置は安価であり、どこにでも設置できます。

問題の定式化

多くの点で、このプロジェクトは、結果を応用する可能性を伴う一種の実験研究として発展しました。

Zabbix が監視システムとして選択されたのは、Zabbix が強力で、無料で、十分に文書化されたシステムであるためです。

ハードウェア プラットフォームの問題は深刻になっており、別のマシンを監視下に置くことも、あまり良い解決策ではありません - 新しい機器を購入するか、古い機器を探すのに費用がかかります + 中小企業では、サーバー/サーバーに関する問題が頻繁に発生します。ハードウェア。

buildroot ビルド システムを使用すると、Linux オペレーティング システムに関する最小限の知識を持つ担当者が操作できる特殊なソリューションを作成できます。 このシステムは初心者に優しいですが、同時に経験豊富な開発者の手による十分なカスタマイズの機会を提供します。 これは、IT インフラストラクチャを運用する担当者のトレーニング要件を最小限に抑え、安価でありながら完全に機能する IT インフラストラクチャの監視という問題を解決するのに最適です。

解決策のステップ

これはデバッグに便利で高速なソリューションであるため、最初は qemu で実行する x86_64 用のファームウェアを作成することにしました。 次に、それを arm シングルボード コンピューター (私は asus tinker ボードが気に入りました) に移植します。

buildroot がビルド システムとして選択されました。 当初は zabbix パッケージがなかったため、移植する必要がありましたが、ロシア語ロケールに問題がありましたが、適切なパッチを適用することで解決されました (注: buildroot の新しいバージョンでは、これらのパッチは必要ありません)。

zabbix パッケージ自体の移植については別の記事で説明します。

すべてがファームウェア (変更不可能なシステム イメージ + 回復可能な構成/データベース ファイル) として機能する必要があるため、独自の systemd ターゲット、サービス、タイマー (ターゲット、サービス、タイマー) を作成する必要がありました。

メディアを 2 つのセクションに分割することが決定されました。システム ファイルを含むセクションと、変更可能な設定と zabbix データベース ファイルを含むセクションです。

データベースに関連する問題を解決するのは少し難しいことが判明しました。 それを直接メディアに載せたくなかったのです。 同時に、データベースのサイズが、使用可能な RAM ディスクのサイズを超える可能性があります。 したがって、妥協的な解決策が選択されました。データベースは SD カードの 30 番目のパーティションにあります (最新の SLC カードの書き込みサイクルは最大 000 回です)。ただし、外部メディア (USB など) の使用を許可する設定があります。 HDD）。

温度監視は RODOS-5 デバイスを通じて実装されました。 もちろん、Dallas 1820 を直接使用することもできますが、USB を接続した方が速くて簡単でした。

x86_64 のブートローダーとして grub2 が選択されました。 起動するには最小限の設定を記述する必要がありました。

qemuでデバッグした後、asus tinker boardに移植しました。 私のオーバーレイの構造は当初、クロスプラットフォームであることを目的としており、各ボードに固有の構成 (ボード defconfig、ブートローダー、システム パーティションを含むイメージの生成) を割り当て、ファイル システムのカスタマイズ/データを含むイメージの作成を最大限に均一にすることを目的としていました。 このような準備があったため、移植はすぐに進みました。

紹介記事を読むことを強くお勧めします。
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

組み立て方

プロジェクトはgithubに保存されています
リポジトリのクローンを作成すると、次のファイル構造が得られます。

[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.sh

buildroot-2019.05.tar.gz - クリーンな buildroot アーカイブ
overlay は、external-tree のある私のディレクトリです。 ここには、buildroot を使用してファームウェアをビルドするために必要なものがすべて保存されます。
README.md - プロジェクトの説明と英語のマニュアル。
run_me.sh は、ビルド システムを準備するスクリプトです。 アーカイブから buildroot を展開し、(外部ツリー メカニズムを介して) オーバーレイをアタッチし、アセンブリのターゲット ボードを選択できるようにします。

[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Select defconfig, press A for abort. Default [0]

この後、buildroot-2019.05 ディレクトリに移動して make コマンドを実行するだけです。
ビルドが完了すると、すべてのビルド結果が 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
update

必要なファイル:

• sdcard.img - SD カードに記録するためのメディア イメージ (wibdows の dd または rufus 経由)。
• qemu.qcow2 - qemu で実行するメディア イメージ。
• external.qcow2 - データベースの外部メディアイメージ
• Monitor-0.9-beta.tar.gz - Web インターフェース経由で更新するためのアーカイブ

ガイドの生成

同じ命令を何度も書く価値はありません。 そして最も論理的なのは、マークダウンで一度書いてから、ダウンロード用に PDF に変換し、Web インターフェイス用に HTML に変換することです。 これは Pandoc パッケージのおかげで可能になります。

同時に、これらすべてのファイルは、システム イメージがアセンブルされる前に生成する必要があるため、ビルド後のスクリプトはすでに役に立ちません。 したがって、生成はマニュアル パッケージの形式で行われます。 オーバーレイ/パッケージ/マニュアルをご覧いただけます。

Manuals.mk ファイル (すべての作業を実行します)

################################################################################
#
# 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 の世界では systemd への移行が活発に行われており、私もそうする必要がありました。
嬉しい革新の XNUMX つはタイマーの存在です。 一般的に、それらについては別の記事が書かれていますが（それらについてだけではありません）、簡単に説明します。

定期的に実行する必要があるアクションがあります。 logrotate を実行して、lighttpd と php-fpm のログをクリアする必要がありました。 通常は cron でコマンドを書くのですが、systemd のモノトニックタイマーを使うことにしました。 したがって、logrotate は厳密な時間間隔で実行されます。

もちろん、特定の日付に起動するタイマーを作成することも可能ですが、私はこれを必要としませんでした。
タイマーの例:

• タイマーファイル

  
  [Unit]
  Description=RODOS temp daemon timer

[タイマー] OnBootSec=1分
OnUnitActiveSec=1分

[インストール] WantedBy=timers.target

- Файл сервиса, вызываемого таймером:
```bash
[Unit]
Description=RODOS temp daemon

[Service]
ExecStart=/usr/bin/rodos.sh

サポートされているボード

Asus Tinker Board は、すべてが動作するメインボードです。 安価で非常に強力であるため選択されました。

Beaglebone black は、(より強力なボードの選択中に) 動作がテストされた最初のボードです。

Qemu x86_64 - 開発のデバッグに使用されます。

その仕組み

起動時に、設定の XNUMX 段階の復元が行われます。

• settings_restore スクリプトを (サービス経由で) 実行します。 基本的なシステム設定（タイムゾーン、ロケール、ネットワーク設定など）を復元します。
• (サービス経由で) 準備スクリプトを実行します。ここで zabbix とデータベースが準備され、IP がコンソールに出力されます。

初めて起動すると、SD カードの XNUMX 番目のパーティションのサイズが決定されます。 未割り当ての領域がまだある場合は、メディアのパーティションが再分割され、データ セクションがすべての空き領域を占有します。 これは、インストール イメージ (sdcard.img) のサイズを削減するために行われます。 さらに、この時点で postgresql 作業ディレクトリが作成されます。 そのため、新しい通信事業者による最初の打ち上げは、その後の打ち上げよりも時間がかかります。

外部ドライブを接続すると、起動時に空きドライブが検索され、外部ラベルで ext4 にフォーマットされます。

注意！ 外付けドライブを接続するときは (取り外しや交換も同様に)、バックアップを作成して設定を復元する必要があります。

RODOS 5 デバイスは温度監視に使用され、製造元はデバイスを操作するためのユーティリティのソース コードを提供しています。 システムの電源がオンになると、rodos タイマーが開始され、このユーティリティが XNUMX 分ごとに実行されます。 現在の温度はファイル /tmp/rodos_current_temp に書き込まれ、その後、zabbix はこのファイルをセンサーとして監視できます。

構成ストレージ メディアは /data ディレクトリにマウントされます。

システムを起動して操作の準備をすると、次のメッセージがコンソールに表示されます。

System starting, please wait

準備作業が完了すると、IPアドレスの表示に変わります。

current ip 192.168.1.32
Ready to work

温度監視用の zabbix のセットアップ

温度を監視するには、次の 2 つの手順を実行するだけです。

• RODOS デバイスを USB ポートに接続します
• zabbixでデータ項目を作成する

zabbix Web インターフェイスを開きます。

• 「構成」→「ホスト」セクションを開きます
• zabbix サーバーの行にある「項目」をクリックします。
• 「項目の作成」をクリックします

次のデータを入力します。

• 名前 - あなたの裁量で (たとえば、serverRoomTemp )
• タイプ - zabbix エージェント
• キー - ロドス
• 数値型
• 単位 - C
• 履歴保存期間 — 履歴保存期間。 残り10日
• トレンド保存期間 - 変化のダイナミクスの保存期間。 残り30日
• 新しいアプリケーション - サーバー室温

そして「追加」ボタンを押します。

Webインターフェース経由で設定を管理

Web インターフェイスは PHP で書かれています。 主な機能は次のとおりです。

• デバイスのステータスを表示する
• ネットワーク設定を変更する
  
• ユーザーパスワードの変更
• タイムゾーンの選択
• バックアップ/復元/出荷時設定へのリセット
• 外部ドライブを接続する機能
• システムアップデート
  

Web インターフェースへのログインはパスワードで保護されています。 スタートページ - マニュアル。

Zabbix インターフェース アドレス: ${ip/dns}/zabbix
管理インターフェースのアドレス: ${ip/dns}/manage

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

このコマンドは、4 コア、2048 RAM、有効な KVM、bridge0 上のネットワーク カード、および XNUMX つのディスク (システム用に XNUMX つと postgresql 用に外部に XNUMX つ) を備えたシステムを起動します。

イメージは Virtualbox で変換して実行できます。

qemu-img convert -f qcow2  qemu.qcow2 -O vdi qcow2.vdi
qemu-img convert -f qcow2  external.qcow2 -O vdi external.vdi

次に、それらをvirtualboxにインポートし、SATA経由で接続します。

まとめ

その過程で、私はすぐに使える製品を作ることに興味を持つようになりました。インターフェイスはあまり美しくありませんが (インターフェイスを書くのは好きではありません)、機能し、設定が簡単な製品です。

KVM に zabbix-appliance をインストールする最後の試行では、この手順が正しいことが示されました (インストール完了後、システムは起動しません)。 たぶん私は何か間違ったことをしています😉

材料

https://buildroot.org/

出所： habr.com