みなさん、こんにちは。しずかと申します。前回は Zabbix6.0 の新機能 Zabbix HA について、設定編をブログに書きました。 今回は、監視編ということで、監視登録やその挙動、フェイルオーバー・フェイルバックの挙動について、まとめてみました。
目次
- 目次
- 設定編のおさらい
- 監視登録
- 監視対象登録と注意点
- フェイルオーバーとデータ欠損
- フェイルバック
- フェイルオーバー時のクライアントの挙動
- デフォルトで設定されているZabbix Serverのホスト
- まとめ
設定編のおさらい
前回こちらの記事で、Zabbix HAの設定方法についてまとめました。
今回はその続編で、監視登録やフェールオーバー・フェイルバックについてまとめてみます。
検証する構成は、前回と同じく以下の構成になっています。
監視登録
アクティブ機とスタンバイ機の両方からWebUIにはアクセスできますが、それぞれから監視登録できるのか、以下のパターンを試してみたいと思います。
- アクティブ機のWebUIからスタンバイ機のZabbixサーバを登録
- スタンバイ機のWebUIからアクティブ機のZabbixサーバを登録
事前状態の確認
まずは登録前に設定状況の確認をしてみます。サイドバー > 設定 > ホスト
にて確認します。
デフォルトの Zabbix Server
が登録済みです。インターフェイスが 127.0.0.1
ですが、これはアクティブ機、スタンバイ機どちらなのでしょうか。答え合わせは後ほど行いたいと思います。
スクリーンショットは割愛しますが、スタンバイ機でも同様にデフォルトの Zabbix Server
が登録済みで、インターフェイスが 127.0.0.1
になっています。
アクティブ機WebUIからスタンバイ機のホスト登録
メニュバー > 設定 > ホスト
から 右上の ホストの作成
を押下し、ホストを登録します。
ポップアップが表示されるので、各項目を入力していきます。Zabbix6.0系ではIPアドレスを指定する インターフェイス
は 追加 を押下しないと一つ目の入力ボックスが表示されないようです。
追加 を押下し、エージェント
を選択します。
スタンバイ機のプライベートIPアドレスを入力したら、追加
を押下します。
ホストの一覧に、設定追加されており、ZBX
のアイコンも緑になっているので、スタンバイ機のエージェントと疎通できているようです。
では、スタンバイ機のWebUIからも同様に確認すると、同じようにホスト登録されていることがわかります。わかりにくいですが左上のホスト名を見るとスタンバイ機のWebUIで確認していることがわかります。
ここまでの情報をいったんまとめます。
- Zabbix6.0系でも、これまでのZabbixとほぼ同じ方法で、ホスト登録ができる。
- インターフェイス は 追加 を押下する必要がある。
- HA構成において、同一のデータベースを使用する構成であれば、スタンバイ機からも確認できる。
スタンバイ機WebUIからアクティブ機のホスト登録
上記と同じ手順で、今度はスタンバイ機からホスト登録をしてみます。
アクティブ機と同様に、スタンバイ機でもホスト登録できるようです。
ここでのポイントをまとめておきます。
- ホスト登録は、同一のデータベースを使用する構成であれば、アクティブ機、スタンバイ機のどちらからでも可能。
監視対象登録と注意点
監視対象にZabbixエージェントをインストールします。登録方法は公式サイトのダウンロードページを参照してください。
エージェントのインストールが完了したら、zabbix_agentd.conf
にて Server
ServerActive
にZabbixサーバのIPアドレスなどを指定します。
この時、アクティブ機とスタンバイ機の両方を記載する必要があります。
変更箇所は内容は以下の通りです。
# cat /etc/zabbix/zabbix_agentd.conf | grep -e Server= -e ServerActive= | grep -v \# Server=10.0.1.xxx,10.0.2.yyy ServerActive=10.0.1.xxx,10.0.2.yyy
修正したら、プロセスを再起動します。
systemctl restart zabbix-agent
WebUIから上記と同様にホスト登録します。ZBX
のアイコンが緑になれば、エージェントと疎通が取れたサインです。
フェイルオーバーとデータ欠損
フェイルオーバー
アクティブ機のエージェントを止めて、フェイルオーバーさせてみます。なおスタンバイ機ではHAステータス確認コマンドを0.5秒間隔でwatchしておきます。
watch -n 0.5 -d "zabbix_server -R ha_status"
ではエージェントを止めます。
systemctl stop zabbix-server
目測ですが、3秒程度でスタンバイ機のステータスが active
に変わり、アクティブ機のステータスは stopped
になりました。
# zabbix_server -R ha_status Failover delay: 60 seconds Cluster status: # ID Name Address Status Last Access 1. cldral4c60001gfmcilxa7znx zab6-ha-a 10.0.1.xxx:10051 stopped 2m 24s 2. cldrc132c0001qumefonhzi64 zab6-ha-c 10.0.2.yyy:10051 active 1s
公式ドキュメント には以下の記載があります。
フェイルオーバーはどのくらいの速さで実行されるか。 すべてのノードは5 秒ごとに最終アクセス時刻 (および変更されている場合はステータス) を更新します。 よって: - アクティブ ノードがシャットダウンし、そのステータスが"停止"と報告された場合、別のノードが 5 秒以内に引き継ぎます。 アクティブ ノードがシャットダウンするか、ステータスを更新できずに使用できなくなった場合、スタンバイ ノードは フェイルオーバー遅延 + 5 秒待機して引き継ぎます。
フェイルオーバー遅延はデフォルトで 1分
となっていますので、65秒以内 にスタンバイ機へ切り替わるようです。
その間のデータ取得と欠損状況を見ていきましょう。
データ欠損
今回は CPU utilization
のアイテムで見ていきます。 サイドバー > 最新データ > (必要に応じてフィルタ) > アイテムCPU utilization のグラフ
を確認してみます。
欠けていないよう見えます。(フェイルオーバー前に 監視対象のホストでCPU負荷をかけていたので 使用率100% になっています。)
グラフではわからないので、表示形式
を 値
に変えて確認してみます。コンソールログからコマンド実行時間は 20:09:58 でした。
なんと欠損していませんでした!
ただし、CPU utilizationのアイテムは 60秒間隔
で取得していることや、監視対象が少なくサーバの負荷が少ないため、データ欠損しなかった可能性もあります。取得間隔を狭く設定しているアイテムなどは欠損する可能性もあるかと思います。
また、データ欠損に関する公式ドキュメントはまだ見つけられておりませんので、あくまでも参考情報としていただければと思います。
ここでのポイントをまとめておきます。
- フェイルオーバーは 5秒以内、アクティブ機がシャットダウンやステータスを更新できずに使用できなくなった場合、スタンバイ ノードは フェイルオーバー遅延 + 5 秒待機して引き継がれる。
- アイテムの取得間隔や環境にも依存するが、データが欠損しない場合もある。
フェイルバック
1号機(旧アクティブ機)が障害から復帰したと想定して、エージェントを再起動させます。フェイルオーバー時と同様に2号機(現アクティブ機)でHAステータス確認コマンドをwatchしておきます。
systemctl start zabbix-server
エージェントを起動してすぐに、スタンバイとして復帰しました。
# zabbix_server -R ha_status Failover delay: 60 seconds Cluster status: # ID Name Address Status Last Access 1. cldral4c60001gfmcilxa7znx zab6-ha-a 10.0.1.xxx:10051 standby 2s 2. cldrc132c0001qumefonhzi64 zab6-ha-c 10.0.2.yyy:10051 active 1s
自動的にフェイルバックはされない ようです。
フェイルオーバー時のクライアントの挙動
クライアント側の zabbix_agentd.log
では以下のログが出力されていました。
# tail -f /var/log/zabbix/zabbix_agentd.log 7637:20230208:212004.870 Active check configuration update from [10.0.2.yyy:10051] is working again 7636:20230208:212104.896 Unable to connect to [10.0.1.xxx]:10051 [cannot connect to [[10.0.1.xxx]:10051]: [111] Connection refused] 7636:20230208:212104.896 Active check configuration update started to fail
アクティブチェックが切り替わった旨、Zabbixサーバに接続できなくなった旨のログが出力されていました。
クライアント側からZabbixサーバが切り替わったことは、判断しづらいかもしれません。
デフォルトで設定されているZabbix Serverのホスト
最後にデフォルトで登録されている Zabbix Server
のホストですが、インターフェイスは 127.0.0.1
とループバックアドレスを見に行ってます。フェイルオーバーが起こった時、どのようなデータになるのでしょうか。
検証前の状態は アクティブ機: zab6-ha-a
、スタンバイ機: zab6-ha-c
になっています。
まずスタンバイ機でCPU負荷をかけてみます。
Zabbix Server
と アクティブ機の zab6-ha-a
が近い値になっています。
ではフェイルオーバーさせて、プロセスを起動させます。
Zabbix Server
と アクティブ機の zab6-ha-c
が近い値になっています。
つまり 127.0.0.1
で登録すると、その時点での アクティブ機のデータ ということがわかります。
またグラフだけを見てしまうと、フェイルオーバーが発生していたことに気づけない かもしれません。
まとめ
Zabbix HA構成での監視登録やその挙動、フェールオーバー・フェイルバックについて、検証してみました。
それでは今回のまとめです。
- Zabbix6.0系でも、これまでのZabbixとほぼ同じ方法で、ホスト登録ができる。ただし、インターフェイス は 追加 を押下する必要がある。
- HA構成において、同一のデータベースを使用する構成であれば、スタンバイ機からもデータが確認やホスト登録ができる。
- 監視対象の
zabbix_agentd.conf
のServer
ServerActive
には アクティブ機とスタンバイ機の両方を記載する必要がある。 - フェイルオーバーは 5秒以内、アクティブ機がシャットダウンやステータスを更新できずに使用できなくなった場合、スタンバイ ノードは フェイルオーバー遅延 + 5 秒待機して引き継がれる。
- アイテムの取得間隔や環境にも依存するが、フェイルオーバーしてもデータが欠損しない場合もある。
- デフォルトではフェイルバックは自動的にはされない。
- デフォルトでホスト登録
Zabbix Server
は127.0.0.1
がインターフェイスに指定されているため、その時点での アクティブ機のデータ になる。
最後まで読んでいただき、ありがとうございました。
静 優(執筆記事の一覧)
オンプレからクラウドに転身したインフラエンジニア