ログファイル監視

概要

Zabbix は、ログローテーション対応の有無にかかわらず、ログファイルの集中監視と分析に使用できます。

通知を使用すると、ログファイルに特定の文字列または文字列パターンが含まれている場合にユーザーへ警告できます。

ログファイルを監視するには、次のものが必要です。

• ホスト上で Zabbix エージェントが稼働していること。
• ログ監視アイテムが設定されていること。

設定

エージェントパラメータの確認

エージェント設定ファイルで、次を確認してください。

• Hostname パラメータが Webインターフェース上のホスト名と一致していること。
• ServerActive パラメータのサーバーが、アクティブチェックの処理対象として指定されていること。

アイテム設定

ログ監視用のitemを設定します。

必須入力フィールドには赤いアスタリスクが付いています。

ログ監視アイテムでは、次の項目を入力します。

重要な注意事項

• サーバーとエージェントは、監視対象ログのサイズと最終更新時刻（logrt の場合）を 2 つのカウンターで保持します。 さらに:
  • エージェントは、ログファイルが切り詰められたりローテーションされたりした際の判定を改善するために、内部的に inode 番号（UNIX/GNU/Linux）、ファイルインデックス（Microsoft Windows）、およびログファイル先頭 512 バイトの MD5 合計値も使用します。
  • UNIX/GNU/Linux システムでは、ログファイルが保存されているファイルシステムが inode 番号を報告し、それを使ってファイルを追跡できるものと想定されています。
  • Microsoft Windows では、Zabbix エージェントがログファイルの存在するファイルシステム種別を判定し、次を使用します:
    • NTFS ファイルシステムでは 64 ビットのファイルインデックス。
    • ReFS ファイルシステムでは（Microsoft Windows Server 2012 以降のみ）128 ビットのファイル ID。
    • ファイルインデックスが変化するファイルシステム（例: FAT32、exFAT）では、ログファイルのローテーションにより最終更新時刻が同じ複数のログファイルが生成された場合に、不確実な条件下でも妥当な判断を行うためのフォールバックアルゴリズムを使用します。
  • inode 番号、ファイルインデックス、および MD5 合計値は、Zabbix エージェントによって内部的に収集されます。 これらは Zabbix サーバーには送信されず、Zabbix エージェントの停止時に失われます。
  • ログファイルの最終更新時刻を変更しないでください（たとえば touch を使用しないでください）。また、監視対象のログファイルをコピーして元の名前で置き換えないでください（これにより新しい inode が作成されます）。 いずれの場合も、Zabbix はそのファイルを別のファイルとして扱い、先頭から再読み込みすることがあり、その結果、重複した障害通知が発生する可能性があります。
  • logrt[] アイテムに一致するログファイルが複数あり、Zabbix エージェントがそのうち最新のものを追跡していて、その最新のログファイルが削除された場合、警告メッセージ "there are no files matching "<regexp mask>" in "<directory>" が記録されます。 Zabbix エージェントは、チェック対象の logrt[] アイテムについて、エージェントがこれまでに見た最も新しい最終更新時刻よりも古い更新時刻のログファイルを無視します。
• エージェントは、前回停止した位置からログファイルの読み取りを開始します。
• すでに解析済みのバイト数（サイズカウンター）と最終更新時刻（時間カウンター）は Zabbix データベースに保存され、エージェントが起動直後である場合や、以前は無効化されていた、または未サポートだったアイテムを受信した場合に、エージェントがこの位置からログファイルの読み取りを開始できるように送信されます。 ただし、エージェントがサーバーからゼロ以外のサイズカウンターを受信していても、logrt[] または logrt.count[] アイテムが一致するファイルを見つけられない場合、後でファイルが現れたときに先頭から解析できるよう、サイズカウンターは 0 にリセットされます。
• ログファイルがエージェントに認識されているログサイズカウンターより小さくなった場合、カウンターは 0 にリセットされ、エージェントは時間カウンターを考慮しながらログファイルの先頭から読み取りを開始します。
• ディレクトリ内に最終更新時刻が同じ一致ファイルが複数ある場合、エージェントは同じ更新時刻を持つすべてのログファイルを正しく解析し、データの取りこぼしや同じデータの二重解析を避けようとしますが、すべての状況で保証されるわけではありません。 エージェントは特定のログファイルローテーション方式を前提とせず、またそれを判定もしません。 同じ最終更新時刻を持つ複数のログファイルがある場合、エージェントは辞書順の降順で処理します。 そのため、ローテーション方式によってはログファイルが元の順序で解析・報告されます。 別のローテーション方式では元のログファイル順が維持されず、結果として一致したログファイルのレコードが変更された順序で報告されることがあります（ログファイルの最終更新時刻が異なれば、この問題は発生しません）。
• Zabbix エージェントは、ログファイルの新しいレコードを Update interval 秒ごとに 1 回処理します。
• Zabbix エージェントは、1 秒あたり maxlines を超えるログファイルを送信しません。 この制限はネットワークおよび CPU リソースの過負荷を防ぎ、agent configuration file の MaxLinesPerSecond パラメータで指定されるデフォルト値を上書きします。
• 必要な文字列を見つけるために、Zabbix は MaxLinesPerSecond で設定された値の 10 倍の新しい行を処理します。 したがって、たとえば log[] または logrt[] アイテムの Update interval が 1 秒の場合、デフォルトではエージェントは 200 件を超えるログファイルレコードを解析せず、1 回のチェックで Zabbix サーバーに送信する一致レコードは 20 件を超えません。 エージェント設定ファイルで MaxLinesPerSecond を増やすか、アイテムキーで maxlines パラメータを設定すると、1 回のチェックで解析されるログファイルレコードは最大 10000 件、Zabbix サーバーに送信される一致レコードは最大 1000 件まで増やせます。 Update interval を 2 秒に設定すると、1 回のチェックに対する制限は Update interval が 1 秒の場合の 2 倍になります。
• さらに、log および log.count の値は、非ログ値が含まれていなくても、常にエージェント送信バッファサイズの 50% に制限されます。 そのため、maxlines の値を 1 回の接続で送信するには（複数回の接続に分かれないようにするには）、エージェントの BufferSize パラメータは少なくとも maxlines x 2 である必要があります。 Zabbix エージェントはログ収集中にデータをアップロードしてバッファを解放できますが、Zabbix エージェント 2 はデータがアップロードされてバッファが解放されるまでログ収集を停止します。これは非同期で実行されます。
• ログアイテムが存在しない場合、エージェントバッファサイズ全体が非ログ値に使用されます。 ログ値が入ってくると、必要に応じて古い非ログ値が置き換えられ、指定された 50% まで使用されます。
• 256kB を超えるログファイルレコードでは、正規表現との照合は先頭 256kB のみが対象となり、残りのレコードは無視されます。 ただし、Zabbix エージェントが長いレコードを処理している最中に停止すると、エージェント内部状態は失われ、再起動後にその長いレコードが再度、かつ異なる方法で解析される可能性があります。
• \ のパス区切り文字に関する特記事項: file_format が file\.log の場合、. がエスケープされているのか、ファイル名の先頭文字なのかを曖昧なく定義できないため、file ディレクトリは存在してはなりません。
• logrt の正規表現はファイル名に対してのみサポートされ、ディレクトリの正規表現マッチングはサポートされません。
• UNIX プラットフォームでは、ログファイルが存在すると想定されるディレクトリが存在しない場合、logrt[] アイテムは NOTSUPPORTED になります。
• Microsoft Windows では、ディレクトリが存在しない場合でもアイテムは NOTSUPPORTED になりません（たとえば、アイテムキー内のディレクトリ名が誤っている場合）。
• logrt[] アイテムに対してログファイルが存在しないことは、NOTSUPPORTED にはなりません。 logrt[] アイテムのログファイル読み取りエラーは Zabbix エージェントのログファイルに警告として記録されますが、アイテムを NOTSUPPORTED にはしません。
• Zabbix エージェントのログファイルは、log[] または logrt[] アイテムが NOTSUPPORTED になった理由を調べるのに役立ちます。 Zabbix は、DebugLevel=4 または DebugLevel=5 の場合を除き、エージェントのログファイルを監視できます。
• 正規表現で疑問符を検索する場合、たとえば \? は、テキストファイルに NUL 文字が含まれていると誤検出を引き起こす可能性があります。これは、Zabbix が改行文字まで行の処理を続けるために、それらを ? に置き換えるためです。

正規表現の一致部分の抽出

正規表現の一致が見つかった場合に、行全体を返すのではなく、対象ファイルから必要な値だけを抽出したいことがあります。

ログアイテムには、一致した行から必要な値を抽出する機能があります。
これは、log および logrt アイテムに追加される output パラメータによって実現されます。

output パラメータを使用すると、関心のある一致部分の「キャプチャグループ」を指定できます。

たとえば、次のようにします。

log[/path/to/the/file,"large result buffer allocation.*Entries: ([0-9]+)",,,,\1]

これにより、次の内容からエントリ数を返せるようになります。

Fr Feb 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) large result
buffer allocation - /Length: 437136/Entries: 5948/Client Ver: >=10/RPC
ID: 41726453/User: AUser/Form: CFG:ServiceLevelAgreement

返されるのは数値のみです。\\1 は最初で唯一のキャプチャグループ ([0-9]+) を参照するためです。

また、数値を抽出して返せるようになることで、その値をトリガーの定義に使用できます。

maxdelay パラメータの使用

ログアイテムの maxdelay パラメータを使用すると、ログファイル内の一部の古い行を無視して、maxdelay 秒以内に解析される最新の行を取得できます。

デフォルトでは、ログ監視用のアイテムはログファイルに現れるすべての新しい行を追跡します。 ただし、状況によっては、ログファイルに大量のメッセージを書き込み始めるアプリケーションがあります。 たとえば、データベースや DNS サーバーが利用できない場合、そのようなアプリケーションは通常の動作が復旧するまで、ほぼ同一のエラーメッセージを何千件もログファイルに出力します。 デフォルトでは、これらのメッセージはすべて忠実に解析され、log および logrt アイテムで設定されたとおりに一致した行がサーバーへ送信されます。

過負荷に対する組み込みの保護として、設定可能な maxlines パラメータ（サーバーを大量の一致ログ行の受信から保護します）と、10*maxlines の上限（1回のチェックでエージェントがホストの CPU と I/O を過負荷にしないよう保護します）があります。 それでも、組み込み保護には 2 つの問題があります。 1 つ目は、情報量の少ない可能性のあるメッセージが大量にサーバーへ報告され、データベースの容量を消費することです。 2 つ目は、1 秒あたりに解析できる行数が限られているため、エージェントが最新のログ記録から数時間遅れる可能性があることです。 おそらく、古い記録を何時間も追いかけるよりも、ログファイルの現在の状況をより早く把握したいはずです。

この 2 つの問題を解決するには、maxdelay パラメータを使用します。 maxdelay > 0 を指定すると、各チェックで処理済みバイト数、残りバイト数、および処理時間が測定されます。 これらの数値から、エージェントは推定遅延、つまりログファイル内の残りのすべての記録を解析するのに何秒かかるかを計算します。

遅延が maxdelay を超えない場合、エージェントは通常どおりログファイルの解析を続けます。

遅延が maxdelay より大きい場合、エージェントはログファイルの一部を「飛ばして」無視し、残りの行を maxdelay 秒以内に解析できるように、新しい推定位置へ移動します。

なお、エージェントは無視した行をバッファーに読み込むことすらせず、ファイル内で移動するおおよその位置を計算します。

ログファイルの行をスキップした事実は、エージェントのログファイルに次のように記録されます。

14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
logfile:"/home/zabbix32/test1.log" skipping 679858 bytes
(from byte 75653115 to byte 76332973) to meet maxdelay

to byte の数値は概算です。なぜなら、「ジャンプ」後にエージェントはファイル内の位置をログ行の先頭に調整しますが、その位置はファイル内でさらに後ろ、または前になる可能性があるためです。

ログの増加速度と解析速度の比較によっては、「ジャンプ」がまったく発生しない場合もあれば、まれに発生する場合、頻繁に発生する場合、大きい「ジャンプ」や小さい「ジャンプ」が起こる場合、あるいは各チェックで小さな「ジャンプ」が発生する場合もあります。 システム負荷やネットワーク遅延の変動も遅延の計算に影響し、その結果、maxdelay パラメータに追従するために先へ「ジャンプ」する動作にも影響します。

maxdelay < update interval の設定は推奨されません（頻繁に小さな「ジャンプ」が発生する可能性があります）。

'copytruncate' ログファイルローテーションの取り扱いに関する注意事項

logrt の copytruncate オプションは、異なるログファイルには異なるレコードが含まれている（少なくともタイムスタンプが異なる）ことを前提としているため、先頭ブロック（最初の 512 バイトまで）の MD5 合計値は異なります。 先頭ブロックの MD5 合計値が同じ 2 つのファイルがある場合、そのうちの 1 つが元のファイルで、もう 1 つはコピーです。

copytruncate オプション付きの logrt は、重複を報告せずにログファイルのコピーを正しく処理するよう努めます。 ただし、同じタイムスタンプを持つ複数のログファイルコピーを作成すること、logrt[] アイテムの更新間隔よりも頻繁にログファイルをローテーションすること、エージェントを頻繁に再起動することは推奨されません。 エージェントはこれらの状況すべてに対して妥当に対処しようとしますが、すべての状況で良好な結果が保証されるわけではありません。

ログ*[] アイテムの永続ファイルに関する注意事項

永続ファイルの目的

Zabbix エージェントが起動すると、Zabbix サーバーまたはプロキシからアクティブチェックの一覧を受け取ります。
log*[] メトリクスについては、ログ監視をどこから開始するかを判断するために、処理済みのログサイズと更新時刻を受け取ります。
ファイルシステムから報告される実際のログファイルサイズと更新時刻に応じて、エージェントは処理済みのログサイズからログ監視を継続するか、ログファイルを先頭から再解析するかを判断します。

稼働中のエージェントは、チェック間で監視対象のすべてのログファイルを追跡するために、より多くの属性を保持します。
このメモリ上の状態は、エージェントが停止すると失われます。

新しいオプションパラメーター persistent_dir は、この log[]、log.count[]、logrt[] または logrt.count[] アイテムの状態をファイルに保存するためのディレクトリを指定します。
Zabbix エージェントの再起動後、ログアイテムの状態は永続ファイルから復元されます。

主な用途は、ミラーリングされたファイルシステム上にあるログファイルの監視です。
ある時点までは、ログファイルは両方のミラーに書き込まれます。
その後、ミラーは分離されます。
アクティブ側のコピーではログファイルは引き続き増加し、新しいレコードが追加されます。
Zabbix エージェントはそれを解析し、処理済みのログサイズと更新時刻をサーバーに送信します。
パッシブ側のコピーではログファイルは変化せず、アクティブ側のコピーよりかなり遅れた状態のままです。
その後、オペレーティングシステムと Zabbix エージェントはパッシブ側のコピーから再起動されます。
Zabbix エージェントがサーバーから受け取る処理済みのログサイズと更新時刻は、パッシブ側のコピーの状況には適していない場合があります。
ファイルシステムのミラー分離時点でエージェントが中断した場所からログファイル監視を継続するために、エージェントは永続ファイルから状態を復元します。

永続ファイルを使用したエージェントの動作

起動時、Zabbix エージェントは永続ファイルについて何も知りません。
Zabbix サーバー（プロキシ）からアクティブチェックの一覧を受信して初めて、いくつかのログアイテムが指定されたディレクトリ内の永続ファイルによって保持されるべきであることを認識します。

エージェントの動作中、永続ファイルは書き込み用に開かれ（fopen(filename, "w") を使用）、最新データで上書きされます。
上書きとファイルシステムのミラー分割が同時に発生した場合に永続ファイルのデータを失う可能性は非常に低く、特別な対処は不要です。
永続ファイルへの書き込み後に、ストレージ媒体への強制的な同期（fsync() の呼び出し）は行われません。

最新データへの上書きは、Zabbix サーバーへの一致するログファイルレコード、またはメタデータ（処理済みログサイズおよび更新時刻）の報告が成功した後に行われます。
ログファイルが変化し続ける場合、これは各アイテムチェックごとに発生することがあります。

エージェントのシャットダウン時に特別な処理はありません。

アクティブチェックの一覧を受信すると、エージェントは削除対象の古い永続ファイルに印を付けます。
永続ファイルは、次の場合に古くなります。

1. 対応するログアイテムが監視されなくなった場合。
2. ログアイテムが再設定され、persistent_dir の場所が以前と異なる場合。

削除は24時間の遅延後に行われます。これは、NOTSUPPORTED 状態のログファイルはアクティブチェックの一覧に含まれないものの、後で SUPPORTED になる可能性があり、その場合は永続ファイルが役立つためです。

24時間が経過する前にエージェントが停止した場合、Zabbix エージェントは Zabbix サーバーからその場所に関する情報を受け取れなくなるため、古いファイルは削除されません。

永続ファイルの名前付けと配置

Zabbix エージェントは、アクティブチェックをそのキーによって区別します。
たとえば、logrt[/home/zabbix/test.log] と logrt[/home/zabbix/test.log,] は異なるアイテムです。
Webインターフェースでアイテム logrt[/home/zabbix/test.log,,,10] を logrt[/home/zabbix/test.log,,,20] に変更すると、エージェントのアクティブチェック一覧から logrt[/home/zabbix/test.log,,,10] アイテムが削除され、logrt[/home/zabbix/test.log,,,20] アイテムが作成されます (一部の属性は Webインターフェース/サーバー側で変更時に引き継がれますが、エージェント側では引き継がれません)。

ファイル名は、衝突の可能性を減らすために、アイテムキーの MD5 合計値にアイテムキーの長さを付加して構成されます。
たとえば、logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] アイテムの状態は、永続ファイル c963ade4008054813bbc0a650bb8e09266 に保持されます。

複数のログアイテムで同じ persistent_dir を使用できます。

persistent_dir は、特定のファイルシステム構成、マウントポイントとマウントオプション、およびストレージミラーリング構成を考慮して指定します。永続ファイルは、監視対象のログファイルと同じミラーリングされたファイルシステム上に配置する必要があります。

persistent_dir ディレクトリを作成できない、存在しない、または Zabbix エージェントのアクセス権限によりファイルの作成/書き込み/読み取り/削除ができない場合、ログアイテムは NOTSUPPORTED になります。

エージェントの動作中に永続ストレージファイルへのアクセス権が削除された場合、または他のエラー（例: ディスク容量不足）が発生した場合、エラーはエージェントのログファイルに記録されますが、ログアイテムは NOTSUPPORTED にはなりません。

I/O の負荷

アイテムの永続ファイルは、アイテムのデータを含む各データバッチをサーバーへ正常に送信した後に更新されます。
たとえば、デフォルトの BufferSize は 100 です。
ログアイテムで 70 件の一致レコードが見つかった場合、最初の 50 件のレコードは 1 つ目のバッチで送信され、永続ファイルが更新されます。その後、残りの 20 件のレコードは 2 つ目のバッチで送信され（より多くのデータが蓄積されるまで少し遅延する場合があります）、永続ファイルが再度更新されます。

エージェントとサーバー間の通信が失敗した場合の動作

log[] および logrt[] アイテムの各一致行と、各 log.count[] および logrt.count[] アイテムのチェック結果には、エージェント送信バッファ内の指定された 50% 領域に空きスロットが必要です。
バッファ内の要素は定期的にサーバー（またはプロキシ）へ送信され、その後バッファスロットは再び空きになります。

エージェント送信バッファの指定されたログ領域に空きスロットがある間にエージェントとサーバー（またはプロキシ）間の通信が失敗すると、ログ監視結果は送信バッファに蓄積されます。
これにより、短時間の通信障害を緩和できます。

通信障害が長引くと、すべてのログスロットが使用中になり、次の動作が行われます。

• log[] および logrt[] アイテムのチェックは停止されます。
  通信が回復し、バッファに空きスロットがある場合、チェックは前回の位置から再開されます。
  一致した行は失われず、後で報告されます。
• log.count[] および logrt.count[] のチェックは、maxdelay = 0（デフォルト）の場合に停止されます。
  動作は上記の log[] および logrt[] アイテムと同様です。
  これは log.count[] および logrt.count[] の結果に影響する可能性があることに注意してください。たとえば、あるチェックでログファイル内の一致行を 100 行数えたものの、バッファに空きスロットがないためチェックが停止されたとします。
  通信が回復すると、エージェントは同じ 100 行の一致行を数え、さらに 70 行の新しい一致行も数えます。
  エージェントは、あたかも 1 回のチェックで見つかったかのように count = 170 を送信します。
• log.count[] および logrt.count[] の maxdelay > 0 のチェックでは、チェック中に "jump" が発生しなかった場合、動作は上記と同様です。
  ただし、ログファイル行をまたぐ "jump" が発生した場合は、"jump" 後の位置が保持され、数えられた結果は破棄されます。
  つまり、通信障害が発生した場合でも、エージェントは増加するログファイルに追従しようとします。

正規表現のコンパイルエラーと実行時エラーの処理

log[]、logrt[]、log.count[]、または logrt.count[] アイテムで使用される正規表現を PCRE または PCRE2 ライブラリでコンパイルできない場合、そのアイテムはエラーメッセージとともに NOTSUPPORTED 状態になります。
ログアイテムの監視を継続するには、正規表現を修正する必要があります。

正規表現のコンパイルは成功しても、実行時に失敗する場合（いくつかのログレコード、またはすべてのログレコードで失敗する場合）は、ログアイテムは引き続きサポートされ、監視は継続されます。
実行時エラーは Zabbix エージェントのログファイルに記録されます（ログファイルのレコード自体は記録されません）。

Zabbix エージェントが自身のログファイルを監視できるように、ログ出力の頻度はチェックごとに 1 回の実行時エラーに制限されています。
たとえば、10 件のレコードが解析され、そのうち 3 件が regexp の実行時エラーで失敗した場合、エージェントのログには 1 件のレコードだけが出力されます。

例外: MaxLinesPerSecond=1 かつ update interval=1 の場合（チェックごとに解析できるレコードは 1 件のみ）には、regexp の実行時エラーはログに記録されません。

zabbix_agentd は実行時エラーが発生した場合にアイテムキーをログに記録し、zabbix_agent2 はどのログアイテムで実行時エラーが発生したかを特定しやすいようにアイテム ID をログに記録します。
実行時エラーが発生した場合は、正規表現を再設計することを推奨します。