
冒頭にきちんとお伝えしますが、今回紹介するカスタマイズ方法は公式サポートの範囲外となります。とはいえ、大掛かりな改造ではなく、製品にインストール済みのソフトウェアを少し活用してみよう、という軽い試みです。
以前のブログで、EasyBlocks SyslogシリーズにはZabbixサーバーとの連携機能が実装されていることを紹介しました。この連携を実現するため、Zabbixエージェントのパッケージも標準でインストールされています。
しかし、現状ではエージェント自体は有効化されておらず、Zabbixサーバー側からのエージェント監視はできません。
そこで今回は、せっかく入っているのだからということで、Zabbixエージェントを勝手に有効化し、Zabbixサーバー側から監視できるか試してみることにしました。(今後要望が増えれば正式サポートされる……かもしれません。)
はじめに
EasyBlocksシリーズはアプライアンス製品のため、標準仕様外のカスタマイズはサポート対象外となります。追加パッケージのインストールや、Web UI以外からのOSレベルでの設定変更には対応していません。
また、サポートサービスの「Q&Aサービス」は標準構成でご利用いただいている場合のみ提供しています。独自のソフトウェア導入やカスタマイズを行っている場合、サポートをお断りすることがあります。
詳細は、下記サポートサービスページをご確認ください。

インストールパッケージ確認
まず、実際にZabbixエージェントがインストールされているのかEasyBlocks SyslogにOSログインし、コマンドで確認してみます。
# dpkg -l | grep zabbix
ii zabbix-agent 1:6.0.14+dfsg-1+b1 amd64 network monitoring solution – agent
このようにzabbix-agentパッケージ自体はインストールされていることが確認できます。
勝手に設定を編集してみる
設定編集対象ファイル
/etc/zabbix/zabbix_agentd.conf
必要最低限の設定編集だけを行います。
該当箇所は以下の3カ所です。
● Server=Zabbixサーバー(またはプロキシ)のIPアドレスやホスト名
● ServerActive= Zabbixサーバー(またはプロキシ)のIPアドレスやホスト名
● Hostname= Zabbixサーバー(またはプロキシ)で設定したホスト名
ポート開放設定
次に必要なポートを開放します。
Zabbixサーバーと監視対象装置が、監視データの送受信をするときには10050ポートを使って通信を行います。そのため、10050番のポートを許可します。
EasyBlocksシリーズでは製品毎に、サービスに必要なポートのみを開放しているため、10050番はデフォルトでは開放されていないのでiptablesコマンドで許可します。
# iptables -A INPUT -p tcp –dport 10050 -j ACCEPT
最後にZabbixエージェントを起動します。
# systemctl start zabbix-agent
起動確認
# ps ax | grep zabbix_agentd
1185974 ? Ss 0:00 /usr/sbin/zabbix_agentd –foreground
1185975 ? S 0:00 /usr/sbin/zabbix_agentd: collector [idle 1 sec]
1185976 ? S 0:00 /usr/sbin/zabbix_agentd: listener #1 [waiting for connection]
1185977 ? S 0:00 /usr/sbin/zabbix_agentd: listener #2 [waiting for connection]
1185978 ? S 0:00 /usr/sbin/zabbix_agentd: listener #3 [waiting for connection]
1185979 ? S 0:00 /usr/sbin/zabbix_agentd: active checks #1 [idle 1 sec]
こちらでZabbixエージェントのプロセスが起動していることが確認できました。
Zabbixサーバー側設定
ホスト作成などの基本的な手順はここでは割愛します。
今回の目的は、せっかく(勝手に)有効化したZabbixエージェントを使った監視がどこまでできるのかを試してみることです。
EasyBlocks Syslogシリーズでは、内部的にSyslog-ngとMariaDBを組み合わせることで、ログの受信からデータベースへの格納までを実現しています。
そこで今回は、これら主要コンポーネントのプロセスがそれぞれどれくらいCPUを使用しているのかを、Zabbixエージェントの機能を使って確認してみます。
具体的には、プロセスごとのCPU使用率を取得する設定を行い、EasyBlocks Syslogがどの程度の負荷で動作しているのかを可視化していきます。
SyslogプロセスCPU使用率アイテム作成

アイテムの作成から①名前、②タイプはZabbixエージェント、③キー(proc.cpu.util[syslog-ng])、④データ型やホストインターフェース等は適時設定します。
データベースプロセスCPU使用率アイテム作成

アイテムの作成から①名前、②タイプはZabbixエージェント、③キー(proc.cpu.util[mariadbd])、④データ型やホストインターフェース等は適時設定します。
最新データ確認
アイテムの作成を実施した後に、取得したデータのグラフを確認します。
SyslogプロセスCPU使用率グラフ

▶平均0.1232%、最大0.3%
データベースプロセスCPU使用率グラフ

▶平均0.1881%、最大2.1%
ほぼほぼ負荷がかかっていない状態とわかります。
これだとつまらないので、EasyBlocks Syslogに負荷をかけてグラフに変化がでるか確認してみました。データベースの負荷が高くなるデータベースのダンプ処理を実行しながらログを秒間500件程度送信してみました。
SyslogプロセスCPU使用率グラフ

▶平均6.9241%、最大13.8%となりました。
データベースプロセスCPU使用率グラフ

▶平均32.1852%、最大55.8%となりました。
平常時よりはどちらも負荷が高くなっていることが確認できました。
あとは障害判定するためのトリガーの作成、メール通知等の設定を適時することにより、EasyBlocks Syslogとして重要なプロセスの負荷監視が実現できます。
まとめ
今回は、かなり特殊な内容をご紹介しました。
冒頭でも触れたとおり、EasyBlocksシリーズはアプライアンス製品であるため、お客様によるカスタマイズはサポート対象外となります。
本記事の手順を実施したことで重大な技術的問題が発生する可能性は高くありませんが、あくまで公式サポート外の操作である点はご理解ください。

一方で、Zabbixエージェントを利用した監視機能については、ユーザーからのご要望が増えれば Web UIから正式に設定できる機能として実装される可能性もあります。
「エージェント監視を使いたい」「こんな監視項目が欲しい」といった声は、ぜひお気軽にお寄せください。
