我们在三台主机上的日志处理方面遇到了重大挑战。这些主机中的每一个都运行九个服务，每个日志文件每分钟生成 30,000 到 72,000 个事件。服务器规格包括 16 核 CPU 和 62 GB 内存。
我们观察到日志处理有大约 20 分钟的延迟。此外，每小时轮换并重命名日志文件后，Filebeat 不会从之前的文件中读取数据。这会导致最后 10 到 20 分钟的日志数据丢失。
相比之下，我们的其他九台主机（一个应用程序中有3 + 9台主机。其他应用程序的数据收集也效果很好），配置了三到五个日志文件，可以有效地处理数据，没有任何问题。
为了诊断问题，我执行了命令 GET _cat/thread_pool/bulk?v，该命令没有显示任何被拒绝的请求，表明批量线程池正在按预期运行。
如何解决这些问题并改进受影响主机上的日志处理？
A] Filebeat/ELK 版本：8.3.1（12 节点白金许可证）
B] 每分钟事件数。
Service1 - 60k events/min
Service2 - 15k events/min
Service3 - 500 events/min
Service4 - 17k events/min
Service5 - 15.5k events/min
Service6 - 40k events/min
Service7 - 100 events/min
Service8 - 78k events/min
Service9 - 160k events/min
C] 以下是文件beat.yml
filebeat.config.modules:
enabled: true
path: ${path.config}/modules.d/*.yml
reload.enabled: true
reload.period: 10s
queue.mem:
events: 20000
#events: 20000 (tried 8192 as well)
flush.min_events: 2048
filebeat.registry.flush: 5s
output.logstash:
hosts: [ "10.40.7.40:5045", "10.40.7.41:5044", "10.40.7.42:5045", "10.40.7.40:5044", "10.40.7.41:5045", "10.40.7.42:5044" ]
loadbalance: true
workers: 12
#workers: 8 ( tried 8 as well)
bulk_max_size: 20000
#bulk_max_size: 15000 (tried this as well)
flush_interval: 1s
#flush_interval: 500ms (tried this as well)
D]modules.d/app.yml
注意：每隔一小时，文件就会重命名为“app1-2024-10-16-19-1.log”，其中“19”是前一小时。
- module: app-1
microservice:
enabled: true
var.paths:
- "/path/to/app1.log"
input:
scan_frequency: 3s
close_renamed: false
close_inactive: 30m
ignore_older: 24h
clean_inactive: 48h
close_timeout: 2h
E] 我有 3 个 Logstash 主机，有 12 核 cpu 和 23 GB 内存。我已将 pipeline.batch_size 设置为 2048
F] 示例应用程序日志 - 响应字符串（它打印请求/响应以及事务之间的内容，但日志格式相同）
2024-06-13 17:50:20:815 [app4] [应用程序服务] [信息] [https-jsse-nio-9443-exec-38] [c7dd483c-2461-4ee5-8d67-bd5076129460] [858f223f1ffe4b8c ] [858f223f1ffe4b8c] [] [ResponseLogFilter:100] - TraceId= [c7dd483c-d5076129460] 时间戳= [1718281219341] ClientId= [abcd] AuthMethod= [JOSE] RequestMethod= [POST] ContentType= [application/jose] AcceptType= [application/jose] RequestUri= [/abcd/efg/create] RequestIp= [0.0.0.0] ResponseBody= [{"error_type":"api_validation_error","error_code":"T3","message":"测试测试" ,"status":422}] KeyId= [bdbhsbsa-bsbbsbwh8QaCek] 算法= [null] ServerAuthorization= [null] 状态= [422] ResponseDate= [2024-06-13T17:50:20+0530] ErrorType= [api_validation_error]错误代码= [T3] 错误消息= [测试测试] 延迟= [27]
G] Filebeat 日志
{"log.level":"info","@timestamp":"2024-10-16T20:23:08.455+0530","log.logger":"监控","log.origin":{"文件.name":"log/log.go","file.line":185},"message":"过去 30 秒内的非零指标","service.name":"filebeat","monitoring": {“metrics”：{“beat”：{“cgroup”：{“cpuacct”：{“total”：{“ns”：299461410874}}，“内存”：{“mem”：{“usage”：{“字节":13615104}}}},"cpu":{"system":{"ticks":1140,"time":{"ms":360}},"total":{"ticks":20510," time":{"ms":7210},"value":0},"user":{"ticks":19370,"time":{"ms":6850}}},"info":{"ephemeral_id ":"9dadf2d8-7ad2-43c5-9726-5e33fbb455c8","正常运行时间":{"ms":90114},"版本":"8.3.1"},"memstats":{"gc_next":215038376,"memory_alloc “：157361792，“memory_sys”：4194304，“memory_total”：3315695936，“rss”：335130624}，“运行时”：{“goroutines”：116}}，“filebeat”：{“events”：{“active”： -4，“添加”：110716，“完成”：110720}，“收割机”：{“open_files”：0，“运行”：0}}，“libbeat”：{“配置”：{“模块”：{ “运行”：9}，“扫描”：3}，“输出”：{“事件”：{“确认”：102528，“活动”：12288，“批次”：55，“总计”：110720}，“读":{"字节":336},"写":{"字节":22499231}},"管道":{"客户端":9,"事件":{"活动":20025,"已发布": 110720,"total":110716},"queue":{"acked":110720}}},"registrar":{"states":{"current":0}},"system":{"load": {"1":13.72,"15":15.51,"5":14.25,"norm":{"1":0.8575,"15":0.9694,"5":0.8906}}}},"ecs.version “：”1.6.0“}}
您有 2 个问题：
您已经创建了一个自定义模块。为了全面调查这个问题，我们需要访问您的
microservice我要假设是，在模块的config.yml中，您使用的是自定义的
file_identityinode/path/to/app1.log所以很可能您需要更改一些内容
config/microservice.yml调查资源：
再次进行一些假设，听起来您不知道哪个组件导致了延迟。 我可以建议的是：
这应该可以帮助您识别引入问题的组件。