- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
试水搭建ELK,使用了ELK7.17.13版本,filebeat默认配置的input type已经是filestream而非旧版的log类型,开始了探索之旅.
ChatGPT3.5介绍说filestream是旧版log类型的替代者,提供了更多的功能和改进,该类型对于新加入文件默认是从尾部开始同步,简单测试后直接上了一台线上机器,log同步QPS破万,马上把ES机器 CPU跑满,妥妥地从文件头部开始读取同步,首次失败,。 ChatGPT继续查询说可以tail_files参数控制log和filestream类型加入新文件时是否从尾部读取的行为,出于谨慎加入tail_files: true参数后尝试同步测试环境的api log,发现依然是从头部开始读取,参数未生效,二次失败。 继续咨询ChatGPT tail_files不生效的可能原因,表示如果之前已经读取过了文件,即便后续修改了tail_files从尾部读取也不会生效,需要删除状态文件registry/filebeat/data.json,最终找到了7.17中对应的log.json文件进行删除,而后重启filebeat发现依然是从头读取整个文件,三次失败。 所谓尽信大模型则不如无大模型确实是有道理的,最终停掉filebeat同步后开始自主探究.
查询资料后发现filestream其实并没有tail_files这一参数,只有旧版的log类型才支持tail_files,有不少关于filestream有没有类似log类型的tail_files功能的提问,回答基本都是提到ignore_inactive这个参数,说是可以达到从尾部读取的功能,官方文档介绍如下:
ignore_inactive
If this option is enabled, Filebeat ignores every file that has not been updated since the selected time. Possible options are since_first_start and since_last_start. The first option ignores every file that has not been updated since the first start of Filebeat. It is useful when the Beat might be restarted due to configuration changes or a failure. The second option tells the Beat to read from files that have been updated since its start.
The files affected by this setting fall into two categories:
Files that were never harvested
Files that were harvested but weren’t updated since ignore_inactive.
For files that were never seen before, the offset state is set to the end of the file. If a state already exist, the offset is not changed. In case a file is updated again later, reading continues at the set offset position.
The setting relies on the modification time of the file to determine if a file is ignored. If the modification time of the file is not updated when lines are written to a file (which can happen on Windows), the setting may cause Filebeat to ignore files even though content was added at a later time.
To remove the state of previously harvested files from the registry file, use the clean_inactive configuration option.
ignore_inactive有两个选项since_first_start、since_last_start,分别代表filebeat首次启动时间和本次启动时间,filebeat对于首次启动或者本次启动时间之后的文件将直接ignore,即不同步其内容。 重点是后面的 For files that were never seen before, the offset state is set to the end of the file. 这句话直接可以理解为对于filebeat之前没有记录过的文件,offset将被直接置为文件尾部,于是看上去似乎将ignore_inactive设置为since_last_start就能达到tail_files: true的效果.
在测试环境尝试同步一个微服务的日志文件,验证发现filebeat确实不再从头部读取整个文件内容同步,直到文件尾部有新的内容写入后,尾部的新内容才被filebeat同步最终写入的ES。 再次加入测试环境api主服务的日志文件同步,结果一模一样的配置api的日志文件却是从头开始同步的!! 。
尝试通过源码探究这看似古怪的现象,才算最终捋清了ignore_inactive这一参数的具体作用:
// beats/filebeat/input/filestream/prospector.go
167 func (p *fileProspector) onFSEvent(
168 log *logp.Logger,
169 ctx input.Context,
170 event loginp.FSEvent,
171 src loginp.Source,
172 updater loginp.StateMetadataUpdater,
173 group loginp.HarvesterGroup,
174 ignoreSince time.Time,
175 ) {
176 switch event.Op {
...
190 if p.isFileIgnored(log, event, ignoreSince) {
191 err := updater.ResetCursor(src, state{Offset: event.Descriptor.Info.Size()})
192 if err != nil {
193 log.Errorf("setting cursor for ignored file: %v", err)
194 }
195 return
196 }
...
如上可以看到onFSEvent函数在190行调用了isFileIgnored函数判定文件是否符合ignore条件,若符合则直接将其OffSet置为文件实际Size,亦即设置为从文件尾部开始读取,而isFileIgnored函数实现如下:
224 func (p *fileProspector) isFileIgnored(log *logp.Logger, fe loginp.FSEvent, ignoreInactiveSince time.Time) bool {
225 if p.ignoreOlder > 0 {
226 now := time.Now()
227 if now.Sub(fe.Descriptor.Info.ModTime()) > p.ignoreOlder {
228 log.Debugf("Ignore file because ignore_older reached. File %s", fe.NewPath)
229 return true
230 }
231 }
232 if !ignoreInactiveSince.IsZero() && fe.Descriptor.Info.ModTime().Sub(ignoreInactiveSince) <= 0 {
233 log.Debugf("Ignore file because ignore_since.* reached time %v. File %s", p.ignoreInactiveSince, fe.NewPath)
234 return true
235 }
236 return false
237 }
可以看到若ignoreInactiveSince有值--since_first_start/since_last_start,且当前时间>=ignoreInactiveSince则返回true,于是调用方onFsEvent将读取offset设置为文件尾,至于ignoreOlder对应于filestream的配置参数ignore_older,其判定机制类似,区别在于配置时是采用5m、5h这样的相对时间格式。 测试环境用于测试的微服务日志更新很少,可能几分钟才有新内容,所以filebeat重启后其更新时间小于since_last_start,也就被isFileIgnored判定为true,于是从尾部开始读取文件;而测试环境主api服务的log则是秒级更新,其会被isFileIgnored判定为false,所以会从头读取文件。 也就是说ignore_inactive能够对于新出现的文件设置为从尾部读取的前提是:该文件的最后更新时间小于ignore_inactive设置时间,但是对于秒级甚至ms级持续更新的在线服务日志文件,这个条件判定正常是无法满足的,其并不能完成log类型tail_files对于全部新文件从尾部读取的功能.
最终得出结论:新filestream类型目前并没有提供旧log类型tail_files参数类似的可以控制新加入文件是否从尾部读取的功能,对于持续读写的大log文件首次接入filebeat,可能会由于从头开始同步导致短时QPS飙升进而导致一系列负载飙升,需充分考虑相应的处理方案以防万一.
转载请注明出处,原文地址: https://www.cnblogs.com/AcAc-t/p/filebeat_filestream_read_offset.html 。
https://www.elastic.co/guide/en/beats/filebeat/7.17/filebeat-input-filestream.html 。
最后此篇关于filebeat新filestream类型是否支持tail_files类似功能探究的文章就讲到这里了,如果你想了解更多关于filebeat新filestream类型是否支持tail_files类似功能探究的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我的 filebeat(来自 docker.elastic.co/beats/filebeat:6.1.2 的容器)收割机正在被 close_inactive 关闭,我不希望它们被关闭。来自 here
我是ELK的新手。我先安装了没有 Logstash 的 Elasticsearch 和 Filebeat,我想将数据从 Filebeat 发送到 Elasticsearch。在我安装了 Filebea
我正面临 logstash 的延迟问题。 事实上,我有一个这样构建的 ELK 堆栈: 我在 AWS 自动缩放组中有多个 AWS EC2 网络前端 我在每个前端都安装了 filebeat filebea
我的目标 我正在尝试提交对 Filebeat documentation 的修复,写于asciidoc 。 来源 Currently it is not possible to recursively
我的目标 我正在尝试提交对 Filebeat documentation 的修复,写于asciidoc 。 来源 Currently it is not possible to recursively
我正在尝试使用 filebeat test ouput -e -c filebeat.yml 测试我的配置,我只看到带有命令列表的帮助消息。 我其实是想输出数据文件来验证。虽然我已经测试了 fileb
是否可以将文件节拍设置为从远程目录读取(因为我无法在那台机器上安装进程) 我在beats yml上是这样设置的: filebeat: # List of prospectors to fetch
我目前正在使用 ELK 5.5。现在看来 document_type 在 Filebeats 中已被弃用,但我现在在任何地方都找不到任何关于如何实现相同的示例。 这是我在日志中得到的: WARN DE
我在 filebeat 方面遇到了一些奇怪的问题 我正在使用云形成来运行我的堆栈,并且我正在安装和运行 filebeat 来进行日志聚合, 我将/etc/filebeat/filebeat.yml注入
因此,我正在使用Filebeat读取几种不同的文件类型。我为要收获的每种文件设置document_type。我的问题是我想将大多数这些文件类型发送到Logstash,但是我希望将某些类型的文件直接发送
我正在尝试从 filebeat 读取文件并将它们推送到 logstash。在推送它们之前,我正在尝试合并包含 java 堆栈跟踪的事件。我试过这个过滤器,但它不起作用。 filebeat.prospe
paths: - /var/log/*.log 我使用它作为filebeat中运输日志的路径。 输出为elasticsearch。 output: elasticsearch:
我有一个读取多种不同日志格式的文件节拍。 一种工作得很好的格式是单个衬里,它作为单个事件发送到 Logstash。 现在,我有另一种格式,即多线。我想将其作为单个事件读取并将其发送到 Logstash
我们正在通过filebeat将数据摄取到Elasticsearch并遇到配置问题。 我正在尝试为特定字段指定日期格式(标准@timestamp字段保留索引时间,我们需要实际的事件时间)。到目前为止,我
我正在使用 Filebeat > logstash > elasticsearch > kibana 运行一个基本的 elk 堆栈设置——全部在 5.2 版上 当我删除 Filebeat 并将 log
我想要一个filebeat实例可以将数据发送到不同的logstash管道的功能。 这可能吗? 我已经配置了一个logtash服务,它具有两个管道 管道给出了单独的端口。 假设管道1(端口5044),管
首先我为我的英语道歉。 我是一家公司的实习生,我用 Filebeat 提出了一个解决方案 ELK 来发送日志。 问题是一旦恢复 syslog_pri 总是显示 Notice 和 severity_co
问题: TCP 输入是否管理收割机(即,您是否将文件路径发送到 TCP 输入,然后收割机开始摄取该文件)? TCP 输入能否接受结构化数据(例如 log 输入上的 json 配置选项)? TCP 输入
我正在使用 Filebeat 将日志数据从我的本地 txt 文件发送到 Elasticsearch,并且我想将 message 行中的一些字段添加到事件中——比如时间戳和日志级别。例如,这是我的日志行
filebeat 是否使用 tail -f 检查文件中的新内容,然后将其刷新到所需的输出?或者有没有其他方法检查文件中的新内容? 最佳答案 由于 filebeat 是开源的,您可以随时 go look
我是一名优秀的程序员,十分优秀!