2020年11月28日土曜日

OSSのロードバランサ「ZEVENET Community Edition」をクラスタ化し冗長構成にする

先日、OSSのロードバランサである「ZEVENET Community Edition」の導入手順を記事にした。

ZEVENET Community Editionでは、Enterprise Editionと比較すると機能が必要最低限に制限されているため、GUIからはクラスタ化による冗長構成を設定することができない。しかし、SSHにてログインしCLIから操作することで、クラスタ化の設定が可能となっている。クラスタ化することで、2台のZEVENET間で以下が実装される。

  • VRRPによるVIP冗長化
  • コンフィグ同期

クラスタ化の手順はZEVENET公式の手順はにまとめられているものの、実際はその手順だけでは不足していた。そこで、本記事では不足していた手順を含め、ZEVENETのクラスタ化手順をまとめることにする。

環境

  • ESXi 6.7 Update 3
  • ZEVENET Community Edition 5.11

「zevenet-ce-cluster」パッケージのインストール

1. 公開鍵証明書方式にてSSHログインを許可

ZEVENETはクラスタ化するとコンフィグ同期がされるようになる。コンフィグ同期の仕組みはいたってシンプルで、設定ファイルが保存されている「/usr/local/zevenet/config」のフォルダをrsyncにて同期するというものになっている。

rsysncで正常にコンフィグ同期がされるように、公開鍵認証方式にてパスワードなしでログインできるようにしておく。公開鍵認証方式は、ssh-keygenにてキーペアを作成し、ssh-copy-idにて対向ノードに公開鍵をコピーするだけでよい。

## node1で実行

# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ←★空白でエンター
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): ←★空白でエンター
Enter same passphrase again: ←★空白でエンター
~(以下略)~

# ssh-copy-id root@<node2のIPアドレス>
~(中略)~
Are you sure you want to continue connecting (yes/no)? yes ←★yesを入力
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@<node2のIPアドレス>'s password: ←★node2のrootパスワードを入力
~(以下略)~
## node2で実行

# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ←★空白でエンター
Enter passphrase (empty for no passphrase): ←★空白でエンター
Enter same passphrase again: ←★空白でエンター
~(以下略)~

# ssh-copy-id root@<node1のIPアドレス>
~(中略)~
Are you sure you want to continue connecting (yes/no)? yes ←★yesを入力
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@<node1のIPアドレス>'s password: ←★node1のrootパスワードを入力
~(以下略)~

2. Zevenet CE Clusterのパッケージをインストール

ZEVENET Community Editionをクラスタ化するためのパッケージである「Zevenet CE Cluster」のパッケージをインストールする。インストールはapt-getで行う。

## node1/node2両方で実行

# apt-get update
# apt-get install zevenet-ce-cluster -y
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了

~(中略)~

systemd (240-2) のトリガを処理しています ...
zevenet-ce-cluster (1.3) を設定しています ...
Completing the Zevenet CE Cluster installation...

3. Zevenet CE Clusterの設定ファイルを修正

Zevenet CE Clusterの設定ファイルの以下個所を修正する。$cluster_ipでクラスタのVIPを設定しているので、一見するとVIPが自動作成されるように見えるが、実際には作成されることはない。VIP自体はGUIで作成すること。

## node1/node2両方で実行

# cp /usr/local/zevenet/app/ucarp/etc/zevenet-cluster.conf{,.org}
# vi /usr/local/zevenet/app/ucarp/etc/zevenet-cluster.conf
#local IP to be monitored, i e 192.168.0.101
$local_ip="<自ノードのIPアドレス>";

#remote IP to be monitored, i e 192.168.0.102
$remote_ip="<対向ノードのIPアドレス>";

#used password for vrrp protocol communication
$password="<VRRPで使用する共通パスワード>";

#unique value for vrrp cluster in the network
$cluster_id="<任意のVRRP ID>";

#used virtual IP in the cluster, this ip will run always in the master node
$cluster_ip="<クラスタで使用するVIP>";

4. サービス起動ファイルの設定修正

ここが公式のマニュアルでは言及がされていない手順となる。

この状態でzevenet-ce-clusterサービスを起動させようとすると、以下の通り「Cluster is disabled」エラーとなり起動に失敗する。

# /etc/init.d/zevenet-ce-cluster start
Cluster is disabled, enable cluster in /etc/init.d/zevenet-ce-clusterUsage: /etc/init.d/zevenet ( stop | start )

起動スクリプトである「/etc/init.d/zevenet-ce-cluster」内に$enable_cluster変数があるが、デフォルトではfalseに設定されておりクラスタが起動できないことが原因となる。この変数をtrueに修正する。

## node1/node2両方で実行

# vi /etc/init.d/zevenet-ce-cluster
#!/usr/bin/perl
$action = $ARGV[0];

$enable_cluster="true"; # false = disable cluster, true = enable cluster
↑★trueに変更

~(以下略)~

5. zevenet-ce-clusterサービスを起動

zevenet-ce-clusterサービスを起動させる。先に起動した側がMasterになることから、Master側を先に起動させるようにすること。Master/Backupどちらで起動しているかは「/etc/zevenet-ce-cluster.status」ファイルに記録される。また、このファイルの内容はシェルのプロンプトにも表示されるようになる。

## node1で実行

# /etc/init.d/zevenet-ce-cluster start
Starting Zevenet CE Cluster...
[master] # cat /etc/zevenet-ce-cluster.status
master

次にBackup側を起動させる。

## node2で実行

# /etc/init.d/zevenet-ce-cluster start
Starting Zevenet CE Cluster...
[backup] # cat /etc/zevenet-ce-cluster.status
backup

動作確認

管理GUIにログインしてみると、Masterとなっているnode1側では、Virtual Interface及びFarmがUp (緑色) となっており、正常に動作していることがわかる。


一方、Backupとなっているnode2側では、Virtual Interface及びFarmがDown (赤色) となっており、Backup中はVirtual Interface及びFarmが無効化されていることがわかる。


MasterとBackupを切り替えるためには、Master側にSSHでログインし、zevenet-ce-clusterサービスを停止→数秒待機→起動すればよい。サービス再起動だと、Master側のZEVENETが再度Masterで復帰してしまうので注意。

[master] # systemctl stop zevenet-ce-cluster
[] #
[] # systemctl start zevenet-ce-cluster
[backup] #

あるいは、ZEVENET自体を再起動ことでも、MasterとBackup切り替えることができる。

まとめ

以上で、ZEVENET Community Editionをクラスタ化し冗長構成にすることができた。GUIで設定できないことは少し不便ではあるものの、設定後は問題なく切り替わりやコンフィグ同期も動作しており、これによってより一層使えるロードバランサになった。

参考

2020年11月22日日曜日

OSSのロードバランサ「ZEVENET Community Edition」をESXi上にインストールしてみた

自宅検証環境ではPacmekaerで冗長化したプロキシサーバ (兼DNS/メール/NTPサーバ) を構築している。このサーバは、PacmekaerでActive-Standby構成としていたが、ロードバランサを導入してActive-Active構成に変更したいと考えていた。

そんなことを計画しながら、OSSで使えそうなロードバランサを探していると、スペインに本社を置くZEVENET社の「ZEVENET」という製品を見つけることができた。

ZEVENET Enterprise EditionとZEVENET Community Editionの2つが用意されており、Community Editionであれば無償利用が可能となる。各エディションの差異は、以下公式サイトに情報がある。ちなみに、以下URLではクラスタ構成はEnterprise Editionのみ可能と読めるが、Community Editionであってもクラスタ構成は可能となる。

ZEVENETは残念ながら日本では人気がないらしく、ググっても日本語の情報はほとんどヒットしなかったが、マニュアル自体は充実しておりインストールと設定には困らなそうなので、自宅のESXi環境に、「ZEVENET Community Edition」を導入してみることにした

以後、ZEVENET Community Editionの表記について、特に断りがない限りは単に「ZEVENET」として記載をすることにする。

環境

  • ESXi 6.7 Update 3
  • ZEVENET Community Edition 5.11

ダウンロード

1. ZEVENETのISOイメージをダウンロード

ダウンロードは以下サイトから実施する。ZEVENETは、ソースコード、ISOイメージ、Dockerイメージの3種類がダウンロードできる。今回は、ESXi上の仮想マシンとして構築することから「DOWNLOAD ISO IMAGE」を選択して、ISOイメージをダウンロードする。

2. 仮想マシンの作成

ZEVENETをインストールするための仮想マシンを作成する。以下構成で仮想マシンを作成する。インストール後にuname -aで確認すると「Debian 4.19.67-2 (2019-08-28) x86_64」と表示されるので、OS自体はどう見てもDebian 10ベースのようなだが、ゲストOSのバージョンは「その他のLinux」を選択する必要があるので注意。

設定項目 設定値
ゲストOSのバージョン その他の Linux 4.x 以降 (64 ビット)
CPU 1コア
メモリ 1GB
ディスク 8GB
NIC 1枚 ※VMXNET 3でOK
CD/DVDドライブ ZEVENETのISOイメージを指定

設定で来たら、仮想マシンをパワーオンし「Install」を選択してインストールを開始する。

インストール

1. 言語設定

「Select a Language」の画面では「日本語」を選択しておく。

2. ネットワーク設定

ZEVENETに割り当てるIPアドレス等を以下の通り指定する。

設定項目 設定値
IPアドレス ZEVENETに設定するIPアドレス。x.x.x.x/xの形式で記載する。x.x.x.xの形式で記載した場合は、次の画面でサブネットマスクの設定画面が表示される
ゲートウェイ ZEVENETに設定するデフォルトゲートウェイ。なお、ZEVENET Community Editionではスタティックルートの設定はできないので注意
ネームサーバアドレス 空白でOK
ホスト名 ZEVENETに設定するホスト名
ドメイン名 空白でOK

3. rootパスワード設定

rootパスワードの設定を聞かれるので、任意のパスワードを設定する。なお、ZEVENET Community Editionでは、rootユーザのみ設定が可能で、その他のユーザ作成を行うことはできない。

4. ディスクのパーティション設定

ディスクのパーティション設定は、以下の通りディスク全体を使う設定をすれば問題ない。

設定項目 設定値
パーティショニングの方法 ガイド - ディスク全体を使う
パーティション設定の確認 パーティショニングの終了とディスクへの変更の書き込み
ディスクに変更を書き込みますか? はい

5. GRUBの設定

GRUB設定は以下の通り設定しておく。

設定項目 設定値
GRUBをインストールするデバイス /dev/sdaと/dev/sda1を選択
ブートローダをインストールするデバイス /dev/sdaを選択

6. 管理GUIにログイン

以上でインストールは完了となる。再起動後、以下URLにアクセスするとログイン画面が表示されるはずだ。rootユーザと設定したパスワードを使ってログインしてみよう。

https://<ZEVENETのIPアドレス>:444

open-vm-toolsのインストール

ZEVENETは標準ではopen-vm-toolsがインストールされていないので、SSHでログインしたのち、手動でインストールを行う。いきなりインストールを試みると失敗するようなので、apt updateを1回実行してからインストールすること。

# apt update
# apt install open-vm-tools -y

ロードバランサ設定

1. Virtual Interfaceを設定

「Network」→「Virtual Interfaces」にてサービス提供用の仮想インタフェースを設定する。シングル構成で動作させる場合は設定しなくても動作させることはできるが、クラスタ構成として冗長化する場合も考慮して、仮想インタフェースの設定は実施することをお勧めする。

2. Farmを設定

ZEVENETでは負荷分散の設定を「Farm」という名前で設定する。Farmの設定には以下が含まれる。

  • 使用する仮想インタフェースと待ち受けるポート番号
  • 振り分け先サーバとポート番号
  • 振り分け先サーバの監視方式 (PingチェックやTCPチェック等)
  • 振り分けのアルゴリズム (Round Robin等)
  • パーシステント方式 (送信元IPに応じて振り分け先を決定等)

設定方法は、「LSLB」→「Farms」で行う。「CREATE FARM」ボタンでFarmを作成したのち、鉛筆マークの「Edit」ボタンを押して、詳細な負荷分散の設定を行う。このあたりの設定の詳細は割愛するが、たとえば、メールサーバに対する振り分け設定は以下の通りとなる。

設定項目 設定値
Load balancer Algorithm Round Robin
Persistence No persistence
Health Checks for backend check_tcp
Backend メールサーバ2台を25番ポートで登録。PriorityとWeightはデフォルトの1を設定

まとめ

最後にまとめとして、ZEVENETのメリット・デメリットを以下に記載する。

メリット

  • OSイメージが約570MBと軽量
  • 軽量なため、少ないリソースでも十分に動作する
  • 軽量なため、OSの起動がすごく早い
  • Debianベースとなっているため、OSコマンドである程度対処ができる (aptによるパッケージ管理やsystemdによるサービス管理など)
  • ZEVENET公式のマニュアルが比較的充実
  • 良くも悪くもCommunity Editionでは設定項目が必要最低限に絞られているので、マニュアル見なくてもあまり迷うことなく直感的に設定できる
  • Community Editionでもクラスタ構成が組める

デメリット

  • UIを日本語に変更できるが、翻訳が直訳で雑 (Farmが農場と翻訳されていたりする)
  • 公式サイトも日本語サイトがあるが、機械翻訳によるものとなっており、あやしさが漂う
  • おそらく日本国内の人気は低く、日本語で記載されたブログ等の情報は皆無
  • Community Editionであってもクラスタによる冗長化が組めるが、GUIからは実施できない
  • スタティックルートが設定できない

参考

2020年11月21日土曜日

ESXiをvCenter Serverに登録した際に「ホスト上のサードパーティ I/Oフィルタ ストレージ プロバイダの登録/登録解除に失敗する」のエラーが出る

ESXiをvCenter Server (vCSA)に登録した際に以下警告メッセージが表示された場合の対処方法を記載する。

"ホスト上のサードパーティ I/Oフィルタ ストレージ プロバイダの登録/登録解除に失敗する"
※英語表記の場合"Registration/unregistration of third-party IO filter storage providers fails  on a host"


原因

vCSAとESXiの間にFirewall等で通信制御をしている環境において、以下通信許可が不足していることが原因となる。
送信元 送信先 送信先ポート
vCSA ESXi 9080/tcp

対処

  1. Firewall等の通信許可設定で、vCSA→ESXi方向の9080/tcpを許可する。
  2. vSphere Clientにて、[vCenter Server] -> [設定] -> [詳細] -> [ストレージ プロバイダ]を選択する。

  3. [ストレージプロバイダの同期]を選択し、ESXiが表示されることを確認する。なお、9080/tcpのポートが許可されていない場合は、この操作はエラーで失敗する。

  4. ESXiの警告メッセージは手動でリセットしないと消えないようなので、[緑にリセット]を選択して、警告を解除する。

2020年11月14日土曜日

ESXiをvCenter Serverに登録した際に、ESXiが頻繁に「応答なし」になる

ESXiをvCenter Server (vCSA)に登録した際に、ESXiが頻繁に応答なしになる事象が発生した。


ESXiのイベントとしては「ホストが応答しません」のエラーが出力される。


なお、「応答なし」になるタイミングや頻度は以下となる。
  • メンテナンスモード有効/無効時
  • vSphere HA有効/無効時
  • 1分間に1回(ただし、1秒以内に回復)

原因

vCSAとESXiの間にFirewall等で通信制御をしている環境において、以下通信許可が不足していることが原因となる。
ESXi→vCSA方向の通信要件となるため注意。

送信元 送信先 送信先ポート
ESXi vCSA 902/udp

対処

  1. Firewall等の通信許可設定で、ESXi→vCSA方向の902/udpを許可する。
  2. ESXiのイベントで「ホストが応答しません」が発生しないことを確認する。また、「ホストのCPU使用率が灰色から緑に変わりました」といったメッセージが表示されていることも確認する。

2020年11月7日土曜日

Zabbix Agentの「リモートコマンド」を使って監視対象のOSコマンドを実行する

Zabbix Agentはインストール対象のOSにてコマンド実行やスクリプト実行をさせる「リモートコマンド」機能を有している。この機能を使うと、例えば障害などでサーバ再起動が必要となった際などに、わざわざOSにログインせずともZabbixの管理画面から再起動を実行することができる
※当然障害中であってもZabbix Agentと疎通ができることが条件となる。

今回、Zabbix Agentにてリモートコマンドを有効にし、Zabbixの管理画面からOSの再起動を実行できるよう設定をしてみた

環境

  • Zabbix : 5.0.3 (CentOS 8にインストール)
  • Zabbix Agent : 4.0.17 (Ubunt 20.04にインストール)

Zabbix Agent設定手順

1. 「/etc/zabbix/zabbix_agentd.conf」の修正

「/etc/zabbix/zabbix_agentd.conf」に対して以下を設定修正する。修正内容はZabbix Agent 5.0より前のバージョンと5.0以降で異なるので注意。

Zabbix Agent 5.0より前のバージョンは以下で設定する。

$ sudo vi /etc/zabbix/zabbix_agentd.conf
EnableRemoteCommands=1 

Zabbix Agent 5.0以降のバージョンは以下で設定する。

$ sudo vi /etc/zabbix/zabbix_agentd.conf
AllowKey=system.run[*]

設定修正後、Zabbix Agentを再起動し設定反映する。

$ sudo systemctl restart zabbix-agent

2. 「/etc/sudoers」の修正

パスワードなしでコマンドを叩けるようにvisudoコマンドでsudoの設定を行う。

$ sudo visudo
# allows 'zabbix' user to run all commands without password.
zabbix ALL=NOPASSWD: ALL

Zabbixにてスクリプトを設定

1. 再起動用のスクリプトを設定

Zabbix管理画面にて「管理」→「スクリプト」を選択し、以下のスクリプトを作成する。

内容は、1分後にサーバを再起動するスクリプトとなる。再起動を1分後にしている理由は、即材に再起動させるとスクリプト実行後の応答をZabbixが受け取ることができずエラーになるためである。また、万が一再起動をキャンセルしたい場合に備えて、猶予期間を設けることも理由となる。

今回の再起動といった影響の大きいスクリプトを実行させる場合は、「確認を有効」にチェックを入れておく。このチェックを入れることで、スクリプト実行前に確認画面を表示させることができ、オペミスの発生を予防できる

項目 設定値
名前 Reboot
タイプ スクリプト
次で実行 Zabbixエージェント
コマンド sudo shutdown -r +1
必要なホストへのアクセス権 表示のみ
確認を有効 チェック
確認テキスト 1分後にホスト {HOST.NAME} を再起動します。


2. 再起動キャンセル用のスクリプトを設定

万が一再起動をキャンセルしたい場合に備え、再起動をキャンセルするスクリプトも併せて作成しておく。

項目 設定値
名前 Cancel reboot
タイプ スクリプト
次で実行 Zabbixエージェント
コマンド sudo shutdown -c
必要なホストへのアクセス権 表示のみ
確認を有効 チェックなし
確認テキスト <空白>


2. 動作確認

まず「Reboot」スクリプトを実行してみる。

「監視データ」→「ホスト」にて対象のホストの名前をクリックし、「Reboot」を選択する。

「1分後にホスト <対象のホスト名> を再起動します。」と表示されるので、「実行」ボタンをを選択する。

実行後、コマンドの標準出力の結果が表示される。これで1分待てば、サーバが再起動されるはずだ。

再起動をキャンセルしたい場合は、再度対象のホストの名前をクリックし、「Cancel reboot」を選択する。こちらは「確認を有効」にチェックを入れていないので、特に何も表示されるスクリプトが実行される。

まとめ

今回は、ホストを選択して直接スクリプトを実行させる手順を紹介したが、このスクリプトは、アクションでも使うことができる。

アクションを設定することで、「特定の監視メッセージが表示された際に、復旧コマンドやログ取得コマンドを自動実行させる」といった使い方もできるので、うまく設定すれば運用効率化が実現できそうだ。

参考

2020年11月3日火曜日

Zabbix Agent2を使ってsystemdのサービスステータスを監視する

ZabbixはWindowsやLinuxなどの監視を行うために、エージェントとして「Zabbix Agent」が長らく提供されてきた。Zabbix 5.0から新たなエージェントとして「Zabbix Agent2」が正式サポートされるようになった。

Zabbix AgentとZabbix Agent2の違いの説明は割愛するが、今後のことを考えて、Zabbix Agent2を使ってみることにした。本記事では、Zabbix Agent2のインストールと設定を記載する。先に言っておくと、インストール手順はZabbix Agentほとんど変化がなく、Zabbixを使ってきた人であればマニュアルを見なくてもインストールできるだろう。

環境

今回はZabbix 5.0を使用する。Zabbix Agent2をCent OS 8にインストールし、Zabbix Agent2で可能となったsystemdのサービスステータス監視を設定する

なお、Zabbix Agent2がサポートされるプラットフォームは以下の通り。マニュアルを見るとWindowsは一部機能制限がある旨、記載されているので注意。

  • RHEL/CentOS 6, 7, 8
  • SLES 15 SP1+
  • Debian 9, 10
  • Ubuntu 18.04
  • Windows (一部機能制限あり)

Zabbix Agent2のインストール

そのままではdnfでインストールすることができないので、「zabbix-release」のパッケージをインストールしたのち、インストールを実行する。

# rpm -Uvh https://repo.zabbix.com/zabbix/5.0/rhel/8/x86_64/zabbix-release-5.0-1.el8.noarch.rpm
# dnf install zabbix-agent2 -y

設定ファイルは「/etc/zabbix/zabbix_agent2.conf」となる。以下3行を環境に合わせて修正する。

# vi /etc/zabbix/zabbix_agent2.conf
Server=<Zabbix ServerのIPアドレス>
ServerActive=<Zabbix ServerのIPアドレス>
Hostname=<ホスト名>

設定修正後、Zabbix Agent2を起動する。

# systemctl enable zabbix-agent2
Created symlink /etc/systemd/system/multi-user.target.wants/zabbix-agent2.service → /usr/lib/systemd/system/zabbix-agent2.service.
# systemctl start zabbix-agent2
# systemctl status zabbix-agent2
● zabbix-agent2.service - Zabbix Agent 2
   Loaded: loaded (/usr/lib/systemd/system/zabbix-agent2.service; enabled; vend>
   Active: active (running) since Sat 2020-08-22 17:34:54 JST; 10s ago
 Main PID: 20448 (zabbix_agent2)
    Tasks: 7 (limit: 11090)
   Memory: 7.8M
   CGroup: /system.slice/zabbix-agent2.service
           mq20448 /usr/sbin/zabbix_agent2 -c /etc/zabbix/zabbix_agent2.conf

 8月 22 17:34:54 t3022cent systemd[1]: Started Zabbix Agent 2.
 8月 22 17:34:54 t3022cent zabbix_agent2[20448]: Starting Zabbix Agent 2 [t3022>
 8月 22 17:34:54 t3022cent zabbix_agent2[20448]: Press Ctrl+C to exit.

systemdのサービスの監視を追加

Zabbix Agent2では、systemdのサービスの監視ができるようになっているので、今回その機能を使ってPacmekaerのサービス監視を行うことにした。具体的には、systemd.unit.info[<unit name>,<property>,<interface>]にてアイテムを作成することで実現する。

今回は例として、「pacemaker.service 」を監視させることにする。

1. アイテムを作成

以下のような内容でアイテムを作成する。デフォルトから変更していない箇所は記載を省略しているので、必要な場合は適宜変更すること。

項目 設定値
名前 Pacemaker service is running
タイプ Zabbixエージェント
キー systemd.unit.info[pacemaker.service]
データ型 文字列
アプリケーション Pacemaker service


2. トリガーを作成

以下のような内容でトリガーを作成する。デフォルトから変更していない箇所は記載を省略しているので、必要な場合は適宜変更すること。

項目 設定値
名前 Pacemaker service is down on {HOST.NAME}
深刻度 軽度の障害
条件式 {Template Pacemaker Service:systemd.unit.info[pacemaker.service].last()}<>"active"


3. 動作確認

それでは実際にPacemakerのクラスタを停止させて、Zabbixxにて停止を検知することを確認してみよう。

停止前のアイテムの最新データは「active」となっている。

クラスタを停止させると、「inactive」となる。

systemdのサービスのステータスが変化したことで、正常にトリガーも実行された。


まとめ

以上でZabbix Agent2を使って、systemdの監視を実現することができた。Zabbix Agent2ではディスカバリを使ってsystemdに登録されているサービスを自動で取得することもでできるようなので、そちらも別途試していきたい。

参考


人気の投稿