ZabbixでLinuxのログを監視する方法(syslogを例に設定手順を確認)

2025-09-28Others,Rocky Linux/CentOS,Zabbix

ZabbixでLinuxのテキストログを監視する場合の手順です。

Linuxの/var/log/messagesの監視を例として、Zabbixでシステムログを収集するためのアイテム作成、システムログへのアクセス権限付与、ログのフィルタリング設定、トリガー設定など、一連の手順を確認しています。
また、ログ監視に使用するアイテムキーの概要も紹介しています。

※手順確認には、Zabbixのバージョンは7.0LTS(7.0.17)を使用しています。
※手順確認には、Rocky Linux release 9.6 (Blue Onyx)を使用しています。
※今回は、Zabbix エージェント2を利用した場合の手順を中心に確認しています。

ZabbixでLinuxのログを収集するためのアイテム設定手順

テキストログ監視用のアイテムが用意されている

Zabbixには、messagesなどのテキストログを監視するためのアイテムが用意されています。

log
logrt

ログ内の特定の文字列や正規表現に一致した場合のみデータを収集することができ、トリガーと連携させることでアラート通知も可能です。
これらのアイテムは、Zabbixエージェントのアクティブチェックでのみ動作します。
Zabbixエージェントは、監視対象のログファイルのサイズや最終更新時刻などの情報を保持しています。
また、ログファイル内の読み込んだ位置を記憶しておき、次回のチェック時には前回の続きからログを読み取ります。

収集データの送信

これにより、毎回ログファイル全体をチェックするのではなく、新たに追記された部分のみを監視する仕組みとなっています。

また、ログの件数をカウントするためのアイテムも用意されています。

log.count
logrt.count

項目	log	logrt
タイプ	zabbixエージェント(アクティブ)
監視対象ログの指定	固定	正規表現
ログローテーションを検知した場合の動作	ログファイルを先頭から読み込む	直前に読み込んでいたファイルを末尾まで読んでから最新のファイルを先頭から読み込む

move形式、copytruncate形式どちらのログローテーション形式にも対応

move形式、copytruncate形式の両方のログローテーション形式に対応しています。

Zabbixエージェントの実行ユーザーにログへのアクセス権が必要

Zabbixエージェントは監視対象のログファイルを直接読み込みます。
Zabbixエージェントを実行するユーザー(通常はzabbixユーザー)に、管理対象のログファイルを読み取る権限が必要となります。
特に/var/log/messagesなどの重要なシステムログは、デフォルトではrootユーザーのみが参照できる状態となっています。
そのため、ログファイルへのアクセス権限設定が必要になります。

※Zabbixエージェントをrootユーザーで起動する方法もありますが、セキュリティリスクが高まるため注意が必要です。

logrtのアイテムキーの設定内容

今回は、ローテーションを行うログファイルを監視するため、logrtアイテムキーを使用しています。
logrtアイテムキーでは、監視対象となるログファイル名や、ログフィルタリング用の文字列を設定します。

logrt

ログファイル名は必須項目であり、必ず指定する必要があります。ディレクトリでの指定はできません。

logrtのアイテムキーの設定内容
logrt[file regexp,<regexp>,<encoding>,<maxlines>,<mode>,<output>,<maxdelay>,<options>,<persistent dir>]
file regexp	監視対象のログファイル名を指定します。 ファイルパスはフルパスで指定します。 正規表現も利用可能です。
regexp	ログフィルタリング用の文字列を指定します。 監視対象のログの内容に対してフィルタをかけたい場合に使用します。 正規表現も利用可能です。
encoding	ログファイルの文字コードを指定します。 デフォルト値はUTF-8です。 エンコーディング設定
maxlines	1秒間に送信するログの最大行数を指定します。 この値はzabbix_agent2.confの設定値を上書きします。
mode	アイテム登録時に過去のログを含めてすべてチェックするかどうかを指定します。 allまたはskipから選択できます。 デフォルト値はallです。 skipを指定すると、アイテム登録時点以前のログはスキップされ、以降に追加されたログのみが監視対象となります。
output	Zabbixサーバーに送信するログの形式(フォーマット)を指定します。 正規表現を使用して、送信するログの内容を定義できます。
maxdelay	最大何秒以内に処理できるログを対象とするかを指定します。 古いログ行が無視される場合があるため、利用にあたっては注意が必要となります。 maxdelay パラメータの使用
options	監視対象となるログファイルのログローテーションタイプを指定します。 バージョン5.0.2以降では非推奨のオプションとされています。
persistent dir	ログの読み込み状況をファイルに保存する場合に使用します。 保存するファイルのディレクトリを指定します。 Zabbixエージェント2ではサポートされていません。 永続化ファイルの目的

※アイテムキーのフォーマットの説明については、こちらに記載されています。

アイテムキーのフォーマット

Zabbixユーザーにログ(/var/log/messages)へのアクセス権を付与

Zabbixユーザーに/var/log/messagesへの読み取り権限を付与します。
ログローテーション時の設定と、既存ファイルへのアクセス権付与を行います。

※今回は、簡易的な設定としています。そのため/var/log/maillogなどにもzabbixユーザーへのアクセス権限が付与されます。

アクセス権を付与する前の状態です。 [root@vm-02 ~]# ls -l /var/log/ |grep messages -rw——-. 1 root root 824165 Sep 27 03:57 messages -rw——-. 1 root root 337443 Aug 20 07:46 messages-20250827 -rw——-. 1 root root 658771 Aug 30 09:46 messages-20250907 -rw——-. 1 root root 918406 Sep 12 06:06 messages-20250916 -rw——-. 1 root root 550531 Sep 18 09:22 messages-20250921

rsyslogでログローテーション時にログファイルの権限を付与します。 logrotateの設定ファイルを編集し、createオプションでパーミッションと所有者・グループを指定します。 [root@vm-02 ~]# vi /etc/logrotate.d/rsyslog /var/log/cron /var/log/maillog /var/log/messages /var/log/secure /var/log/spooler { 　　missingok 　　sharedscripts 　　create 0640 root zabbix　# 追加 　　postrotate 　　　　/usr/bin/systemctl -s HUP kill rsyslog.service >/dev/null 2>&1 || true 　　endscript }

既存のログファイルに対してZabbixユーザーに読み取り権限を付与します。 また、Zabbixユーザーで監視対象のログが正しく読み取れるかも確認します。 [root@vm-02 ~]# chgrp zabbix /var/log/messages* [root@vm-02 ~]# chmod 0640 /var/log/messages* [root@vm-02 ~]# ls -l /var/log/ |grep messages -rw-r—–. 1 root zabbix 824597 Sep 27 04:23 messages -rw-r—–. 1 root zabbix 337443 Aug 20 07:46 messages-20250827 -rw-r—–. 1 root zabbix 658771 Aug 30 09:46 messages-20250907 -rw-r—–. 1 root zabbix 918406 Sep 12 06:06 messages-20250916 -rw-r—–. 1 root zabbix 550531 Sep 18 09:22 messages-20250921 [root@vm-02 ~]# sudo -u zabbix tail -n 3 /var/log/messages Sep 27 04:37:44 vm-02 systemd[1]: Started Zabbix Agent 2. Sep 27 04:37:44 vm-02 zabbix_agent2[8803]: Starting Zabbix Agent 2 (7.0.18) Sep 27 04:37:44 vm-02 zabbix_agent2[8803]: Zabbix Agent2 hostname: [vm-02]

サービスを再起動します。 [root@vm-02 ~]# systemctl restart rsyslog [root@vm-02 ~]# systemctl restart zabbix-agent2

ログを収集するアイテムの作成手順

アイテムを新規作成する場合は、ホストのアイテム作成から開始します。

アイテムの作成

/var/log/messagesのログを収集する設定としています。
フィルタリング用の文字列として、alert、crit、error(大文字小文字を区別しない)を指定しています。
アイテム名はLog Monitoringとしています。

今回は、file regexpに/var/log/messagesと指定しています。
この場合/var/log/messages*と同様の設定となります。
/var/log/messagesおよび/var/log/messagesで始まるすべてのファイルが監視対象となります。

運用環境で利用する場合には、必要以上に多くのログファイルが監視されないよう、注意して設定します。

※modeにskipを指定しています。

システムログを収集するアイテムを作成
対象ホストのアイテムを選択します。
アイテムの作成を選択します。
新規アイテム作成画面が表示されます。 タイプをZabbixエージェント(アクティブ)に変更します。 キーを選択します。
アイテムキーの選択画面が表示されます。 logrtのアイテムキーを選択します。
アイテムの名前を設定します。 キーを設定します。 データ型がログであることを確認します。 監視間隔を設定します。 追加を選択します。 ※今回、監視間隔は1秒としています。
設定したアイテムキー logrt[/var/log/messages,"(?i)(alert|crit|error)",,,skip]
アイテムが作成されたことを確認できます。

アイテムで収集したログを最新データで確認

作成したアイテムで、ログが収集されているかを確認します。
監視データのメニューにある、最新データから確認しています。

最新データ

収集したログを確認
loggerコマンドを使用して、テスト用のメッセージを書き込みます。	[root@vm-02 ~]# logger “test error from zabbix"
最新データで作成したアイテムのヒストリを表示します。 ログが収集されていることを確認できます。

※最新データの表示は、他のメニューからも可能です。

Zabbixユーザーがログにアクセスできない場合はPermission Deniedエラーになる

監視対象のログに対してZabbixユーザーにアクセス権がない場合は、Permission Deniedエラーになります。
監視対象に指定したすべてのログに対して、Zabbixユーザーにアクセス権が必要です。

エラーメッセージの例
読み取り権限がないため、Cannot open file “監視対象のログ": Permission Deniedというエラーメッセージが表示されます。

※最新データの表示は、他のメニューからも可能です。

ログ監視間隔は短くする

手順では監視間隔を1分にしていますが、Zabbixエージェントによるログ監視では監視間隔を短くすることが推奨されています。
ログ監視では、Zabbixエージェント側でログをチェックし、Zabbixサーバー側にログを送信しています。
そのため、短い間隔でチェックした方が1回のチェック件数が少なくなり、処理負荷を平準化できます。

※Zabbixサーバー側の負荷なども確認しながら、監視間隔は設定します。

収集するログは件数は減らす

アイテムキーの設定に合致したログをZabbixエージェント側でチェックし、Zabbixサーバー側に送信します。
Zabbixサーバー側では、受信したログがトリガー条件に合致するか評価したり、データベースに書き込みを行います。
そのため、送信されるログが少ないほど、Zabbixサーバーの負荷を軽減できます。

—広告—

ZabbixでLinuxのログを監視するためのトリガー設定手順

ログに関するトリガー関数

ログに関するトリガー関数も用意されています。

ヒストリ関数

※ZabbixのWeb画面上では、文字列関数の区分にありますが、Zabbixの公式ホームページ上では、ヒストリ関数の項目にfindやcount関数が記載されています。

ログに関するトリガー関数
find	指定した値に一致するデータを検索します。 検索する値の指定には正規表現が利用可能です。 マッチした場合もしくはマッチしない場合にトリガーを実行させることができます。
count	指定した値に一致するデータを検索し、件数をカウントします。 検索する値の指定には正規表現が利用可能です。 件数に応じてトリガーを実行させることができます。

ログ監視用のトリガー作成手順

ホストのトリガー作成から開始します。
作成したアイテムを利用して、トリガーを作成します。

トリガーの設定

トリガーでは検知対象の文字列を指定せず、アイテムで収集したログデータに対して発動するように設定しています。
トリガー名はLog Monitoring(Error)としています。

※検証用の設定です。今回の設定だと、アイテムで収集したすべてのログが検知対象となります。そのため大量にアラート検知してしまう可能性があります。

ログ監視用のトリガーを作成
対象ホストのトリガーを選択します。
トリガーの作成を選択します。
新規トリガー作成画面が表示されます。 トリガー名を設定します。 条件式の追加を選択します。
トリガー条件式の設定画面が表示されます。 作成したログのアイテムを選択します。
関数には文字列関数のfind()を選択します。
最新の1カウントを指定します。 合致条件や文字列は空白のままとしています。 結果には1を指定します。 ※結果1は合致した場合を意味します。
条件式を追加します。 正常性イベントの生成はなしを選択します。 障害イベント生成モードは複数を選択します。 手動クローズを許可にチェックを入れています。 追加を選択します。 ※深刻度は警告としています。
設定したトリガー条件式 find(/vm-02/logrt[/var/log/messages,"(?i)(alert|crit|error)",,,skip],#1)=1
トリガーが追加されたことが確認できます。

対象となるログを発生させて障害検知できるかを確認

監視対象のホストで対象のログを発生させ、Zabbixで障害検知できるかを確認します。

障害検知を確認
loggerコマンドを使用してテスト用のメッセージを書き込みます。 最新データを確認すると、ログが収集されていることを確認できます。	[root@vm-02 ~]# logger “test error from zabbix"
障害の発生状況を確認します。 Zabbixに収集されたログに基づき、障害が検知されていることを確認できます。 最新データのタイムスタンプと、障害イベントの発生時刻が一致していることも確認できます。

正常性イベントについて

正常性イベントの生成は、障害イベントが復旧したと判断する条件です。

トリガーイベントの生成

ログ監視の場合は、復旧とみなすログの条件式を指定します。
正常性イベントの生成に条件式を指定した場合、条件式に合致しないログを検知した際に障害イベントが自動的に復旧します。
復旧条件式を指定した場合は、復旧条件式に合致するログを検知した際に障害イベントが自動的に復旧します。

手動クローズについて

通常は、障害状態から復旧したと判断された場合、障害イベントは自動的にクローズされます。
クローズの条件式が複雑な場合などは、手動でクローズする設定を利用します。

問題の手動クローズ

復旧を示すログが出力されない場合は、障害イベントがクローズされずに残ってしまいます。
そのため、手動でクローズできるように設定する必要があります。

障害イベント生成モードについて

障害イベントの生成モードには単一と複数があります。
ログを連続して検知したい場合は、障害イベント生成モードには複数を選択します。

障害イベント生成モード
単一	最初の障害を検知した場合のみ、イベントを生成します。 連続して障害となるログを収集した場合は、最初の1件だけが障害イベントとして生成されます。
複数	障害となるログを収集するたびにイベントを生成します。 連続して障害となるログを収集した場合は、その都度障害イベントが生成されます。

監視対象外とする文字列の設定方法(非監視文字列の設定)

同じfindのトリガー関数で、非監視文字列を設定することも可能です。
この場合、非監視としたい文字列を条件として指定し、それに合致しない場合にトリガーが実行されるように設定します。
パラメーターには、iregexpを使用しています。
パターンに指定する文字列は、大文字と小文字を区別せずに判断されます。

find

testという文字列が含まれる場合は、トリガーが実行されないように設定しています。

※今回は検証目的の設定です。条件式を組み合わせて使うことでより細かい設定ができます。

非監視文字列の設定方法
条件式を修正します。 パラメーターにはiregexpを設定し、文字列にはtestを指定します。 条件は0の場合と設定します。 ※条件を1に設定すると一致した場合に、0に設定すると一致しなかった場合にトリガーが実行されます。
設定したトリガー条件式 find(/vm-02/logrt[/var/log/messages,"(?i)(alert|crit|error)",,,skip],#1,"iregexp","test")=0
トリガーが変更されていることを確認できます。

監視対象外とした文字列が含まれる場合のトリガー動作を確認

監視対象のホストで対象のログを発生させ、Zabbixで障害検知できるかを確認します。

ログオンエラーの検知を確認
loggerコマンドを使用してテスト用のメッセージを書き込みます。 非監視の文字列として設定した、testを含むログと含まないログを書き込みます。 最新データを確認すると、ログが収集されていることを確認できます。	[root@vm-02 ~]# logger “test Error from zabbix 1" [root@vm-02 ~]# logger “test Error from zabbix 2" [root@vm-02 ~]# logger “Error from zabbix 1" [root@vm-02 ~]# logger “Error from zabbix 2"
testという文字列を含まない場合のみ、障害が検知できていることが確認できます。

※今回の設定方法は1つの例です。いろいろな設定方法があります。

—広告—

最後に

今回は、Linuxのシステムログを例に、Zabbixでログを監視する手順を確認しました。
アイテムの作成からトリガーの作成までの一連の流れを確認しました。

ログローテーションに対応できるアイテムキーが用意されていることも確認できました。
また、トリガー設定では、監視対象外とする文字列を設定できることも確認できました。

引き続き、いろいろ試してみたいと思います。

ZabbixでWindowsのイベントログを監視するための手順については、こちらで紹介しています。

自動登録アクションを利用したホストの自動登録手順については、こちらで紹介しています。

Zabbix エージェントのインストールや暗号化通信の有効化手順については、こちらで紹介しています。

Zabbixのアクションのメール送信でSendGridを使う方法は、こちらで紹介しています。

Azure Monitorを利用してWindows Serverのイベントログを監視する手順については、こちらで紹介しています。