我们正在使用ELK来控制程序日志。在我们的FileBeat配置中,我们从 30个不同的 路径中收获, 这些
路径包含每秒更新的文件(它仅在prod的机器中每秒更新一次-
在其他Dev机器中,日志大大减少)。我们的日志文件变旧后才会被删除,并且我们将停止使用它们(我们也不会在此修改名称)。最近,我们发现, 来自生产机器
的配置文件(.yml)中最后路径的日志从未出现在Kibana中。
经过调查,我们意识到卡在文件上的FileBeat是第一个路径,似乎从未到达最后一个路径。当我将最后两个路径的位置替换为开头时,FileBeat开始在此处注册所有日志,并在以后收集它们。
我查阅了有关FileBeat配置的文档,并发现了close
*选项close_option_config似乎是个好主意。但是我还没有设法弄清楚它,我不确定scan_frequency选项的建议时间是多少(目前默认为10s),什么会以最佳方式为我服务。
我试图将 close_timeout 更改为15s,将 scan_frequency更改 为2m
close_timeout: 15s
scan_frequency: 2m
我想在这里发表一些意见,我应该怎么做才能解决这个问题?我把配置放在这里有一些参考,看看是否错过了其他东西。
我的filebeat.yml :(更改之前)
filebeat:
# List of prospectors to fetch data.
prospectors:
# Each - is a prospector. Below are the prospector specific configurations
-
paths:
- D:\logs\*\path1\a_*_Pri_app.log.txt
input_type: log
document_type: type1
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
multiline.negate: true
multiline.match: after
-
paths:
- D:\logs\*\path2\b_*_Paths_app.log.txt
input_type: log
document_type: type2
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
multiline.negate: true
multiline.match: after
-
paths:
- D:\logs\*\path3\c_*_R_app.log.txt
input_type: log
document_type: path3
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
multiline.negate: true
multiline.match: after
-
paths:
- D:\logs\*\path4\d_*_d_app.log.txt
- C:\logs\*\path4\d_*_d_app.log.txt
input_type: log
document_type: path4
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
multiline.negate: true
multiline.match: after
.....与以上相同
paths:
- D:\logs\*\path27\S.Coordinator_Z.*.log*
- C:\logs\*\path27\S.Coordinator_Z*.log*
input_type: log
document_type: path27
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
multiline.negate: true
multiline.match: after
-
paths:
- D:\logs\*\path28\d_*_Tr_app.log.txt
- C:\logs\*\path28\d_*_Tr_app.log.txt
input_type: log
document_type: path28
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
multiline.negate: true
multiline.match: after
-
paths:
- D:\logs\*\R1_Output\R*\pid_*_rr_*
input_type: log
document_type: path29
multiline.pattern: '<\?xml version="1\.0" encoding="UTF-8"\?>'
multiline.negate: true
multiline.match: after
-
paths:
- D:\logs\*\R2_Output\R*\pid_*_rr_*
input_type: log
document_type: path30
multiline.pattern: '<\?xml version="1\.0" encoding="UTF-8"\?>'
multiline.negate: true
multiline.match: after
registry_file: "C:/ProgramData/filebeat/registry"
经过长时间的调查,当我尝试找到与 解决方案 相似的问题时,并在dicuss弹性论坛中尝试了运气。我设法解决了这个问题。
由于我没有在网络上看到此选项,因此将其放在此处。
当同时处理大量打开的文件时,Filebeat收集系统显然具有局限性。(一个已知的问题和弹性团队还提供了许多配置选项来帮助解决此问题,并根据您的需要打扮
ELK,例如config_options)。我设法通过再打开2个Filebeat服务来解决我的问题,该服务通过以下方式配置其探矿者(A的示例与B相同):
paths:
- D:\logs\*\pid_*_rr_*
input_type: log
document_type: A
multiline.pattern: '<\?xml version="1\.0" encoding="UTF-8"\?>'
multiline.negate: true
multiline.match: after
close_eof: true
通过这种方式,因为Filebeat相互依赖地工作,所以它们一直试图操作它们(而不是“卡在”第一个探矿者上)。
我以这种方式设法使我的收割能力加倍。
构成Elastic网站中的讨论:
讨论
我的目标:我需要收集从运行的tomcat容器到Filebeat容器的tomcat日志。 问题:我不知道如何从Tomcat容器中获取收集的日志文件。 到目前为止我尝试过的内容:我尝试创建一个docker卷并将tomcat日志添加到该卷中,并从filebeat容器访问该卷,但没有成功。 docker-containers:包含3个主子目录(Tomcat、Nginx和Postgres)。ENV文件和do
filebeat 是基于原先 logstash-forwarder 的源码改造出来的。换句话说:filebeat 就是新版的 logstash-forwarder,也会是 Elastic Stack 在 shipper 端的第一选择。 安装部署 deb: curl -L -O https://download.elastic.co/beats/filebeat/filebeat_5.0.0_amd
本文向大家介绍iOS10适配问题收集整理,包括了iOS10适配问题收集整理的使用技巧和注意事项,需要的朋友参考一下 1、TencentOpenAPI的坑 表现:启动就crash 原因:由于很久没有更新该sdk了,用的版本是2.3.1。后来想着去官网下个最新的吧,不过最新的是3.0的版本,替换原来的sdk后,有些接口和头文件定义的问题,直接编译不过。为了少踩点坑,还是选择了其他项目已经在用的2.8版
Open-Falcon数据收集,分为[绘图数据]收集和[报警数据]收集。下面介绍,如何验证两个链路的数据收集是否正常。 如何验证[绘图数据]收集是否正常 数据链路是:agent->transfer->graph->query->dashboard。graph有一个http接口可以验证agent->transfer->graph这条链路,比如graph的http端口是6071,可以这么访问验证: #
我的Ionic 5应用程序中有以下Firestore数据库结构。 书(集合) {bookID}(带有book字段的文档) 赞(子集合) {userID}(文档名称作为带有字段的用户ID) 集合中有文档,每个文档都有一个子集合。Like collection的文档名是喜欢这本书的用户ID。 我正在尝试进行查询以获取最新的,同时尝试从子集合中获取文档以检查我是否喜欢它。 我在这里做的是用每个图书ID调
问题内容: 当伊甸园空间年轻时已满,将触发次要GC。在次要GC过程中,伊甸园和一个源Survivor空间中的非自由对象将被复制到另一个目标Survivor空间。 我的问题是,如果目标“幸存者”空间已满,次要GC如何处理? 问题答案: 如果不可能执行/完成次要收集,则将执行主要/完整收集。通常使用标记扫描紧凑算法而不是复制算法来完成此操作……这是完整收集昂贵的原因之一。 但是最终(如果您继续填充堆)