[comment]: # translation:outdated [comment]: # ({aed6dc97-aed6dc97}) # 6 ログファイル監視 [comment]: # ({/aed6dc97-aed6dc97}) [comment]: # ({20b129cf-8d33723f}) #### 概要 Zabbixは、ログローテーションの有無にかかわらず、ログファイルの集中監視および分析に使用できます。通知機能を利用して、ログファイルに特定の文字列やパターンが含まれている場合にユーザーに警告することができます。ログファイルを監視するには、以下が必要です。 - 監視対象ホストでZabbixエージェントが稼働していること - ログ監視アイテムが設定されていること ::: noteimportant 監視対象のログファイルのサイズ制限は、[大容量ファイルサポート](/manual/appendix/items/large_file_support)に依存します。 ::: [comment]: # ({/20b129cf-8d33723f}) [comment]: # ({5d32b87c-5d32b87c}) #### 設定 [comment]: # ({/5d32b87c-5d32b87c}) [comment]: # ({66161808-9223a947}) ##### エージェントパラメータの確認 [エージェントの設定ファイル](/manual/appendix/config/zabbix_agentd)で、以下を確認してください。 - `Hostname`パラメータがフロントエンドのホスト名と一致していること。 - `ServerActive`パラメータにアクティブチェックを処理するサーバーが指定されていること。 [comment]: # ({/66161808-9223a947}) [comment]: # ({744dfb1e-e137d9c7}) ##### アイテムの設定ログ監視[アイテム](/manual/config/items/item#overview)を設定します。 ![](../../../../../assets/en/manual/config/items/itemtypes/logfile_item.png){width="600"} 必須の入力フィールドには、赤いアスタリスクが付いています。特にログ監視アイテムでは、以下を入力します。 | | | |--|--------| |*Type*|ここでは **Zabbix agent (active)** を選択します。| |*Key*|以下のいずれかのアイテムキーを使用します。
**log\[\]** または **logrt\[\]**:
これら2つのアイテムキーでは、ログを監視し、regexp の内容によってログエントリをフィルタリングできます（指定されている場合）。
例: `log[/var/log/syslog,error]`。ファイルに 'zabbix' ユーザーの読み取り権限があることを確認してください。そうでない場合、アイテムのステータスは 'unsupported' に設定されます。
**log.count\[\]** または **logrt.count\[\]**:
これら2つのアイテムキーでは、一致した行数のみを返すことができます。
これらのアイテムキーとそのパラメータの使用方法の詳細については、サポートされている [Zabbix agent アイテム](zabbix_agent#supported-item-keys) キーのセクションを参照してください。| |*Type of information*|自動的に事前入力されます。
log\[\] または logrt\[\] アイテムの場合 - `Log`;
log.count\[\] または logrt.count\[\] アイテムの場合 - `Numeric (unsigned)`。
オプションで `output` パラメータを使用する場合は、`Log` 以外の適切な情報の型を手動で選択できます。
Log 以外の情報の型を選択すると、ローカルタイムスタンプが失われることに注意してください。| |*Update interval (in sec)*|このパラメータは、エージェントがログファイルの変更をどのくらいの頻度で確認するかを定義します。1秒に設定すると、新しいレコードをできるだけ早く取得できます。| |*Log time format*|このフィールドでは、ログ行のタイムスタンプを解析するためのパターンを任意で指定できます。サポートされているプレースホルダー:
\* **y**: *年 (1970-2038)*
\* **M**: *月 (01-12)*
\* **d**: *日 (01-31)*
\* **h**: *時 (00-23)*
\* **m**: *分 (00-59)*
\* **s**: *秒 (00-59)*
空欄のままにすると、タイムスタンプは Unix time で 0 に設定され、1970年1月1日を表します。
例えば、Zabbix agent ログファイルの次の行を考えてみましょう。
" 23480:20100328:154718.045 Zabbix agent started. Zabbix 1.8.2 (revision 11211)."
この行は、先頭に PID 用の6文字分の位置があり、その後に日付、時刻、残りのメッセージが続きます。
この行のログ時刻形式は "pppppp:yyyyMMdd:hhmmss" になります。
"p" と ":" はプレースホルダーであり、"yMdhms" 以外の任意の文字を使用できることに注意してください。| [comment]: # ({/744dfb1e-e137d9c7}) [comment]: # ({ce4ac909-2a661d49}) #### 重要な注意事項 - サーバーとエージェントは、監視対象ログのサイズと最終更新時刻（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 "" in ""` が記録されます。 Zabbixエージェントは、チェック対象の `logrt[]` アイテムについて、エージェントが確認済みの最新の最終更新時刻より古い更新時刻を持つログファイルを無視します。 - エージェントは、前回停止した位置からログファイルの読み取りを開始します。 - すでに解析済みのバイト数（サイズカウンター）と最終更新時刻（タイムカウンター）はZabbixデータベースに保存され、エージェントが起動直後である場合や、以前は無効または未サポートだったアイテムを受信した場合でも、その位置からログファイルの読み取りを開始できるようにエージェントへ送信されます。ただし、エージェントがサーバーから0以外のサイズカウンターを受信していても、logrt\[\] または logrt.count\[\] アイテムが一致するファイルを見つけられない場合、後でファイルが現れたときに先頭から解析できるよう、サイズカウンターは0にリセットされます。 - ログファイルのサイズが、エージェントが認識しているログサイズカウンターより小さくなった場合は常に、そのカウンターは0にリセットされ、エージェントはタイムカウンターを考慮しつつログファイルの先頭から読み取りを開始します。 - ディレクトリ内に同じ最終更新時刻を持つ一致ファイルが複数ある場合、エージェントはデータの取りこぼしや同じデータの二重解析を避けるため、同じ更新時刻を持つすべてのログファイルを正しく解析しようとしますが、すべての状況で保証されるわけではありません。エージェントは特定のログローテーション方式を前提とせず、それを判定もしません。同じ最終更新時刻を持つ複数のログファイルがある場合、エージェントはそれらを辞書順の降順で処理します。そのため、ローテーション方式によっては、ログファイルは元の順序どおりに解析・報告されます。一方で、別のローテーション方式では元のログファイル順序が維持されず、一致したログレコードが順序の変わった状態で報告される可能性があります（ログファイルの最終更新時刻が異なる場合、この問題は発生しません）。 - Zabbixエージェントは、ログファイルの新しいレコードを *Update interval* 秒ごとに処理します。 - Zabbixエージェントは、1秒あたりログファイルから **maxlines** を超えて送信しません。この制限は、ネットワークおよびCPUリソースの過負荷を防ぐためのもので、[agent configuration file](/manual/appendix/config/zabbix_agentd) の **MaxLinesPerSecond** パラメータで指定されたデフォルト値よりも **maxlines** が優先されます。 - 必要な文字列を見つけるために、Zabbixは MaxLinesPerSecond に設定された値の10倍の新規行を処理します。したがって、たとえば `log[]` または `logrt[]` アイテムの *Update interval* が1秒の場合、デフォルトではエージェントは1回のチェックで最大200件のログファイルレコードを解析し、そのうち最大20件の一致レコードをZabbixサーバーへ送信します。エージェント設定ファイルで **MaxLinesPerSecond** を増やすか、アイテムキーで **maxlines** パラメータを設定することで、この上限は1回のチェックあたり最大10000件の解析済みログファイルレコード、および1000件の一致レコード送信まで引き上げることができます。 *Update interval* を2秒に設定した場合、1回のチェックあたりの上限は *Update interval* が1秒の場合の2倍になります。 - さらに、log および log.count の値は、エージェント送信バッファサイズの50%に常に制限されます。たとえその中に非ログ値が存在しない場合でも同様です。したがって、**maxlines** の値を1回の接続で送信するためには（複数回の接続ではなく）、エージェントの [BufferSize](/manual/appendix/config/zabbix_agentd) パラメータは少なくとも 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 にはなりません。 - `log[]` または `logrt[]` アイテムが NOTSUPPORTED になった理由を調べるには、Zabbixエージェントのログファイルが役立つ場合があります。 Zabbixは自身のエージェントログファイルを監視できますが、DebugLevel=4 または DebugLevel=5 の場合を除きます。 - 正規表現を使用して疑問符を検索する場合、たとえば `\?` では、テキストファイルにNUL文字が含まれていると誤検出が発生する可能性があります。これは、改行文字まで行の処理を継続するために、Zabbixがそれらを "?" に置き換えるためです。 [comment]: # ({/ce4ac909-2a661d49}) [comment]: # ({d368c478-5fc56a1f}) #### 正規表現の一致部分の抽出正規表現の一致が見つかった場合に、対象ファイルの全行を返すのではなく、興味のある値だけを抽出したい場合があります。ログアイテムには、一致した行から目的の値を抽出する機能があります。これは、`log`および`logrt`アイテムの追加パラメータ **output** によって実現されます。 'output'パラメータを使用すると、関心のある一致の「キャプチャグループ」を指定できます。たとえば、次のようにします。 ```default log[/path/to/the/file,"large result buffer allocation.*Entries: ([0-9]+)",,,,\1] ``` これは、次の内容に見られるエントリ数を返すことができます。 ```default 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\]+)** を参照しているため、数値だけが返されます。また、数値を抽出して返すことができるため、その値を使用してトリガーを定義できます。 [comment]: # ({/d368c478-5fc56a1f}) [comment]: # ({f8ba4a8e-32045a26}) #### maxdelayパラメータの使用ログアイテムの`maxdelay`パラメータを使用すると、`maxdelay`秒以内に最新の行が分析されるように、ログファイルの古い行を無視することができます。 ::: notewarning 'maxdelay' > 0を指定すると、**重要なログファイルの記録が無視され、アラートが見逃される**可能性があります。必要な場合のみ、自己責任で慎重に使用してください。 ::: デフォルトでは、ログ監視用のアイテムはログファイルに現れるすべての新しい行を追跡します。しかし、アプリケーションによっては、特定の状況下でログファイルに大量のメッセージを書き込み始めるものがあります。たとえば、データベースやDNSサーバーが利用できない場合、そのようなアプリケーションは通常の動作が回復するまで、ほぼ同一のエラーメッセージでログファイルを埋め尽くします。デフォルトでは、これらすべてのメッセージが忠実に分析され、`log`および`logrt`アイテムで設定された条件に一致する行がサーバーに送信されます。過負荷に対する組み込みの保護には、設定可能な`maxlines`パラメータ（サーバーが受信する一致するログ行の数を制限）と10\*'maxlines'の制限（1回のチェックでエージェントによるホストのCPUとI/Oの過負荷を防止）があります。それでも、組み込みの保護には2つの問題があります。第一に、あまり有益でない可能性のある大量のメッセージがサーバーに報告され、データベースのスペースを消費します。第二に、1秒あたりに分析される行数が制限されているため、エージェントが最新のログ記録に何時間も遅れる可能性があります。おそらく、何時間も古い記録を追いかけるよりも、ログファイルの現在の状況を早く知りたいと思うでしょう。この2つの問題の解決策が`maxdelay`パラメータの使用です。 `maxdelay` > 0が指定されている場合、各チェック時に処理されたバイト数、残りのバイト数、および処理時間が測定されます。これらの数値から、エージェントはログファイル内のすべての残りの記録を分析するのに何秒かかるかという推定遅延を計算します。遅延が`maxdelay`を超えない場合、エージェントは通常どおりログファイルの分析を続行します。遅延が`maxdelay`を超える場合、エージェントは**ログファイルの一部を「ジャンプ」して無視し**、残りの行が`maxdelay`秒以内に分析できるように新しい推定位置に移動します。エージェントは無視された行をバッファに読み込むことすらせず、ファイル内でジャンプするおおよその位置を計算することに注意してください。ログファイルの行をスキップした事実は、エージェントのログファイルに次のように記録されます。 ```default 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` < `更新間隔`に設定することは推奨されません（頻繁に小さな「ジャンプ」が発生する可能性があります）。 [comment]: # ({/f8ba4a8e-32045a26}) [comment]: # ({5a6d4f6f-57bbb0a9}) #### 'copytruncate'ログファイルローテーションの取り扱いに関する注意事項 `logrt`に`copytruncate`オプションを指定した場合、異なるログファイルには異なるレコード（少なくともタイムスタンプが異なる）が含まれていると仮定します。そのため、初期ブロック（最初の512バイトまで）のMD5サムも異なります。初期ブロックのMD5サムが同じ2つのファイルがある場合、一方がオリジナルで、もう一方がコピーであることを意味します。 `logrt`に`copytruncate`オプションを指定した場合、重複を報告せずにログファイルのコピーを正しく処理するように努めます。ただし、同じタイムスタンプで複数のログファイルコピーを作成したり、logrt\[\]アイテムの更新間隔よりも頻繁にログファイルをローテーションしたり、エージェントを頻繁に再起動したりすることは推奨されません。エージェントはこれらの状況すべてを適切に処理しようとしますが、すべての状況で良好な結果が保証されるわけではありません。 [comment]: # ({/5a6d4f6f-57bbb0a9}) [comment]: # ({c5cdb98a-c5cdb98a}) #### log*[\] itemのpersistent filesに関する注意事項 [comment]: # ({/c5cdb98a-c5cdb98a}) [comment]: # ({6effb858-99ce1d02}) ##### 永続ファイルの目的 Zabbixエージェントが起動されると、Zabbixサーバーまたはプロキシからアクティブチェックのリストを受信します。 log\*\[\]メトリックの場合、処理済みのログサイズと変更時刻を受信し、どこからログファイルの監視を開始するかを判断します。ファイルシステムから報告された実際のログファイルサイズと変更時刻に応じて、エージェントは処理済みのログサイズからログファイルの監視を継続するか、ログファイルの先頭から再解析するかを決定します。実行中のエージェントは、チェック間で監視されているすべてのログファイルを追跡するための属性のより大きなセットを保持します。このメモリ内の状態は、エージェントが停止すると失われます。新しいオプションパラメータ**persistent_dir**は、log\[\]、log.count\[\]、logrt\[\]、またはlogrt.count\[\]アイテムの状態をファイルに保存するディレクトリを指定します。 Zabbixエージェントが再起動された後、ログアイテムの状態は永続ファイルから復元されます。主なユースケースは、ミラー化されたファイルシステム上にあるログファイルの監視です。ある時点までは、ログファイルは両方のミラーに書き込まれます。その後、ミラーが分割されます。アクティブなコピーでは、ログファイルは新しいレコードを取得しながら成長し続けます。 Zabbixエージェントはそれを分析し、処理済みのログサイズと変更時刻をサーバーに送信します。パッシブコピーでは、ログファイルは同じままで、アクティブコピーよりもかなり遅れています。後で、オペレーティングシステムとZabbixエージェントがパッシブコピーから再起動されます。 Zabbixエージェントがサーバーから受信する処理済みのログサイズと変更時刻は、パッシブコピーの状況には有効でない場合があります。ファイルシステムのミラー分割時点でエージェントが中断した場所からログファイルの監視を継続するために、エージェントは永続ファイルから状態を復元します。 [comment]: # ({/6effb858-99ce1d02}) [comment]: # ({2635fff7-126798f0}) ##### 永続ファイルを使用したエージェントの動作起動時、Zabbixエージェントは永続ファイルについて何も知りません。 Zabbixサーバー（プロキシ）からアクティブチェックのリストを受信した後にのみ、エージェントは一部のログアイテムが指定されたディレクトリの下に永続ファイルでバックアップされるべきであることを認識します。エージェントの動作中、永続ファイルは書き込み用にオープンされ（fopen(filename, "w")）、最新のデータで上書きされます。上書きとファイルシステムのミラー分割が同時に発生した場合に永続ファイルのデータが失われる可能性は非常に低く、特別な処理は行いません。永続ファイルへの書き込み後にストレージメディアへの強制同期（fsync()の呼び出し）は行いません。最新データでの上書きは、該当するログファイルレコードまたはメタデータ（処理済みログサイズおよび変更時刻）がZabbixサーバーに正常に報告された後に行われます。これは、ログファイルが変更され続ける場合、アイテムチェックごとに発生する可能性があります。エージェントのシャットダウン時に特別な処理はありません。 [comment]: # ({/2635fff7-126798f0}) [comment]: # ({8943e15c-0cf19270}) アクティブチェックのリストを受信した後、エージェントは不要になった永続ファイルを削除対象としてマークします。永続ファイルが不要になるのは、次の場合です: 1. 対応するログアイテムが監視対象ではなくなった場合。 2. ログアイテムが、以前とは異なる **persistent\_dir** の場所で再設定された場合。削除は24時間遅延して実行されます。これは、NOTSUPPORTED 状態のログファイルはアクティブチェックのリストに含まれないものの、後で SUPPORTED になり、その永続ファイルが有用になる可能性があるためです。 24時間が経過する前にエージェントが停止した場合、不要になったファイルは削除されません。これは、Zabbixエージェントがそれらの場所に関する情報をZabbixサーバーから受け取れなくなるためです。 ::: notewarning ユーザーが古い永続ファイルを削除しないまま、エージェント停止中にログアイテムの **persistent\_dir** を以前の **persistent\_dir** の場所に再設定すると、古い永続ファイルからエージェントの状態が復元され、メッセージの取りこぼしや誤ったアラートの原因になります。 ::: [comment]: # ({/8943e15c-0cf19270}) [comment]: # ({390550c2-2ce6da68}) ##### 永続ファイルの命名と場所 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になります。 [comment]: # ({/390550c2-2ce6da68}) [comment]: # ({8d97a3fc-e74fd773}) エージェントの動作中に永続ストレージファイルへのアクセス権が削除された場合や、その他のエラー（例：ディスクの空き容量不足）が発生した場合、エラーはエージェントのログファイルに記録されますが、ログアイテムはNOTSUPPORTEDにはなりません。 [comment]: # ({/8d97a3fc-e74fd773}) [comment]: # ({38e18d73-975fe8d1}) ##### I/Oの負荷アイテムの永続ファイルは、サーバーへの各データバッチ（アイテムのデータを含む）の送信が成功した後に更新されます。例えば、デフォルトの`BufferSize`は100です。ログアイテムが70件の一致するレコードを見つけた場合、最初の50件のレコードは1つのバッチで送信され、永続ファイルが更新され、残りの20件のレコードは（より多くのデータが蓄積されたときに遅延して）2番目のバッチで送信され、永続ファイルが再度更新されます。 [comment]: # ({/38e18d73-975fe8d1}) [comment]: # ({d1923644-df734a31}) #### エージェントとサーバー間の通信が失敗した場合の動作 `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[]` チェック：チェック中に「ジャンプ」がなかった場合、動作は上記と同様です。ログファイル行の「ジャンプ」が発生した場合は、「ジャンプ」後の位置が保持され、カウントされた結果は破棄されます。したがって、エージェントは通信障害が発生しても増加するログファイルに追従しようとします。 [comment]: # ({/d1923644-df734a31}) [comment]: # ({3b1e0096-5233be27}) #### 正規表現のコンパイルエラーおよび実行時エラーの処理 `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を記録して、どのログアイテムで実行時エラーが発生したかを特定できるようにします。実行時エラーが発生した場合は、正規表現の設計を見直すことを推奨します。 [comment]: # ({/3b1e0096-5233be27})