【決定版】Zabbixログ監視を徹底解説！ ～設定の基本から、安定稼働を実現する運用ノウハウまで～

本ページでは、Zabbixでのログ監視設定の手順に加え、”初歩でのつまずきポイント”や、運用開始後に起きてしまう”よくある問題”と解決策について解説します。

Zabbixのログ監視は、Zabbixエージェントがあらかじめ指定したログファイルを読み取り、設定した条件に合致するログをZabbixサーバーへ送信する仕組みです。

ログの文字列やWindowsイベントログID、ソース等、様々な情報から検知文字列を指定できるため、柔軟な監視設定が可能です。

▼よくある監視対象ファイル例

Zabbixにおけるログ監視の障害検知は、以下のステップで行われます。

▼Zabbixログ監視における監視から通知までの流れ

Zabbixでログ監視を行う際には、アイテム・トリガー・通知（アクション）の3つの設定が必要ですが、本ページでは、このうち「アイテム」と「トリガー」の設定方法と注意点を中心に解説します。

アイテムやトリガーの設定が完了し、早速ログ監視をスタート！・・・と思いきや、ログ監視テストでアイテムが取得不可になってしまったり、想定したログが検知できないケースがあります。

Zabbixのログ監視には、「ログ監視実装時に見落としがちなチェックポイント」がいくつかあります。想定したログが収集／検知できない場合は、以下のポイントを確認してみましょう。

ログ監視を行う際は、監視対象となるログファイルの権限や配置など、環境に応じた設定に注意が必要です。特にLinux環境では、ログファイルの権限設定が原因で監視が失敗するケースがあります。

Zabbixエージェントはデフォルトで Zabbix ユーザー（OSユーザー）として起動するため、エージェントの起動ユーザーがログファイルを読み取れるように、起動ユーザーまたはログファイルの権限を適切に設定する必要があります。

＜チェックポイント＞
• Zabbixエージェントが監視対象ファイルを読み込む権限はあるかどうか
• 監視対象ログファイルが存在しているかどうか
• ログファイルのローテーションはあるかどうか

ログを収集するZabbixエージェント側にも、正しく動作させるための確認ポイントがあります。特に、ホスト名の指定は見逃しやすいポイントのため注意が必要です。

Zabbixのログ監視はアクティブモードで実行されるため、エージェントが認識しているホスト名と、Zabbixサーバー上で登録されているホスト名が一致している必要があります。このホスト名の不一致が原因で、ログデータがサーバーへ送信されないケースがよく発生します。

また、エージェントの設定ファイル（zabbix_agent2.conf）では、アクティブ監視用のパラメータを正しく設定しておくことが重要です。

＜チェックポイント＞
• エージェントが問題なく起動しているかどうか
• ServerActive パラメータに Zabbix サーバーの IP アドレスを設定しているか
• ホスト名設定が正しくできているか（以下のいずれか）
a. Hostname パラメータにホスト名を指定
b. HostnameItem パラメータに "system.hostname" を指定
　※ "system.hostname" を指定すると、hostnameコマンドの結果をホスト名として使用します。

Zabbixサーバー側の監視設定も、誤りがあるとログ監視が正しく動作しないため、改めて確認が必要です。

アイテムキーは設定項目が多くミスが起こりやすい箇所ですが、なかでも監視対象ログファイルのファイル名指定は特に重要です。

アイテムキーにlogrt を利用する場合は、ログの読み飛ばしを防ぐため、ローテーションされたファイルも読み取れるように正規表現で監視対象を指定します。ただし、正規表現の範囲を広くしすぎると、意図しないファイルまで読み込む可能性があるため、できる限り厳密なパターン設定を推奨します。

設定後は必ずテストログを発行し、監視対象ログが収集／検知できることを確認してください。

＜チェックポイント＞
• エージェントが認識しているホスト名と、Zabbixサーバーに登録されているホスト名が一致しているか
• アイテムキーに、ローテーションされるログファイル名を含めて適切に指定しているか
• アイテムのタイプが「Zabbixエージェント（アクティブ）」になっているか
• アイテムキー内のローテーション方式の指定が適切か
• アイテムキーの mode パラメータに skip が指定されているか
※ デフォルト（all）でも監視は可能ですが、過去ログをすべて読み込むため、大量のデータを収集してしまう可能性があります。
• 監視対象ログの文字コードを、アイテムキーのパラメータに正しく指定しているか
• トリガーの障害イベント生成モードが「複数」になっているか

ログ監視のチェックポイントを確認し、実装やテストも問題なく完了。

しかし、いざZabbixでログ監視を運用し始めると、想定していなかった課題やトラブルに直面することがあります。ここでは、運用開始後によく発生する問題と、その解決のポイントを紹介します。

とりあえず収集できるログは全部取っているけど、ディスクのひっ迫が心配・・

ログ監視を実装する際、すべてのログを収集しようとして、アイテムキーの収集文字列やイベントID／ソースなどを絞らずに設定してしまうケースが見受けられます。設定当初は問題なく動作していても、Zabbixが大量のログを収集し続けることで、時間の経過とともにディスク容量を圧迫していきます。

その結果、最悪の場合はディスクの逼迫によってZabbixサーバーが停止し、監視業務そのものが止まるリスクがあります。

アイテムとトリガーの役割を明確化し、不要なログデータを取得せず必要な監視だけを実現！

重要なのは、「不要なログデータを取得せず、必要な監視だけを実現できるか」という視点で、アイテムやトリガーを設計することです。

データベースのひっ迫を防ぐためには、アイテム側で検知対象を適切に絞り込むことが効果的です。アイテムはログデータを収集する役割を担いますが、すべてのログを取得する必要はありません。本当に監視したい文字列を含むログだけを収集するように設定しましょう。

設定例

/var/log/messages ファイル内の「ERROR」という文字列を検知したい場合

注意パターン
　●アイテム設定： /var/log/messages のすべてのログを収集
　●トリガー設定： ログに「ERROR」が含まれる場合に障害イベントを発行
　　→ 全ログを収集するため、Zabbixサーバーのディスクを圧迫するリスクあり。

推奨パターン
　●アイテム設定： /var/log/messages に出力される「ERROR」文字列を含むログのみを収集
　●トリガー設定： 収集されたすべてのログを障害イベントとして発行
　　→ 必要なログだけを対象にでき、効率的かつ安全に監視可能。

監視条件によっては、アイテム側で収集データを明確に絞り込むことが難しい場合もあります。そのような場合は、「除外条件」を設定して不要なログを収集対象から外す方法を検討してください。

以下に、一般的な収集・検知設定のパターン例を示します。可能な限り、パターン1のようにアイテムとトリガーの両方で監視文字列を指定し、対象ログを絞り込む構成を推奨しています。

監視設定が複雑すぎて分からない！当時の担当はいなくなってしまったし・・

ログ監視では、複雑な検知条件を設定したいケースが少なくありません。Zabbixのアイテムやトリガーでは、正規表現を使って収集対象を細かく指定できます。

ただし、設定当初は設計意図や条件を把握できていても、運用を続けるなかで担当者が変わったり、設定内容が複雑になると「どの条件で監視しているのか」が分からなくなることがあります。結果として、トリガーの内容を読み解くのに時間がかかったり、変更時にオペレーションミスが発生するリスクが高まります。

▼複雑なトリガー設定が並んでいる画面

正規表現機能を活用して、監視条件設定の視認性を高める！

正規表現機能を使えば、条件設定をわかりやすく整理できるだけでなく、複数のアイテムやトリガーで同じ条件を一元管理できるため、運用時の変更や確認も容易です。

▼正規表現の設定画面

※ERROR|WARN のように | （パイプ）で区切ることで、'ERROR' または 'WARN' という文字列を含むログを検知できます。

▼トリガー条件式に正規表現を設定する場合の設定画面（Vへ正規表現を指定）

設定例

/var/log/messagesファイルに出力されたいずれかの文字列が含まれたログを障害イベントとして検知したい場合

注意パターン
　トリガー条件式：find(/zab70/logrt["/var/log/^messages(|-[0-9]{8})$",TEST,,,skip],,"regexp","AAAA|BBBB|CCCC|DDDD|EEEE|FFFF|GGGG|HHHH|IIII|JJJJ")=1

推奨パターン
　トリガー条件式：find(/zab70/logrt["/var/log/^messages(|-[0-9]{8})$",TEST,,,skip],,"regexp","@messages_regexp")=1

急いで障害対応したいのに、障害イベント画面が開かない？！

ログ監視を運用するなかで、解決済みのイベントを「復旧状態」にせず放置してしまうケースは意外と多くあります。
Zabbix 4.0以降では、障害ステータスのままになっているイベントは、イベント保存期間を過ぎても自動的には削除されず、データベース上に残り続ける仕様です。

特に、トリガー設定で「正常イベントの生成」を「なし」にしている場合、手動で「復旧済み」処理を行わない限り、イベントは障害ステータスのまま維持されます。

このような未クローズ障害を放置すると、イベントを保存しているDBテーブルが徐々に肥大化し、障害関連画面の表示が極端に遅くなる場合があります。
結果として、有事の際に障害画面が開かず、監視対応の遅延を引き起こすリスクがあります。

▼障害関連の画面の描画遅延

障害イベントは必ず復旧済みの状態にする運用に！

障害イベントを復旧済みにするためには、以下のいずれかの設定が必要となります。

設定例

注意パターン
　・トリガーにおいて「正常イベントの生成」を「なし」とし、手動クローズ設定を「無効」にする

推奨パターン
　・トリガーにおいて「正常イベントの生成」を「条件式」または「復旧条件式」とし、復旧済み状態にする
　・トリガーにおいて「正常イベントの生成」を「なし」とし、手動で復旧済み状態にできるよう手動クローズ設定を「有効」にする

特にログ監視において条件式での判定や復旧条件式での復旧が難しい場合も多々あるため、手動クローズ設定を「有効」にすることを推奨します。

該当イベントの[更新]リンクをクリックし、障害のクローズにチェックを入れて更新すると、該当のイベントが復旧済みになります。

▼障害イベントの復旧済み対応画面

本記事では、Zabbixログ監視の基本的な仕組みから、多くの人がつまずく初期設定のポイント、そして運用を始めてから直面する課題と、その解決策についてご紹介しました。

ログ監視は「設定して終わり」ではなく、システムの状況や今後の運用も踏まえて継続的に改善していくことが大切です。ログ監視の精度はシステム全体の信頼性を大きく左右するため、運用フェーズでも継続的な最適化を意識しましょう。