なぜFilebeat採集ログはリアルタイムではないのですか?(採集時間とlog自体の時間に差がある)

注意:この文書のfilebeatのバージョンは7.5で、異なるバージョンのfilebeatの動作が異なる場合があります.
一、前言
filebeatが収集したログのタイムスタンプと、ログ管理プラットフォームが実際に受け取ったログのタイムスタンプは、通常数秒の遅延があり、場合によっては10数秒に達することもあります.このうち、filebeatからログ管理プラットフォームまでのネットワークの影響はありますが、最大の遅延は、ログの生成からfilebeatに報告されるまでの期間です.なぜfilebeat採集ログはリアルタイムではないのですか?
tail-fに似た簡単なログ収集プログラムであれば、プログラムがログファイルに書き込まれる限り、1秒もしないうちに出力されるべきです.しかし、filebeatは単純なtail-fではなく、システムリソースの占有量を減らし、スループットを増大させる目的で、filebeat内部では様々な構成を使用して具体的な動作を管理しています.
二、原因
まずfilebeatはinotifyのようなメカニズムを採用してターゲットファイル/ディレクトリの状態変化を傍受するのではなく、非常に古いが実用的な方法であるポーリングを採用してログファイルを収集する.一定時間ごとにfilebeatは、ターゲットパスの下に収集可能なファイルがあるかどうか、収集されたファイルに対して新しい書き込みがあるかどうかをチェックします.この「一定時間ごと」だからこそ、アプリケーションがログに書き込まれた後、収集作業が相次ぐことはありません.間の時間差は遅延の主な源である.
1、入力の遅延
filebeatは、ポーリングの動作を制御するために以下のパラメータを使用します.

- type: log
  # How often the input checks for new files in the paths that are specified
  # for harvesting. Specify 1s to scan the directory as frequently as possible
  # without causing Filebeat to scan too frequently. Default: 10s.
  scan_frequency: 10s
  
  # Backoff values define how aggressively filebeat crawls new files for updates
  # The default values can be used in most cases. Backoff defines how long it is waited
  # to check a file again after EOF is reached. Default is 1s which means the file
  # is checked every second if new lines were added. This leads to a near real time crawling.
  # Every time a new line appears, backoff is reset to the initial value.
  backoff: 1s
  
  # Max backoff defines what the maximum backoff time is. After having backed off multiple times
  # from checking the files, the waiting time will never exceed max_backoff independent of the
  # backoff factor. Having it set to 10s means in the worst case a new line can be added to a log
  # file after having backed off multiple times, it takes a maximum of 10s to read the new line
  max_backoff: 10s
  backoff_factor: 2

このうちscan_frequencyは、ターゲットパスの下に新しいファイルが表示されているかどうかをどのくらいチェックするかに影響します.このデフォルトは10秒ですが、log rotationが発生しない限り、新しいログファイルは表示されません.(最悪の場合は10秒遅れて新しいファイルが見つかりました)
その後、「backoff」に関連する3つの構成は、既存のログの収集動作に適用される.filebeatがファイルのログを収集し(ファイルの最後まで読む)と、新しいログappendが入ってくるかどうかをしばらく隔てて確認します.この時間がbackoffの値です.filebeatが再表示されても新しいログがない場合は、backoff*backoff_を隔てます.factorはデフォルトの2秒後にbackoff全体がmax_に達するまで表示を続けます.backoffは10秒までです.したがって、たまに発生するログ(エラーログなど)については、filebeatによって収集されるまで10秒かかる可能性があります.
しかしながら、filebeatによって収集されたものは、filebeatによって出力されるものではない.filebeat全体のプロセスは、異なる入力-汎用的な処理-異なる出力の3つのセグメントに分けることができます.
2、汎用処理の遅延
ログ入力部に遅延があるほか,filebeatは汎用的な処理を行う際にも遅延を導入する.これはfilebeatがeventをキューにキャッシュし、より高いスループットのバッチ出力を追求するためです.

queue:
  mem:
    # Max number of events the queue can buffer.
    events: 4096
    
    # Hints the minimum number of events stored in the queue,
    # before providing a batch of events to the outputs.
    # The default value is set to 2048.
    # A value of 0 ensures events are immediately available
    # to be sent to the outputs.
    flush.min_events: 2048
    
    # Maximum duration after which events are available to the outputs,
    # if the number of events stored in the queue is < `flush.min_events`.
    flush.timeout: 1s

デフォルトでは、filebeatは次の2つの条件のいずれかが成立した場合にのみキャッシュキューを消去します.

現在キャッシュされているイベントはflush.min_events

に達する.

前回のキャッシュのリフレッシュ動作は、flush.timeout

を超える.
もちろんqueueがもたらす遅延は最大1秒であり,backoffがもたらすオーバーヘッドよりも大きくない.
3、出力側の遅延
「汎用的な処理」を過ぎると、「異なる出力」になります.ここにも少しバッチがあります.ほとんどの出力タイプにはbulk_max_sizeがあり、出力ごとにロットのサイズを制御します.でもbulk_を考えるとmax_sizeの値はqueueのキャッシュよりも小さいことが多いので、遅延は無視できます.
以上のパラメータから推定すると、最大遅延時間は入力遅延(10 s)+汎用処理時間(1 s)+出力端遅延(1 s仮定)=12 sである.すなわちlog自身のコンテンツ時間とfilebeat収集タイムスタンプの差12 s
三、可変パラメータflush.timeoutまたはflush.min_eventsを減らすなど、queueのキャッシュ設定を減らすことを選択すると、予想外の問題が発生する可能性があります.
filebeatは、ロットの出力が完了するたびに、収集進捗ファイルが更新されます(7.5ではdata/data/registry/filebeat/data.json).このファイルをタイムリーに更新しないと、filebeatがクラッシュすると、採集の進捗が失われ、ログの重複採集が発生します.queueを小さくすると、1ロットも小さくなり、進捗ファイルの保存が頻繁になります.進捗ファイルへの書き込みはファイル全体を書き直し、書き込みのたびにfsyncを呼び出して書き込みデータがディスクに落ちることを保証するため、この操作にかかる時間は短くありません.
filebeatにはもう一つの構成項目があります.

# The timeout value that controls when registry entries are written to disk
# (flushed). When an unwritten update exceeds this value, it triggers a write
# to disk. When flush is set to 0s, the registry is written to disk after each
# batch of events has been published successfully. The default value is 0s.
filebeat.registry.flush: 0s

デフォルトでは、バッチの更新が完了するたびに進捗が更新されます.しかし、数秒おきに更新するように設定することができます.filebeatは正常に終了すると進捗ファイルも更新されるため、データの一貫性を保障するデータベースではないので、数秒の進捗を失う心配はありません.
転載先:https://segmentfault.com/a/1190000022088221