3 ログファイルの監視

概要

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 データベースに保存され、エージェントが起動直後である場合や、以前は無効化されていた、または未対応だったアイテムを受信した場合に、エージェントがこの位置からログファイルの読み取りを開始するよう送信されます。 ただし、エージェントがサーバーから 0 以外のサイズカウンターを受信していても、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 回のチェックで最大 20 件の一致レコードを Zabbix サーバーに送信します。 エージェント設定ファイルで 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' ログファイルローテーションの取り扱いに関する注意事項

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

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

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

永続ファイルの目的

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

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

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

主な用途は、ミラー化されたファイルシステム上にあるログファイルの監視です。
ある時点までは、ログファイルは両方のミラーに書き込まれます。
その後、ミラーが分割されます。
アクティブ側のコピーでは、ログファイルは引き続き増加し、新しいレコードが追加されます。
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[] アイテムのチェックは停止します。
  通信が回復し、バッファーに空きスロットがある場合、チェックは前回の位置から再開されます。
  一致した行は失われず、後で報告されます。
• maxdelay = 0（デフォルト）の場合、log.count[] および logrt.count[] のチェックは停止します。
  動作は上記の log[] および logrt[] アイテムと同様です。
  なお、これは log.count[] および logrt.count[] の結果に影響する場合があります。たとえば、あるチェックでログファイル内の一致行を 100 行数えたものの、バッファーに空きスロットがないためチェックが停止したとします。
  通信が回復すると、エージェントは同じ 100 行の一致行を数え、さらに新しい 70 行の一致行も数えます。
  エージェントは、あたかも 1 回のチェックで見つかったかのように count = 170 を送信します。
• maxdelay > 0 の log.count[] および logrt.count[] のチェックでは、チェック中に "jump" が発生しなかった場合、動作は上記と同様です。
  ただし、ログファイル行をまたぐ "jump" が発生した場合は、"jump" 後の位置が保持され、カウント結果は破棄されます。
  そのため、通信障害が発生した場合でも、エージェントは増加するログファイルに追従しようとします。

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

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

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

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

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

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