6 ログファイル監視

概要

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

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

ログファイルを監視するには、以下が必要です。

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

設定

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

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

• Hostnameパラメータがフロントエンドのホスト名と一致していること。
• ServerActiveパラメータにアクティブチェックを処理するサーバーが指定されていること。

アイテムの設定

ログ監視用のアイテムを設定します。

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

特にログ監視アイテムの場合は、以下を入力します。

重要な注意事項

• サーバーとエージェントは、監視対象のログのサイズと最終更新時刻（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にリセットされ、ファイルが後で現れた場合は最初から解析されます。
• ログファイルがエージェントが認識しているログサイズカウンターよりも小さくなった場合、カウンターはゼロにリセットされ、エージェントは時刻カウンターを考慮してログファイルの先頭から読み取りを開始します。
• ディレクトリ内に同じ最終更新時刻の一致するファイルが複数ある場合、エージェントは同じ更新時刻のすべてのログファイルを正しく解析し、データのスキップや重複解析を避けるようにしますが、すべての状況で保証されるわけではありません。 エージェントは特定のログファイルローテーション方式を前提とせず、またそれを判別しません。 同じ最終更新時刻の複数のログファイルがある場合、エージェントはそれらを辞書順で降順に処理します。 したがって、ローテーション方式によっては、ログファイルは元の順序で解析・報告されます。 他のローテーション方式では元のログファイルの順序が維持されず、一致したログファイルレコードが順序を変更して報告されることがあります（ログファイルの最終更新時刻が異なる場合はこの問題は発生しません）。
• Zabbixエージェントは、更新間隔秒ごとにログファイルの新しいレコードを処理します。
• Zabbixエージェントは、1秒あたりmaxlinesを超えるログファイルのレコードを送信しません。 この制限はネットワークやCPUリソースの過負荷を防ぎ、エージェント設定ファイルのMaxLinesPerSecondパラメータで指定されたデフォルト値を上書きします。
• 必要な文字列を見つけるために、ZabbixはMaxLinesPerSecondで設定された値の10倍の新しい行を処理します。 したがって、例えばlog[]またはlogrt[]アイテムの更新間隔が1秒の場合、デフォルトでエージェントは最大200件のログファイルレコードを解析し、1回のチェックで最大20件の一致するレコードをZabbixサーバーに送信します。 エージェント設定ファイルのMaxLinesPerSecondを増やすか、アイテムキーのmaxlinesパラメータを設定することで、1回のチェックで最大10000件の解析済みログファイルレコードと1000件の一致レコードをZabbixサーバーに送信するように制限を引き上げることができます。 更新間隔が2秒に設定されている場合、1回のチェックの制限は更新間隔が1秒の場合の2倍になります。
• さらに、logおよびlog.countの値は、非ログ値がバッファに存在しない場合でも、常にエージェント送信バッファサイズの50%に制限されます。 したがって、maxlinesの値を1回の接続で送信する（複数回の接続ではなく）には、エージェントのBufferSizeパラメータをmaxlines x 2以上にする必要があります。 Zabbixエージェントはログ収集中にデータをアップロードしてバッファを解放できますが、Zabbix agent 2はデータがアップロードされバッファが解放されるまでログ収集を停止します（これは非同期で実行されます）。
• ログアイテムがない場合、すべてのエージェントバッファサイズは非ログ値に使用されます。 ログ値が入ってくると、必要に応じて古い非ログ値を置き換え、指定された50%まで使用します。
• 256kBを超えるログファイルレコードの場合、最初の256kBのみが正規表現と照合され、残りのレコードは無視されます。 ただし、Zabbixエージェントが長いレコードを処理中に停止した場合、エージェントの内部状態が失われ、再起動後に長いレコードが再度、かつ異なる方法で解析される可能性があります。
• "\"パスセパレータに関する特記事項：file_formatが"file\.log"の場合、"file"ディレクトリを作成しないでください。なぜなら、"."がエスケープされているのか、ファイル名の最初の文字なのかを明確に定義できないためです。
• logrtの正規表現はファイル名のみでサポートされており、ディレクトリの正規表現マッチングはサポートされていません。
• UNIXプラットフォームでは、ログファイルが見つかるはずのディレクトリが存在しない場合、logrt[]アイテムはNOTSUPPORTEDになります。
• Microsoft Windowsでは、ディレクトリが存在しない場合でもアイテムはNOTSUPPORTEDになりません（例：アイテムキーでディレクトリ名を誤記した場合など）。
• logrt[]アイテムにログファイルが存在しない場合でもNOTSUPPORTEDにはなりません。 logrt[]アイテムのログファイル読み取りエラーは、Zabbixエージェントのログファイルに警告として記録されますが、アイテムをNOTSUPPORTEDにはしません。
• log[]またはlogrt[]アイテムがNOTSUPPORTEDになった理由を調べるには、Zabbixエージェントのログファイルが役立ちます。 Zabbixは、DebugLevel=4またはDebugLevel=5の場合を除き、エージェントのログファイル自体も監視できます。
• 正規表現を使って疑問符を検索する場合（例：\?）、テキストファイルにNUL記号が含まれていると誤検出が発生する可能性があります。これは、ZabbixがNUL記号を"?"に置き換えて、改行文字まで行の処理を継続するためです。

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

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

ログアイテムには、一致した行から目的の値を抽出する機能があります。 これは、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つの問題の解決策が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 < 更新間隔に設定することは推奨されません（頻繁に小さな「ジャンプ」が発生する可能性があります）。

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

logrtにcopytruncateオプションを指定した場合、異なるログファイルには異なるレコード（少なくともタイムスタンプが異なる）が含まれていると仮定します。そのため、初期ブロック（最初の512バイトまで）のMD5サムも異なります。 初期ブロックのMD5サムが同じ2つのファイルがある場合、一方がオリジナルで、もう一方がコピーであることを意味します。

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

log*[] itemのpersistent filesに関する注意事項

永続ファイルの目的

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エージェントは、キーによってアクティブチェックを区別します。 たとえば、logrt[/home/zabbix/test.log]とlogrt[/home/zabbix/test.log,]は異なるアイテムです。 フロントエンドでアイテムlogrt[/home/zabbix/test.log,,,10]をlogrt[/home/zabbix/test.log,,,20]に変更すると、エージェントのアクティブチェックリストからlogrt[/home/zabbix/test.log,,,10]アイテムが削除され、logrt[/home/zabbix/test.log,,,20]アイテムが作成されます（いくつかの属性はフロントエンド/サーバーでの変更時に引き継がれますが、エージェントでは引き継がれません）。

ファイル名は、アイテムキーの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 を送信します。
• maxdelay > 0 の log.count[] および logrt.count[] チェック：チェック中に「ジャンプ」がなかった場合、動作は上記と同様です。 ログファイル行の「ジャンプ」が発生した場合は、「ジャンプ」後の位置が保持され、カウントされた結果は破棄されます。 したがって、エージェントは通信障害が発生しても増加するログファイルに追従しようとします。

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

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

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

Zabbixエージェントが自身のログファイルを監視できるように、ログの記録頻度は1チェックにつき1回の実行時エラーに制限されています。 たとえば、10件のレコードを分析し、3件のレコードで正規表現の実行時エラーが発生した場合、エージェントログには1件のレコードのみが出力されます。

例外：MaxLinesPerSecond=1かつ更新間隔=1（1チェックにつき1レコードのみ分析可能）の場合、正規表現の実行時エラーは記録されません。

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