Zabbixとは？ログ監視の設定・設計・障害検知まで完全網羅

Zabbixログ監視の全体像と導入メリット

システム障害の予兆は、多くの場合「ログ」に現れます。CPUやメモリの使用率が閾値を超える前に、アプリケーションは小さなエラーログを吐き出していることが多いのです。Zabbixによるログ監視は、こうした「無言の悲鳴」を検知し、深刻なサービス停止を防ぐための最後の砦となります。

特に中小企業の情報システム部門では、専任の監視オペレーターを配置することが難しく、異常検知の自動化が急務です。本記事では、Zabbixを用いたログ監視の設計から設定、そして現場で役立つトラブルシューティングまで、実務経験に基づいたノウハウを体系的に解説します。

リソース監視（CPU、メモリ、ディスク監視）とログ監視は、車の「両輪」の関係にあります。リソース監視はシステムの「健康状態」を数値で把握しますが、ログ監視はシステムの「挙動そのもの」をテキストベースで把握します。

例えば、Webサーバーが攻撃を受けた際、CPU負荷が上がる前にアクセスログには不審なリクエストが記録されます。また、バッチ処理がデータ整合性エラーで停止した場合、リソースには変化がないまま、業務だけが止まっているという事態も起こり得ます。

ログファイルには、システムやアプリケーションの動作状況、エラー、警告などが記録されます。Zabbixでログ監視を行うことで、障害の予兆検知や原因特定を迅速に行うことができます。

出典: アシスト「【決定版】Zabbixログ監視を徹底解説！」

私の経験でも、データベースのデッドロック検知などはリソース監視では不可能で、アプリケーションログの「Deadlock found」という文字列監視だけが頼りでした。ログ監視を導入することで、障害対応の初動を劇的に早めることが可能になります。

Zabbixのログ監視を理解する上で最も重要なのが、「アクティブチェック（Active Check）」という仕組みです。

通常の監視（パッシブチェック）では、Zabbixサーバーからエージェントに対して「CPU使用率は？」と問い合わせます。しかし、ログ監視では逆の動きをします。Zabbixエージェントが自発的にログファイルを読みに行き、新しい行が追加されていたら、そのデータをZabbixサーバーに送信します。

この仕組みが必要な理由は、ログが発生するタイミングが予測不能だからです。サーバー側から定期的に問い合わせる方式では、突発的な大量ログを取りこぼしたり、監視間隔のタイムラグが発生したりするリスクがあります。したがって、ログ監視を設定する際は、エージェントの設定ファイル（zabbix_agentd.conf）で ServerActive の設定が必須となります。

Zabbixでログ監視を行う際、アイテムキーとして log[] と logrt[] の2種類が存在します。実運用では、9割以上のケースで logrt[] を選択すべきです。

• log[ファイルパス]: 指定された固定のファイル名のみを監視します。ファイル名が変わると追跡できません。
• logrt[ファイルパスの正規表現]: ログローテーションに対応しています。

Linuxサーバーでは通常、ログは app.log → app.log.1 → app.log.2 のようにローテーション（世代管理）されます。log[] キーで監視していると、ファイル名が変わった瞬間に監視が途切れたり、ローテーションされた過去のログを重複して読み込んだりするトラブルが発生します。

logrt は「Log RoTation」の略であり、正規表現を使ってファイル名のパターンを指定することで、ログファイルが切り替わっても正しく最新のログを追尾し続けることができます。

【実践】Zabbixログ監視の設定手順ステップバイステップ

ここからは、実際にZabbixでログ監視を構築するための手順を解説します。設定は細かいパラメーターのミスで動かなくなることが多いため、一つずつ確実に進めてください。

設定作業の中で最もトラブルが多いのが「権限（Permission）」の問題です。Zabbixエージェントは、Linux上では通常 zabbix というユーザーで動作しています。監視対象のログファイル（例：/var/log/messages や /var/log/nginx/error.log）に、zabbix ユーザーの読み取り権限がないと、データは絶対に取得できません。

権限を付与する方法として、安易に chmod 777 を実行するのはセキュリティ上NGです。推奨されるのは、ACL（Access Control List）を使用した権限付与です。

Zabbix管理画面（フロントエンド）でアイテムを作成します。

1. ホストの選択: 設定 > ホスト から対象ホストを選択し、「アイテム」タブへ移動、「アイテムの作成」をクリック。
2. 名前: わかりやすい名前を入力（例：App Error Log監視）。
3. タイプ: 必ず 「Zabbixエージェント（アクティブ）」 を選択してください。これ以外では動作しません。
4. キー: logrt[/var/log/app/.*error.log,,,skip] のように入力します。

• 第4引数の skip は重要です。これを指定すると、設定直後は既存の過去ログを無視し、これから書き込まれる新しいログのみを監視対象とします。大量の過去ログが一気に通知される事故を防ぐため、初期設定では必須です。

5. データ型: 「ログ」を選択。
6. 監視間隔: 「1s（1秒）」を推奨します。アクティブチェックにおいてはこの値は「エージェントがログを確認しに行く頻度」です。リアルタイム性を高めるため、短めに設定します。

ログを収集できたら、次は「どのような文字列が出たら障害とするか」を定義します。

• find関数: 文字列検索を行います。
• regexp: 正規表現でマッチングします。「ERROR」または「CRITICAL」が含まれる行を検知します。
• =1: 条件にマッチした場合に障害（True）と判定します。

特定の文字列を除外したい場合（例：「Ignore ERROR」という文字列は無視する）は、トリガー条件式を複雑にするよりも、正規表現の工夫や保存前処理（後述）で行う方が管理しやすくなります。

ログ監視のトリガー設定において、「手動クローズを許可（Allow manual close）」 のチェックは必須と言っても過言ではありません。

CPU使用率のような数値監視であれば、数値が下がれば自動的に障害は復旧（解決済）になります。しかし、ログ監視の場合、「エラーログが出た」という事実は時間が経過しても消えません。そのため、一度障害として検知されると、誰かが対応して意図的にステータスを戻さない限り、永遠に「障害中」のまま残ってしまいます。

障害をクローズするためのチェックボックスは、選択した障害の少なくとも1つについて、トリガー設定で手動クローズを許可するオプションがチェックされている場合に利用可能です。
出典: Zabbix Documentation 6.0「13. 障害イベントの確認」

運用フローとしては、「検知」→「担当者がログ確認」→「対応完了」→「Zabbix上で手動クローズ」というサイクルを徹底することで、監視ダッシュボードを常にクリーンな状態に保つことができます。

現場で失敗しないための「ログ監視設計」ベストプラクティス

基本的な設定ができても、実運用では「通知が多すぎてオオカミ少年になる」「サーバー負荷が上がる」といった問題に直面します。ここではプロが実践する設計のコツを紹介します。

複数のホストで同じようなエラー定義（例：System Error, Fatal Error, Panic など）を使う場合、アイテムやトリガーごとに正規表現を書いていくのは非効率で、修正漏れの原因になります。

Zabbixの「管理 > 一般設定 > 正規表現（グローバル正規表現）」機能を活用しましょう。ここで「共通エラーパターン」という名前で正規表現リストを登録しておけば、トリガー設定では @共通エラーパターン と参照するだけで済みます。キーワードの追加・変更が必要になった際も、一箇所修正するだけで全ホストに適用されるため、メンテナンス性が劇的に向上します。

アプリケーションが暴走して、秒間数万行ものエラーログを吐き出すケースを想像してください。Zabbixエージェントがその全てを処理しようとすると、CPUリソースを食いつぶし、最悪の場合業務サーバー自体を停止させてしまうリスクがあります。

これを防ぐのが maxlines パラメーターです。アイテムキーの第3引数で設定します（デフォルトは100行）。
logrt[/path/to/file,,,,100]
これは、1回のチェックでZabbixサーバーに送信する最大行数を制限するものです。

さらに、エージェント設定ファイル（zabbix_agentd.conf）の MaxLinesPerSecond も重要です。これはエージェント全体での秒間処理行数の上限を定めます。デフォルトは20行ですが、ログ流量が多いシステムでは100〜500程度にチューニングすることが一般的です。

logrt を使用していても、ログローテーションの仕組みを正しく理解していないと監視漏れが起きます。Zabbixはファイル名だけでなく、ファイルの「i-node」や「署名（先頭の数バイト）」を見てファイルの同一性を判断しています。

Linux標準の logrotate であれば問題ありませんが、アプリケーション独自の実装で「ファイルを別ディレクトリに移動（mv）してから圧縮」といった特殊な挙動をする場合、Zabbixが見失うことがあります。特に「copytruncate」方式（内容をコピーしてから元のファイルを空にする）のローテーションは、ログの取りこぼしが発生しやすいタイミングがあるため注意が必要です。

Zabbix 4.0以降で強化された「保存前処理」は、ログ監視でも非常に強力です。
例えば、Javaのスタックトレースなどは数十行にわたる巨大なログになりますが、監視に必要なのは「最初の1行目」のエラーメッセージだけという場合があります。

保存前処理で「正規表現」を使い、必要な行だけを抽出（フィルタリング）したり、不要なデバッグログを「破棄」したりすることで、データベースの容量を節約し、Zabbixサーバーの負荷を下げることができます。

保存前処理で「サポートしていない値のチェック」が複数追加可能になり、正規表現で処理を振り分けられるようになりました。
出典: SRA OSS「Zabbix 7.0 の紹介」

よくあるトラブルと解決策（Troubleshooting）

設定したはずなのに動かない。そんな時に確認すべきポイントをまとめました。

最も多いのがこのパターンです。エラーメッセージを確認してください。
Permission denied と出ている場合は、Step1で解説した権限不足です。

もし Cannot allow active checks と出ている場合は、エージェント側の設定ミスです。zabbix_agentd.conf の以下の項目を確認してください。

• ServerActive: ZabbixサーバーのIPアドレスが正しいか。
• Hostname: ここに記述したホスト名と、Web管理画面で登録したホスト名が一言一句（大文字小文字含む）一致しているか。これが不一致だとアクティブチェックは拒否されます。

権限も設定も合っているのにログが来ない場合、以下を疑います。

1. タイムスタンプの解釈: Zabbixがログ内の日時を誤読している可能性があります。アイテム設定の「ログの時間の形式」を空欄にするとシステム日時を使用しますが、フォーマットを指定している場合は記述ミスがないか確認してください。
2. ファイル形式: バイナリファイルや、特殊な文字コード（UTF-16など）のログは標準では読めないことがあります。
3. 古いログ: アイテム作成時に skip をつけていない場合、Zabbixはファイルの先頭から読み込もうとしますが、ファイルが巨大すぎると処理が追いつかず、最新のログに到達するまで時間がかかっている可能性があります。

「エラー発生」の通知が1分ごとに届き、メールボックスが埋め尽くされるのは避けたい事態です。
これを防ぐにはトリガー設定で「障害イベント生成モード」を調整します。

• 単一（Single）: 一度障害状態になったら、正常に戻るまで次の通知を出しません。ログ監視では通常これを選びます。
• 複数（Multiple）: マッチする行が出るたびに通知します。重要なセキュリティログなど、1件たりとも見逃してはいけない場合のみ使用します。

Zabbix 6.0/7.0 LTS以降の新機能と注意点

Zabbixは進化を続けており、最新のLTS（Long Term Support）バージョンではログ監視のパフォーマンスも向上しています。

Go言語で再構築された「Zabbix Agent 2」は、従来のC言語版エージェントと比較して並行処理能力が大幅に向上しています。

• 同時実行数: 従来のエージェントはアクティブチェックをシングルスレッドで処理していましたが、Agent 2はゴルーチンを用いた並行処理が可能です。
• バッファ制限の緩和: デフォルトのバッファサイズや MaxLinesPerSecond の扱いがより柔軟になり、大規模なログ監視に適しています。

Zabbix Agentでは100、Zabbix Agent 2では1000がデフォルト値となります。（中略）今回は監視間隔が30秒なので、1度の監視処理での読込上限は6000行、送信上限は600行になります。
出典: サイバートラスト「Zabbix Agent / Zabbix Agent 2 でのテキストログ監視でよくある質問」

これから新規構築する場合は、Zabbix Agent 2の採用を積極的に検討すべきです。

最新版でも変わらない制限事項として、「ログ監視アイテムはZabbixサーバー側で値を持たない期間が長くなる」という点があります。ログが出力されない限りデータが送られてこないため、Zabbixのグラフ上ではデータが途切れて表示されます。
これを「取得不可」と勘違いしないように注意が必要です。nodata() 関数などを使って「ログが長時間来ていないこと」を監視する場合は、この特性を考慮した閾値設定が求められます。

まとめ：安定したシステム運用のためのログ監視設計

Zabbixによるログ監視は、初期設定こそ権限周りや正規表現でつまづきやすいポイントがありますが、一度適切に構築すればシステム運用の強力な武器となります。

• logrt を使い、ローテーションに対応させる。
• 権限設定（ACL） を正しく行い、エージェントがファイルを読めるようにする。
• 手動クローズ を活用し、障害対応のワークフローを確立する。
• Zabbix Agent 2 などの新機能を活用し、パフォーマンスを最適化する。

この記事の手順を参考に、ぜひ「眠れる夜」を取り戻すための堅牢な監視システムを構築してください。もし自社内での設定に不安がある、あるいはより高度な監視設計が必要な場合は、専門家による導入支援を検討することをお勧めします。