TailFile

简介

此 Processor 提供了一项强大的能力：允许用户周期性地监视一个正在被其他进程写入的文件。当文件发生 变化时，新增的行会被摄取（ingest）。该 Processor 假定文件中的数据是文本。

跟踪（tail）文件系统中的文件看似简单，实则出了名的困难。这是因为我们在周期性地检查一个正在被 写入的文件的内容：文件可能在不断变化，也可能很少变化；文件可能会被"轮转"（即重命名），而且 重要的是，即便在应用（本例中为 Lynxus）重启之后，也要能够从上次的位置继续。还有一些其他的 复杂情况：例如，NFS 挂载的磁盘可能显示数据可读，但实际读取时返回 NUL 字节（Unicode 0）， 因为真正的字节尚不可知（参见 属性）；不同的文件系统的时间戳 精度也各不相同。

此 Processor 的设计能够处理上述所有情况。这可能会使配置稍显复杂，但本文档应当能提供你上手 所需的全部内容！

模式

此 Processor 根据配置的模式用于跟踪一个或多个文件。选择哪种模式取决于被跟踪文件所遵循的日志 模式。无论哪种情况，如果存在轮转模式，轮转文件必须是纯文本文件（目前不支持压缩）。

• Single file（单文件）：Processor 会跟踪 'File(s) to tail' 属性中给出路径的文件。
• Multiple files（多文件）：Processor 会在 'Base directory' 中查找文件。它会按照 'Recursive lookup' 属性递归查找，并跟踪所有匹配 'File(s) to tail' 属性中所给正则表达式的文件。

轮转文件名模式（Rolling filename pattern）

如果使用了 'Rolling filename pattern' 属性，当 Processor 检测到被跟踪的文件发生轮转时， 会在轮转后的文件中查找可能遗漏的消息。为此，Processor 会使用该模式在与被跟踪文件相同的目录中 查找轮转文件。

为了在 'Multiple files' 模式下、当多个被跟踪文件位于同一目录时该属性仍然可用，可以使用 ${filename} 标签来引用被跟踪文件的名称（不含扩展名）。例如，如果有：

/my/path/directory/my-app.log.1 /my/path/directory/my-app.log /my/path/directory/application.log.1 /my/path/directory/application.log

那么 'rolling filename pattern' 应为 ${filename}.log.*。

不同模式与策略的说明

'Single file' 模式假定即使存在轮转模式，被跟踪的文件名始终保持不变。示例：

/my/path/directory/my-app.log.2 /my/path/directory/my-app.log.1 /my/path/directory/my-app.log

新的日志消息总是追加到 my-app.log 文件中。

如果递归性（recursivity）设置为 'true'，被跟踪文件的正则表达式必须能够涵盖基础目录与被跟踪 文件之间可能存在的中间目录。示例：

/my/path/directory1/my-app1.log /my/path/directory2/my-app2.log /my/path/directory3/my-app3.log

Base directory: /my/path Files to tail: directory[1-3]/my-app[1-3].log Recursivity: true

如果 Processor 配置为 'Multiple files' 模式，还有两个属性比较重要：

• Lookup frequency（查找频率）：指定 Processor 在再次列出被跟踪文件之前等待的最短时间。
• Maximum age（最大存活时间）：指定根据文件最后修改时间判断"不会再有新消息追加"所需的 最短时间。如果自文件上次修改以来经过的时间超过该时长，该文件将不再被跟踪。例如，如果一个 文件在 24 小时前被修改，而此属性设为 12 小时，则该文件不会被跟踪；但如果此属性设为 36 小时， 该文件会继续被跟踪。

要实现高性能，需要注意 'Lookup frequency'、'Maximum age' 属性以及 Processor 的触发频率。 建议保持 'Maximum age' > 'Lookup frequency' > Processor 调度频率，以避免丢失数据。也不建议 把 'Maximum Age' 设得太低，因为如果某个文件在被认为"太旧"之后又追加了消息，该文件中的所有 消息可能会被重新读取，导致数据重复。

如果 Processor 配置为 'Multiple files' 模式，'Rolling filename pattern' 属性必须足够 具体，以确保只列出轮转文件，而不会列出同一目录中当前正在被跟踪的其他文件（可以通过使用 ${filename} 标签来实现）。

多行消息的处理

大多数情况下，跟踪文件时我们乐于周期性接收数据，无论数据是如何写入文件的。但也存在一些场景， 数据的写入方式要求多行必须保持在一起。以日志文件中可能出现的如下文本为例：

2021-07-09 14:12:19,731 INFO [main] cn.org.acal.lynxus.Lynxus Launching Lynxus... 
2021-07-09 14:12:19,915 INFO [main] o.a.n.p.AbstractBootstrapPropertiesLoader Determined default application properties path to be '/Users/mpayne/devel/lynxus/lynxus-assembly/target/lynxus-1.14.0-SNAPSHOT-bin/lynxus-1.14.0-SNAPSHOT/./conf/lynxus.properties' 
2021-07-09 14:12:19,919 INFO [main] o.a.lynxus.properties.LynxusPropertiesLoader Loaded 199 properties from /Users/mpayne/devel/lynxus/lynxus-assembly/target/lynxus-1.14.0-SNAPSHOT-bin/lynxus-1.14.0-SNAPSHOT/./conf/lynxus.properties 
2021-07-09 14:12:19,925 WARN Line 1 of Log Message 			Line 2: This is an important warning. 			Line 3: Please do not ignore this warning. 			Line 4: These lines of text make sense only in the context of the original message. 
2021-07-09 14:12:19,941 INFO [main] Final message in log file

在这种情况下，我们可能希望确保日志行不会被以这样的方式摄取：多行日志消息的第 1、2 行进入一个 FlowFile，而第 3、4 行进入另一个。为此，该 Processor 提供了 属性。如果 把该属性设置为 \d{4}-\d{2}-\d{2}，就是告诉 Processor：每条消息应以 4 位数字开头，后跟一个 短横线、2 位数字、一个短横线和 2 位数字。也就是说，我们告诉它每条消息都以 yyyy-MM-dd 格式的 时间戳开头。正因如此，即使 Processor 运行时只看到多行日志消息的第 1、2 行，它也不会立即摄取 数据，而是等到看到下一条以时间戳开头的消息。

注意，正因如此，在上述情况下 Processor 遇到的最后一条消息是 "Final message in log file" 这一行。 此时，Processor 并不知道接下来遇到的文本是属于这一行的内容还是一条新消息，因此它不会摄取这条 数据，而是等到遇到另一条消息（匹配我们的正则）或者文件发生轮转（重命名）。因此，如果写入文件的 进程在此处停止写入，文件中最后一条消息的摄取可能会有一些延迟。

此外，还存在正则表达式与文件中的数据不匹配的风险。这可能导致整个文件的内容被缓冲，进而导致 Lynxus 内存耗尽。为避免这种情况， 属性限制了可缓冲的数据量。如果缓冲的数据 达到该上限，即使还没有遇到下一条消息，数据也会被刷新（flush）到 FlowFile 中。