前回は、Zabbixエージェント（Agent 2）をインストールしたWindows Serverを管理するために、Zabbix標準の「Windows by Zabbix agent active」テンプレートを複製して監視対象のホストにリンクしました。標準のテンプレートでどのような監視ができるのか詳しく見ていくつもりですが、その前にメール通知環境を整えておきたいと思います。
Zabbixは知機能もやっぱり“最強”？
システムの運用管理やサーバー監視には、通知機能が欠かせません。通知機能により、定期的にシステム全体の正常性を把握したり、障害にいち早く気付くことができます。電子メール（SMTP）による通知は、古くから利用されてきた最も一般的な通知方法です。一方で、電子メール環境に追加、強化されてきたセキュリティ機能は、通知設定を複雑化し、場合によっては監視ツール側の対応が追い付かなかったりすることがあります。
Zabbixは電子メールはもちろんのこと、SMS、カスタムスクリプト、Webhookによる通知をサポートしています。しかも、曜日/時間帯による通知先や通知方法の変更、通知できなかった場合の繰り返し通知やエスカレーション、監視対象のメンテナンスの際の通知抑制、メッセージテンプレートのカスタマイズなど、さまざまなシナリオに細かく対応できる柔軟性、拡張性に定評があるようです。
しかし、どんなことができるのか、使ってみないことにはよくわかりません。そこで私のラボ環境（Azureおよびオンプレミス）に用意したテスト用メール環境（→vol.20 WSL 2で作るクローズドなメール送受信環境のデモ）を利用して、Zabbixのメール通知環境を設定してみました。
メディアタイプ「Email」の設定と送信テスト
Zabbixでメール通知を行うには、電子メール送信用のメディアタイプを作成してテストします。今回は、標準で用意されているメディアタイプ「Email」を設定して、有効にしました。それには、Zabbix UIにログインして、「通知 > メディアタイプ」を開き、メディアタイプ「Email」をクリックして設定を開きます（画面1）。そして、メールプロバイダ「Generic SMTP」を選択して、SMTPサーバーのIPアドレスとポート番号、送信元メールアドレスなどを設定し、「有効」をチェックして、「更新」をクリックします（画面2）。テスト用メール環境はセキュリティなしで接続できるシンプルな環境なので、設定もいたって簡単です。
画面1 「通知 > メディアタイプ」からメディアタイプ「Email」（または「Email（HTML）」）の設定を開く
画面2 テスト用メール環境のSMTPサーバーとポート番号、送信元メールアドレスなどを設定して、このメディアタイプを有効にする
メディアタイプ「Email」を有効にしたら、メディアタイプ「Email」の右側の「アクション」列にある「テスト」をクリックして、宛先メールアドレスを入力し、「テスト」をクリックします。「メディアタイプのテストに成功しました」と表示され、宛先メールアドレスにメールが到達することを確認します（画面3）。
画面3 メディアタイプ「Email」をテストし、テストメッセージの受信を確認する
次に、有効にしたメディアタイプ「Email」を、ユーザーに追加します。今回は、Zabbixの既定のスーパーユーザー「Admin」に追加しました。「ユーザー > ユーザー」を開き、「Admin」の設定を開いたら、「メディア」タブに切り替え、「追加」をクリックします。ここでタイプ「Email」を選択し、送信先メールアドレスを入力します。その他の項目は既定のままにしました。設定画面を見るとわかるように、曜日と時間帯を指定できること、深刻度に応じた通知設定が可能なことがわかります（画面4）。
画面4 ユーザー「Admin」にメディアタイプ「Email」を追加し、送信先メールアドレスを入力する
CPU負荷テストを実施、でも肝心のメール通知がこない
ホストの監視に使用しているテンプレートを見ると、CPU使用率（CPU ulilization）のしきい値（{$CPU.UTIL.CRIT}）が90％に設定されており、5分間（監視間隔は1分間）にこのしきい値を超えると障害として報告するようです。そこで、Windows Sysinternalsの「CPU Stres（Microsoft Learn）」を使用して、CPU100％の状態を意図的に再現しました（画面5）。
画面5 監視対象のWindows Serverで、CPU Stresツール（Cpustres64.exe）を実行し、CPU使用率を100％に、しかしメール通知が来ない
Zabbixのダッシュボードには数分以内に「High CPU utlization」の障害が報告されましたが、メールによる通知がまったくありません。いろいろとZabbixの設定を確認していったところ、「通知 > アクション > トリガーアクション」にある「Report problems to Zabbix administrators」アクションを「有効」にすることで、メール通知が来るようになりました（画面6）。
画面6 メール通知のために、「Report problems to Zabbix administrators」アクションを「有効」にする
これでようやくメール通知環境が整いました。Zabbixはいろいろと、一筋縄ではいきません。
Microsoft 365によるメール通知: Zabbix v.s. BOM for Windows
Zabbixの電子メールに対応したメディアタイプには、汎用的な「Email」や「Email（HTML）」だけなく、「Gmail」や「Office365」も標準で用意されています。これらは、メールプロバイダとして「Gmail」や「Office365」が設定されています。このうち、メディアタイプ「Office365」を設定し、Microsoft 365（Exchange Online）経由でメール送信できるかどうか試してみました。しかし、メールプロバイダ「Office365」でも、「Generic SMTP」でセキュリティ設定を細かく設定しても、テスト結果は「Login denied」となりました（画面7）。
画面7 Zabbixではメール送信に（現在の）Microsoft 365を利用できない？
これはおそらく、2022年12月31日に行われたMicrosoft 365における基本認証（Basic認証）の無効化によるものでしょう。MicrosoftはMicrosoft 365において段階的に基本認証のサポートを削除してきましたが、SMTP AUTHでの基本認証のサポートが最後まで残されていました。それが完全に削除された現在、最新の認証方法（OAuth 2.0）を使用する必要があります。Zabbixのメディアタイプ「Office365」およびメールプロバイダ「Office365」は、Microsoft 365がOffice 365と呼ばれていたことからあるもので、最新のOAuth 2.0には対応していないようです。インターネットを検索すると、Office 365だけでなく、Microsoft 365になってからも、Zabbixのための設定が見つかりますが、現在のMicrosoft 365環境には適用できない可能性があります。あるいは、単に私の力不足が理由かもしれません。
参考:
Exchange Online での基本認証の廃止｜Microsoft Learn
Deprecation of Basic authentication in Exchange Online｜zabbix.com
Log in to Zabbix using OAUTH LOGIN｜zabbix.com
BOM for Windowsは、2022年6月リリースのBOM 8.0においてメール送信時の認証方式として、Microsoft 365で使用されているOAuth 2.0に対応しています（画面8）。詳しくは、以下の製品コラムをご覧ください。
BOM 8.0のMicrosoft 365向けOAuth 2.0対応について－BOM for Windows FAQ（仮）｜製品コラム
画面8 BOM 8.0からは、一般的なSMTP認証に加えて、Microsoft 365のOAuth 2.0認証をサポート
BOMの通知機能としては、メール送信以外にも、メール送信、イベントログ書き込み、SNMPトラップ送信、Syslog送信、RDSクライアント通知（リモートデスクトップ接続ユーザーへの通知）、アラートフィルター（BOM 8.0 SR1の新機能）、カスタム通知、警告灯（カスタム通知を利用）を用意しています。
