持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第5天，点击查看活动详情
启动
启动命令示例如下:
docker run --log-opt max-size=100m --user root --net host --name filebeat -v $PWD/filebeat/data:/usr/share/filebeat/data -v $PWD/filebeat/logs:/usr/share/filebeat/logs -v /logs:/usr/share/filebeat/logdata -e ES_HOSTS="es-1.dx.corp:9200,es-2.dx.corp:9200" -e LOG_PATH="/usr/share/filebeat/logdata/request_details.log" -d filebeat:5.4.3
注意: 需要将监控的日志目录映射到filebeat容器中, 同时配置一个环境变量LOG_PATH用于指定在filebeat容器中的路径, ES_HOSTS 指定es地址, 集群逗号分隔, 注意端口号是http端口
如果默认配置不满足需求, 可以将配置文件重新映射到容器中, 容器内路径是/usr/share/filebeat/filebeat.yml
配置与使用说明
close_inactive
该参数指定当被监控的文件多长时间没有变化后就关闭文件句柄(file handle)。官方建议将这个参数设置为一个比文件最大更新间隔大的值。比如文件最长5s更新一次，那就设置成1min。默认值为5min.
scan_frequency
该参数指定Filebeat搜索新文件的频率(时间间隔)。当发现新的文件被创建时， Filebeat会为它再启动一个 harvester 进行监控。默认为10s。
clean_inactive: 72h
这个配置项也应该配置上，默认值是0表示不清理，不清理的意思是采集过的文件描述在registry文件里永不清理，在运行一段时间后，registry会变大，可能会带来问题。
ignore_older: 70h
设置了clean_inactive后就需要设置ignore_older，且要保证ignore_older < clean_inactive
当logback完成日志切割后(即重命名)，此时老的harvester仍然在监控重命名后的日志文件，但是由于该文件不会再更新，因此会在close_inactive时间后关闭这个文件的 harvester。当scan_frequency时间过后，Filebeat会发现目录中出现了新文件，于是为该文件启动 harvester 进行监控。这样就保证了切割日志时也能不丢不重的传输数据。对于同一个文件经过较长时间后再更新, 也会在scan_frequency时间过后重新启动harvester
# harvester关闭日志
2020/08/20 06:32:18.206200 log.go:116: INFO File is inactive: /usr/share/filebeat/logdata/request_details.log. Closing because close_inactive of 5m0s reached.
# 启动 harvester日志
2020/08/20 06:27:43.197758 log.go:91: INFO Harvester started for file: /usr/share/filebeat/logdata/request_details.log
filebeat的data/registry文件中存放的是被采集的所有日志的相关信息。
linux中registry中一条日志记录的内容如下
[{ "source": "/usr/share/filebeat/logdata/request_details.log", "offset": 29973, "FileStateOS": { "inode": 5784066, "device": 2049 }, "timestamp": "2020-08-20T14:20:28.328896978+08:00", "ttl": 259200000000000}, { "source": "/usr/share/filebeat/logdata/request_details.log", "offset": 1430, "FileStateOS": { "inode": 5784064, "device": 2049 }, "timestamp": "2020-08-20T14:27:13.644183981+08:00", "ttl": 259200000000000}, { "source": "/usr/share/filebeat/logdata/request_details.log", "offset": 1427, "FileStateOS": { "inode": 5784049, "device": 2049 }, "timestamp": "2020-08-20T14:27:44.14364326+08:00", "ttl": 259200000000000}]
这条记录中的各个字段的意义分别为
source 日志文件完整路径 offset 已经采集的日志的字节数;已经采集到日志的哪个字节位置 filestateos 操作系统相关 inode 日志文件的inode号 // linux, ls -i device 日志所在磁盘的磁盘编号 timestamp 日志最后一次发生变化的时间戳 ttl 采集失效时间。-1表示只要日志存在，就一直采集该日志 复制代码
[dx@cdh3 logs]$ ls -il request_details.*
5772009 -rw-r--r-- 1 root root 0 Mar 17 11:06 request_details.2020-03-17.0.log
5784066 -rw-r--r-- 1 root root 29973 Aug 20 14:15 request_details.2020-08-20.0.log
5784064 -rw-r--r-- 1 root root 1430 Aug 20 14:27 request_details.2020-08-20.1.log
5784049 -rw-r--r-- 1 root root 1427 Aug 20 14:27 request_details.log
可以看到 5784066, 5784064, 5784049 这三个文件对应到registry文件中的offset都等于文件大小, 表示都采集完成了
