Azure上のZabbixサーバーからPing監視を試す
久しぶりの更新です（ぐはっ）
たまに、ですが、オンプレで動いている監視機能要件をAzure
へ切り替えたいんだけど、といったこれまで使っていた監視
システムをベースに、それぞれどうするよ的な話がありますね。
もちろんAzure MonitorやLog Analytics、Application Insightなど
監視だけでなく統計、可視化、自動対応などなど様々なソリュ
ーションサービスを組み合わせることでできることも多いですが
「今までやってきた機能要件」をマスト要件とした場合、Azure
だと、、、っと相いれない状況になってくることもあります。
代表的なものの１つとしてping(ICMP)の死活監視やSNMPの
ネットワーク監視がありますが、いまどきpingで死活監視と
いう会話はなくなってきている一方で、オンプレではそう
やってたのでそのままクラウド上にも、という話や、まずは
AS Isで移行したく、といった話もありーの、なかなか避け
て通りづらい代物でもあります。
これから触れる内容はAzure上でZabbixを使いping監視を
やってみるか、というものですが、誤解してほしくないのは
pingを推奨しているわけではない点です。
むしろpingは無くても構わない、ぐらいの感覚でいます。
過去pingを悪用された攻撃が話題になりセキュアなやり方では
ない点や、pingはそもそもNiCまでのパケット通信をやりとり
するネットワーク経路を見てるだけで、といった本質的な
観点から「正しい、だから違う手段で」と解釈できる方は
この記事は無用ですので、あらかじめ。
でも一方で、Azureでping監視って、そもそも推奨してない
のはわかったけど、やればできるの？とか、AWSでは
セキュリティグループの設定でICMPを許可するってやれば
ICMP通信も個別で許可できるんだけど、AzureのNSG
では現実解として許可できないよね？とか、まぁ、素朴な
疑問を持つ方、自己責任で納得性がほしい方もいらっしゃる
のも事実です。
なので推奨はしないけど、Azureだとこうやればできるけどね
という情報を少し出しておきます。
今回やるやり方はZabbixサーバーをAzure上に立て、Azure VM
にZabbix agentを入れて行う監視方法ですが、先に答えを
言っちゃうと、ポイントはOver Internetで通信しない、という
点と監視サーバーは監視対象の同一リージョンには配置しない
という観点です。
AzureではLBのVIPもそうですが、そもそもinboundもoutbound
もどちらもping(ICMP)を非推奨としていますので、プロトコルや
ポートの制限のないプライベートネットワーク間で監視する
という方針です。
でははじめましょ。
まずZabbix サーバーを東アジアリージョンで構築します。
監視対象のメインは東日本リージョンと西日本リージョンに
展開されたVMと想定しています。
以下、Zabbixサーバー側の環境です。
・OS:CentOS 7.5
・VM Size:D2v3 (Hyper Threadingのやつ：特に意図なし）
・Disk: Managed-disk
・NiC: １つ
・vNET+Subnet: 10.1.0.0/16 + 10.1.0.0/24
・Storage Account: １つ（診断用）
・可用性セット: １つ（FD3,UD5）
Zabbix WebUIにアクセスしZabbixサーバー本体のシステム
情報を見た画面が以下です。
構築方法は以下の記事がきれいにまとまってました。
Zabbix 4.0は少し提供が遅れているのかな？待ち遠しいですが
ここは3.0でとりあえずやってます。
また、上記手順にない部分として以下は適当に対応しておき
ました。
〇Adminでのログインパスワードの変更
〇swap領域の設定(CentOS側でswap領域を作成）
# dd if=/dev/zero of=/var/swapfile bs=1M count=2048
# chmod 600 /var/swapfile
# mkswap /var/swapfile
# vi /etc/fstab⇒ /var/swapfile none swap defaults 0 0
# swapon -a
※これやっとかないとzabbix WebUIではswap領域がねぇ！
って言われちゃうんで。
〇WebUI画面のカラー変更
ここまでは、とり合えず東アジアリージョンにZabbix
サーバーが１台立った、というだけです。
Zabbixサーバーの冗長化については多くの記事がありますので
ここでは触れていません。手っ取り早く金かけて解決するなら
Zabbix Enterpriseでサポート契約（有償）することでデータ
移行ツールが手に入るため、そちらを利用して冗長構成を
組むとよいかもしれませんね。
また、MariaDBではなくAzure Database for MySQLのPaaS
をZabbixサーバーのDB領域としてご利用される場合は以下の
記事が参考になります。ご参考まで。
Azure Database for MySQL を Zabbix のバックエンドで使ってみる
では次に東日本リージョンと西日本リージョンに展開されて
いるAzure Linux VMにZabbix agentを入れたいわけですが
その前にやっておくことが１つあります。
Global vNET Peeringの設定です。
Global vNET Peeringは、異なるリージョン間のアドレス帯の
異なるvNET同士をピアリングする、かつ通信はMicrosoftの
バックボーン経由で、という超絶目からうろこな機能です。
ただ、現時点ではAzure ADテナントが同一である必要がある
ようなので、同じテナント内で管理されているサブスクリプ
ションや１サブスクリプション内で、異なるリージョン間の
vNETをピアリングする場合に有効です。
手順はAzure Portalの操作だけで完結しますが、ポイントは
ピアリングしたい元となるvNET側と先となるvNET側の双方で
ピアリングの設定を行うことで、はじめてピアリング接続が確立
するよ、という点です。（片方だけ設定してもダメよ）
以下、Zabbixサーバー側のvNETでピアリングする際の画面です。
片方だけの設定だと「ピアリング状態」が「開始済み」になって
いますね。これは双方で設定すると「接続済み」に変わります。
今回はvNETセグメントを以下のように設定しておきました。
〇東アジアリージョンvNET(Subnet)
10.1.0.0/16 (10.1.0.0/24)
〇東日本リージョンvNET(Subnet)
192.168.2.0/24 (192.168.2.0/25)
〇西日本リージョンvNET(Subnet)
172.10.0.0/24 (172.10.0.0/25)
※Global vNET Peeringの状況
10.1.0.0/16 と 192.168.2.0/24 間でGlobal vNET Peering
10.1.0.0/16 と 172.10.0.0/24 間でGlobal vNET Peering
どちらも「接続済み」ステータスが確認できれば、Zabbix agent
のインストールにいきます。
以下の記事がまとまってて参考になります。
※最後のfirewall-cmdの個所ですが、ここはポートを追加して
いますので、最後に「firewall-cmd --reload」を叩いて反映
させましょう。
あと、最後に以下でagentを起動/確認しましょう。
# systemctl start zabbix-agent
# systemctl enable zabbix-agent
# systemctl status zabbix-agent
ここまででサーバー側/OS側の作業は終わりです。
あとはZabbixのログイン画面にAdminでログインして
設定＞ホスト＞ホスト追加 から東日本リージョンと
西日本リージョンのVMを指定してあげましょう。
テンプレートは標準にあるTemplate OS Linuxでとりあえず
よいでしょう。
ちなみにTemplate OS LinuxにはZabbix agent pingという
のが含まれていますが、ここではあえてicmppingをアプリ
ケーション＋イベント登録して実装してみました。
以下のping-checkという名前が東西の仮想マシンに適用した
時の画面です。
グラフで見ると以下のようにちゃんと取れているようです。
念のためAzure Portalから西日本リージョンの仮想マシンを停止させた
時のグラフです。ちゃんと１から０に変わってますね。
pingのテンプレートについては以下が参考になります。
Zabbix 3-1. サーバ死活（Ping）監視テンプレート設定 | あぱーブログ
バージョンが異なるので見た目が違う部分はありますが
基本的な流れは上記の通りで設定できます。
最後に、注意点を１つ伝えておきます。
オンプレでは専用の回線を直結して、といった環境のため占有
リソースで組み立てられていますが、パブリッククラウドでは
共有リソースになるため、一時的にスループットが落ちたり
裏側のメンテナンスによってデータの反映が遅れるケースは
あります。
Zabbixは柔軟にカスタマイズできる分、監視するポーリングの
頻度やリトライの閾値などを監視項目別に設定できますが、
オンプレで正常だったから、という理由でそのままの閾値で
パブリッククラウドへ展開すると、エラー検知の頻度が上がり
都度細かく調査しても結果的にサービスへの影響はほとんど
ないのに過剰検知されたため調査時間や対応時間だけが無駄に
かかった、とか、冗長構成とってたけど死活監視で死んだと
判定されたためPrimaryが切り替わった、といったことが発生
ついては、オンプレとは別軸で再度見直す＆試験運用する
ことをお薦めします。
以上ですが、要点をまとめると以下です。
〇監視システムは監視対象リージョンとは異なる地域に
配置すべし
Over InternetのPublic IPの経路で監視せずにPrivate IP間
で監視すべし
〇Azure Global vNET Peeringを活用すべし
試験運用期間を通じて見定めていくべし
〇Azureが提供される機能に満足できない場合はOSSを
積極的に試すべし
今回はこのへんで。
