Logtail的工作原理是什么
Logtail的工作原理是什么，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
Logtail数据采集原理介绍，包括文件采集原理以及插件采集原理。
文件采集原理
Logtail文件采集的流程包括：文件监听、文件读取、日志处理、日志过滤、日志聚合和数据发送6个环节。下面将分别进行介绍：
注意：本节只介绍正常运行模式中Logtail的文件采集原理，该模式下不支持采集历史文件，如有采集历史文件需求，请参考采集历史文件。
文件监听
当Logtail获取到采集配置后，根据配置的日志路径、文件名、最大监控目录深度递归扫描目录下符合文件名规则的日志目录和文件。
为保证日志采集时效性以及稳定性，Logtail会对采集目录注册事件监听（Linux下Inotify、Windows下使用ReadDirectoryChangesW）以及定期轮询。
当第一次应用配置时，对于目录下存量的日志文件不会进行采集，直到文件在配置应用后产生修改事件才会采集。
当监听到文件修改后，会进入文件读取环节。
文件读取
每次Logtail读取会从该文件上一次读取的偏移处开始。
若该文件首次读取，会检查该文件大小，若文件小于1MB，则从文件头开始读取，否则从文件尾1MB处开始读取。
每次读取最多512KB数据，因此一条日志最大支持512KB。
日志处理
对于读取的数据块，会根据行首配置进行分行，切分成多条日志。
对于每条日志内容执行对应的解析，例如正则、分隔符、JSON等。
若未配置时间字段，则日志时间为当前解析时间；若配置了时间提取字段，则从解析的日志字段中提取时间，若时间距离当前时间超过12小时，则丢弃该日志并上传错误信息。
若该日志可以被正确解析，则进入日志过滤环节。
若该日志解析失败且开启 高级配置中的丢弃解析失败日志，则直接丢弃该日志，并上报解析失败的报错信息
若该日志解析失败，但未开启 高级配置中的丢弃解析失败日志，则将解析失败的原始日志上传，其中Key为__raw_log__、Value为日志内容
日志过滤
若用户未设置 高级配置 中的 过滤器配置，则跳过日志过滤环节。
若用户已经设置过滤器配置，则会对每条日志中的所有字段进行遍历并验证。
只有过滤器中配置的所有字段都在该日志出现，且所有对应的字段全部符合过滤器配置时，日志才会被采集，否则丢弃该日志。
日志聚合
为降低网络请求次数，当日志处理、过滤完毕后，会在Logtail内部缓存一段时间再进行发送。
缓存规则有3条，任一一条满足则触发发送：
日志聚合时间超过3秒
日志聚合条数超过4096条
日志聚合总大小超过1MB
日志发送
日志发送前会进行压缩，目前Logtail采用的是LZ4压缩算法。
日志发送受限于
max_bytes_per_sec和send_request_concurrency限制，Logtail会保证发送速率以及并发不超过配置值，具体参数请参考启动参数配置。若数据发送失败，则根据错误信息选择重试还是丢弃数据：
401错误，说明没有权限采集数据，直接丢弃。
404错误，说明project或logstore不存在，直接丢弃。
403错误，Quota超限，等待3秒后重试。
500错误，等待3秒后重试。
网络超时，等待3秒后重试。
插件采集原理
Logtail的插件采集流程主要包括以下环节：插件数据采集、数据处理、日志聚合和日志发送。
插件数据采集
插件数据采集的原理在每个插件的文档中都有介绍，具体请参见各个插件的帮助文档。
数据处理
插件数据处理逻辑请参考插件-数据处理。
日志聚合
插件的日志聚合逻辑和文件采集的日志聚合逻辑一致。
日志发送
插件的日志发送逻辑和文件采集的日志发送逻辑一致。
资源限制
Logtail会根据配置文件中的资源限制进行工作，若资源占用长时间（5分钟）超过限定值，则Logtail会进行强制重启。重启后可能会产生一定的数据重复。
数据采集可靠性
Logtail在采集数据时，会定期将采集的点位（CheckPoint）信息保存到本地，若遇到宕机、Crash等异常时，Logtail再次启动会从上一次记录的位置处开始采集数据，尽可能保证数据不丢失。
Logtail内部采用了很多机制提升日志采集可靠性，但并不能保证日志绝对不会丢失。以下情况可能造成日志丢失：
Logtail未运行且日志轮转多次。
日志轮转速度极快，例如1秒轮转1次。
日志采集速度长期无法达到日志产生速度。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注行业资讯频道，感谢您对的支持。
