“ZabbixでWindowsイベントログを監視するのは難しい”というウワサは前々から聞いていました。どのように難しいのかは、よく知りません。今回は、その難しいとウワサされるZabbixを使用したWindowsイベントログの監視に挑戦します。

監視対象のダミーのイベントログ

　インターネットを少し検索すると、Zabbixでは難しいと言われているWindowsイベントログを“簡単に監視”するために、フリーソフトを利用してイベントログをテキストログ化し、Zabbixにテキストログを監視させるというブログ記事を見かけましたが、何とも回りくどいやり方で、とても簡単に監視できているようには感じませんでした。そもそもフリーソフトに頼らなくても、Windowsには標準でイベントログをテキストとして取得する方法がいくつも用意されています。例えば、「WMIC」（非推奨）や「WEVTUTIL」コマンド（→Microsoft Learn）や「Get-EventLog」コマンドレット（非推奨）、「Get-WinEvent」コマンドレット（→Microsoft Learn）です。

　今回は、裏技のようなことは考えず、Zabbixの本来の監視方法でWindowsイベントログを監視してみたいと思います。監視対象はWindows標準の「EVENTCREATE」コマンド（→Microsoft Learn）を使用して意図的に「Application」ログに書き込んだ、ソース「MyApp」、イベントID「999」のレベル「エラー」のイベントがターゲットです（画面1）。WindowsではEVENTCREATEコマンド以外にも、「Write-EventLog」コマンドレット（→Microsoft Learn）を使用してイベントログを書き込むことができます。


画面1　監視対象のイベントログは、「Application」ログのソース「MyApp」、イベントID「999」のレベル「エラー」のイベント

Zabbix標準のWindowsイベントログ監視、何回やっても難解だった

　Zabbixの標準テンプレート「Windows by Zabbix agent active」を複製した「My Windows by Zabbix agent active」に対してイベントログの監視設定を追加してみます。

　Zabbix UIにログインし、「データ収集｜テンプレート」を開き、「My Windows by Zabbix agent active」の行にある「アイテム」リンクをクリックして開きます。ページ右上にある「アイテムの作成」をクリックします。この作成ボタンが巨大なページの右上に配置されていることには、まだ慣れません。

　「新規アイテム」では、アイテムの名前を入力し（例: Windows Application Log）、タイプ「Zabbixエージェント（アクティブ」」を選択して、キーの横にある「選択」をクリックして、「eventlog[name,<regexp>,<severity>,<source>,<eventid>,<maxlines>,<mode>]」を選択します。その後、キーのテキストボックス内で「eventlog[application]」に変更します。その他の項目は既定のまま、「有効」にチェックが入っていることを確認して「追加」をクリックします（画面2）。なお、タイプ「Zabbixエージェント」を選択した場合、eventlogキーは選択肢に表示されなかったので、イベントログの監視のためにはAgent 2のエージェントが必要なようです。

画面2　「eventlog[application]」のアイテムを追加する

　このアイテムの追加は、「Application」ログを監視するために必要になります。今回は使用しませんが、システム（system）ログとセキュリティ（security）ログのアイテムも追加しておきました（画面3）。

画面3　イベントログのログファイルごとに対応するアイテムを追加した

　続いて、同じテンプレートの「トリガー」をクリックして開き、「トリガーの作成」をクリックします。このトリガーで、イベントログの監視条件を定義していきます。

　「新規トリガー」では、分かりやすいトリガー名とイベント名を入力し、深刻度を選択して（今回は「軽度の障害」を選択）、「追加」をクリックします。「トリガー条件式」ではアイテムとして先ほど追加した「テンプレート名: Windows Application Log」を選択し、「logeventid()」「logsource()」「logseverity()」を選択して、条件式を追加していきます（画面4）。

画面4　トリガー条件式を追加していく。この例の場合、3行目を「カウント」にすることで追加することができた

　これがなかなか厄介でした。インターネットを検索しながら、何度も条件式を調整し、実際にイベントログを書き込んで監視テストを繰り返して、ようやく条件式が完成しました（画面5）。

画面5　試行錯誤の上、ようやく完成したトリガー条件式。複数の条件式は「and」でつなげればいいらしい

　「Application」ログからイベントID「999」、ソース「MyApp」、レベル「エラー」のイベントを監視するための、最終的なトリガー条件式は次のようになりました。

　最も苦労したのが、logseverity()の条件式です。Windowsイベントログ上ではイベントレベル「エラー」は「2」（Level=2）に対応しますし（イベントビューアーの「現在のログをフィルター」ダイアログボックスの「XML」タブで確認可能）、「Win32_NTLogEventクラス」（Microsoft Learn）では「1」（EventType=1）です。Zabbixで監視する場合、そのどちらでもありません。答えは、Zabbix古いバージョン2.2のドキュメントに見つかりました。Zabbixでイベントレベル「エラー」のイベントは「4」（logseverity()=4）で検出するのです。

Supported trigger functions｜ZABBIX Documantation
“Windows event logs: 1 - Information, 2 - Warning, 4 - Error, 7 - Failure Audit, 8 - Success Audit, 9 - Critical, 10 - Verbose”

　以上の設定により、監視対象のWindows Serverでイベントを発生させると（書き込むと）、数分以内に障害としてZabbix UIの「ダッシュボード」に表示され、管理者にメールが送信されることを確認できました（画面6）。

画面6　テンプレートに追加したアイテムとトリガーにより、目的のイベントログの発生を障害として報告するようになった

イベントログ監視対決: Zabbix v.s. BOM for Windows

　Windows Serverのサーバー監視では、Windowsイベントログを監視することで、システム障害やその予兆、不正侵入やマルウェア感染、脆弱性の悪用をいち早く検知し、迅速なアクションを可能にします。また、システムの正常性やパフォーマンスのボトルネックを把握するための必要な情報を継続的に取得することができます。

　今回挑戦したZabbixによるWindowsイベントログの監視は、ログファイル、イベントID、ソース、レベルでイベントログを監視するという、基本中の基本です。アイテムのキー「eventlog[name,<regexp>,<severity>,<source>,<eventid>,<maxlines>,<mode>]」の書式を見れば分かるようにアイテムレベルで深刻度やソース、イベントIDなどを絞り込むこともできますし、キーの指定やトリガーの条件式では正規表現も利用できます。これらをうまく活用すれば、詳細なイベントログ監視が実現できるでしょう。しかし、今回の簡単な例を見ただけでも、適切な監視設定を行うのは“難しい”というのは本当でした。これは、まだまだZabbixの経験の浅い私の、あくまでも個人的な感想です。

　弊社製品BOM for Windowsは、Linuxやクラウドを含むさまざまな運用環境の監視に対応していますが、元々はWindows Serverのサーバー監視ツールとして生まれました。Windowsイベントログの監視は最も得意とするところです。BOM標準の監視設定「イベントログ監視」を使用すれば、GUIを使用して、イベントログ監視のための複雑な条件を直観的な操作で定義することができます。ログファイルやソース、イベントIDはWindowsに最初から用意されているものから、あるいは実際に記録されているイベントから選択して定義することができ、特別な知識は何も必要ありません。正規表現の使用を含むテキスト検索による検出または除外設定にも柔軟に対応できます（画面7、画面8）。さらに、「イベントログ監視」の「除外フィルター」機能（Ver.7.0 SR1で追加された新機能）を利用すると、収集済みのログの解析結果から選択する方法で除外設定を簡単に定義することがで、不要なログが収集されるのを回避できます。

画面7　Windowsイベントログが提供する大量のソース/チャネルから、監視したい対象を選択

画面8　既に記録されている実際のイベントからイベントIDを検索して条件に設定

　BOMではGUIですばやく監視設定を追加できるため、例えば脆弱性の悪用を監視するために監視するべきイベントログとその詳細がセキュリティアドバイザリとして公表されたとき、すばやく対応し、すぐに監視を開始できるという利点があります（例: KB5040268: CVE-2024-3596 に関連付けられている Access-Request のパケット攻撃の脆弱性を管理する方法）。

複雑なイベントログ監視をBOMにお任せ: BOMのZabbix連携

　BOMでは監視結果をログにファイル出力したり、Syslogサーバーに送信することも簡単です（画面9）。複雑なイベントログ監視設定はBOMで行って、これらの機能を使用してZabbixを含む他の監視ソリューションと連携することも可能です。詳しくは、以下の製品紹介資料を参照してください。

BOM for Windows Ver.8.0 製品機能紹介資料｜カタログセンター


画面9　BOMのログファイルエクスポート機能やSyslog送信機能を利用して、Zabbixに監視データをテキストログとして送信し、Zabbixの強力なログ監視機能で監視することもできる

　参考までに、画面8でログファイルに出力したテキストファイルをZabbixで監視し、障害として報告するように実装した例を紹介します。以下は、Zabbix側でログファイルの存在（vfs.file.exists[]キーを使用）とタイムスタンプ（vfs.file.Time）を取得する2つのアイテムを作成し、トリガーとして「ログファイルが存在する」かつ「前回との差が600秒以内（change()<600）」の場合、「軽度の障害」とするトリガーを作成したものです（画面10、画面11）。ログファイルの内容（vfs.file.contents[]キーを使用）の取得や、内容の検索（vfs.file.regexp[]キーを使用）、ローテーションするログの監視（logrt[]キーを使用）など、ログベースの詳細な監視を実装することも可能です。しかし、詳細な条件監視をBOMに任せることが目的なので、Zabbix側のアイテムやトリガーを極力簡潔にするのが良いでしょう。

画面10　Windowsエージェント側のログファイルの存在とタイムスタンプに基づいて障害を報告するトリガー

画面11　BOMのログファイルを監視して目的のイベントログを障害として報告