Logtail与LoongCollector兼容性说明

版本命名变更说明

Logtail、iLogtail、LoongCollector实际上是同一软件在不同时期的不同命名：

• Logtail/iLogtail：3.0版本之前的命名。

• LoongCollector：3.0版本之后的命名。

日志与Tag解析规范化

1. 日志主体重复key处理：

   • 1.8版本之后：不允许日志主体中出现重复的key，例如输入content: xxx, content: yyy将只保留一个content: xxx。

   • 1.8版本之前：保留所有重复key并重命名，例如输出content: xxx, content_0: yyy

2. 日志tag重复key处理：

   • 1.8版本之后：不允许日志tag中出现重复的key，例如输入__tag__:tag: xxx, __tag__:tag: yyy将只保留一个__tag__:tag: xxx。

   • 1.8版本之前：保留所有重复key并重命名，例如输出__tag__:tag: xxx, __tag__:tag_0: yyy。

单行、多行日志处理增强

1. 异常处理机制变更：

   • 2.x版本：默认按\n切分，如需丢弃可通过Multiline.UnmatchedContentTreatment参数设置为discard。

   • 1.x版本：无法按行首分割时将整个内容作为一块处理。

2. 最后一行日志处理：

   • 1.8版本之前：无回车符的最后一行日志或最后一段多行日志需要等待回车或下一个多行段落才会输出。

   • 1.8版本之后：引入超时机制控制，全局控制参数为default_reader_flush_timeout，采集配置级控制参数为FlushTimeoutSecs。为了保证最后一段完整性，默认延时为60秒，如果对延时敏感可通过上述参数调整，不建议设置为0，以免日志截断。

Tag处理机制变更

通过扩展插件处理后的Tag将保留在Tag形式中，即写入数据模型的tags结构中，相比之前写入content结构的方式大幅节省空间：

• 对消费场景有影响，需要进行兼容性处理。

• 对查询场景无影响。

容器日志采集路径变更

采集ACK集群容器日志时，如果配置使用ACK控制台创建：

• 2.0版本起：目录的最大递归深度默认是0，如果采集路径中有/**/，则为10。

• 2.0版本之前：最大递归深度默认均为100。