- 微信
- 微博
  
  分享文章到微博
- 复制链接
  
  复制链接到剪贴板

filebeat

yd_224301282 发表于 2023/08/11 21:12:05 2023/08/11

【摘要】 ELFKfilebeat机制filebeat采集功能主要有inputs和harvester组成harvesterharvester负责读取文件上的内容，当发现所以监控的文件大小发生变化，就会按行的形式，将内容读取出来。每一个文件都会对应一个harvester，文件的打开和关闭都是harvester在操作，所以一旦harvester打开一个文件，在没有关闭这个文件之前，文件描述符会一直跟着ha...

ELFK

filebeat机制

filebeat采集功能主要有inputs和harvester组成

harvester

harvester负责读取文件上的内容，当发现所以监控的文件大小发生变化，就会按行的形式，将内容读取出来。每一个文件都会对应一个harvester，文件的打开和关闭都是harvester在操作，所以一旦harvester打开一个文件，在没有关闭这个文件之前，文件描述符会一直跟着harvester，因为文件处理程序不依赖于文件名，即使这个文件被重命名或者删除。harvester打开文件的磁盘空间也不会被释放。所以何时关闭harvester就非常重要
- close_inactive
  - 配置在多久之后文件没有更新，则关闭harvester。默认5m。可以使用close_inactive: 2h 自定义超时时间
  - 如果在关闭harvester之后，在后续扫描文件的过程中再次发现文件变化，则会再次开启harvester，不过如果关闭harvester之后，将文件删除或重命名，原有数据将丢失，无法重新拾取。
  - 不建议设置的过于短的时间，一般要大于日志的刷新频率一些。如果设置的过低，一旦触发harvester关闭，则新日志出现，即使harvester会恢复，但实时性将无法保证。
- close_rename
  - 启动该配置则实现文件在打开之后如果重命名或者移动（注意是移动不是删除），则触发harvester关闭，不再获取该文件内容
- close_removed
  - 跟上面配置差不多，如果启动，在文件删除之后，则会关闭harvester。默认开启，如果禁用，则必须同时禁用clean_removed
- close_eof
  - 文件读取之后即关闭harvester，适用于一次写入的场景，不适合实时写入日志场景
- close_timeout
  - 当选项启动时，filebeat会给每个harvester设置预定义时间，不管这个文件是否被读取，达到设定时间后，将被关闭
注册表操作
- clean_inactived
  - 若在指定时间内文件内容未更新，则删除注册表中文件的状态信息
- clean_removed
  - 是否在重命名文件后，则删除注册表中文件的状态信息。默认为 true. 若文件在段时间内消息并再次出现，则将从头开始读取文件内容
- scan_frequency
  - 指定每隔多久扫描一次 path 路径中新文件的频率。默认为 10s

input

input负责管理harvester，input分为几种类型：Log，Stdin，Redis，UDP，Docker，TCP，Syslog。如果配置的是log类型，input会根据配置的path去寻找文件，并且每一个文件建立一个harvester。如果harvester关闭后，文件再次更新，harvester会被再次开启
- ```
filebeat.inputs:
- type: log
  paths:
    - /var/log/system.log
    - /var/log/wifi.log
- type: log
  paths:
    - "/var/log/apache2/*"
  fields:
    apache: true
  fields_under_root: true
```

filebeat如何确保数据不丢失和数据不重复

filebeat维护了一个registry文件在本地的磁盘，该registry文件维护了所有已经采集的日志文件的状态。每当日志数据发送至后端成功后，会返回ack事件。filebeat启动了一个独立的registry协程负责监听该事件，接收到ack事件后会将日志文件的State状态更新至registry文件中，State中的Offset表示读取到的文件偏移量，所以filebeat会保证Offset记录之前的日志数据肯定被后端的日志存储接收到。
文件被改名或移动，filebeat会根据registry文件中维护的inode和设备号来标志每个日志文件，保证文件不会被重复读取。filebeat异常重启，在每个harvester启动的时候都会读取registry文件，获取对应文件上次读取的位置继续采集，确保不会从头开始重复发送所有的日志文件。
harvester读取中的日志文件被清空，filebeat会在下一次Reader.Next方法中返回ErrFileTruncate异常，将inode标志文件的Offset置为0，结束这次harvester，重新启动新的harvester，虽然文件不变，但是registry中的Offset为0，采集会从头开始。
使用容器部署filebeat，需要将registry文件挂载到宿主机上，否则容器重启后registry文件丢失，会使filebeat从头开始重复采集日志文件，导致数据重复或丢失

filebeat检测事件策略

Filebeat使用换行符来检测事件的结束。如果是按行逐步写入到正在收集的文件中，则在最后一行之后需要换行符，否则Filebeat将不会读取该文件的最后一行

filebeat如何确保至少交付一次

Filebeat可以保证事件可以被至少一次提交，就是可以保证数据不丢失。因为Filebeat会把每个事件的传递状态全部记录到注册表中文件中。在已经被定义了输出，但是没有成功确认输出的事件，Filebeat会尝试进行重试，直到确认成功。如果在输出事件的过程中Filebeat关闭，它是不会等待输出确认返回的，重新启动之后会再次重新发送没有确认的事件，这样可以保证每一个事件都会被输出，不会丢失，但是会造成事件的重复输出。

filebeat如何避免数据重复

因为数据重复多发于Filebeat重启的过程，原因就是Filebeat关闭时并不会等已经发送但没来得及返回的事件。这部分如果输出成功，Filebeat也不知道，在Filebeat重启之后，将会重新发送这部分数据。那么我们能不能让Filebeat在关闭的时候等待所以返回结果呢？答案是可以的。
- ```
filebeat.shutdown_timeout: 5s
```
- 配置Filebeat在关闭之前等待返回的最长时间，如果在这个时间之前确认已全部返回，则直接关闭。这个配置没有默认值，需要手动添加

filebeat收集日志异常情况

日志发送过程中，没来得及回复ack事件，filebeat就挂掉了，registry文件未更新到日志的最新状态，但实际上这条日志是发送成功了的，这就导致在filebeat重启后，这条日志会被重新发送，即存在一条重复的日志数据
linux下老文件被移除，新文件马上创建，这时可能会出现registry文件中维护的inode相同的情况（ inode重用），会导致registry里记录的其实是被移除的文件State状态，这样新的文件采集却从老的文件Offset开始，从而会遗漏日志数据
日志滚动过于频繁，少于scan_frequency时间（默认10s），这就可能出现个别文件未被Filebeat的input模块扫描到，就已经滚动生成重命名为其他文件，导致日志数据丢失。（概率极低，因为一般很少有系统的日志会在几秒内频繁滚动）

https://hulining.github.io/2021/04/03/filebeat-details-and-configuration/

https://server.51cto.com/article/710561.html

https://blog.csdn.net/xiaoyu_BD/article/details/83897649

https://www.elastic.co/guide/en/beats/filebeat/current/configuration-logging.html

https://blog.csdn.net/xzk9381/article/details/109571087

filebeat采集kubelet日志

配置文件

filebeat.inputs:
- type: log
  paths:
    - /log/*.log
output.file:
  path: "/root/llogg"
  filename: log

收集的日志文件样式

{"@timestamp":"2023-08-09T08:12:32.806Z","@metadata":{"beat":"filebeat","type":"_doc","version":"7.17.12"},"log":{"offset":9614229,"file":{"path":"/log/kubelet.log"}},"message":"E0809 16:12:32.196861 1707368 cadvisor_stats_provider.go:415] \"Partial failure issuing cadvisor.ContainerInfoV2\" err=\"partial failures: [\\\"/reserved.slice/kubelet.service\\\": RecentStats: unable to find data in memory cache], [\\\"/reserved.slice/docker.service\\\": RecentStats: unable to find data in memory cache]\"","input":{"type":"log"},"ecs":{"version":"1.12.0"},"host":{"name":"filebeat-86d4cdf98b-sgr7g"},"agent":{"ephemeral_id":"fb65bc4b-4e49-45a6-95c0-7ca965cd92e5","id":"f6b67625-4ed3-47c5-81a2-e1abcd5b0238","name":"filebeat-86d4cdf98b-sgr7g","type":"filebeat","version":"7.17.12","hostname":"filebeat-86d4cdf98b-sgr7g"}}
{"@timestamp":"2023-08-09T08:12:32.806Z","@metadata":{"beat":"filebeat","type":"_doc","version":"7.17.12"},"host":{"name":"filebeat-86d4cdf98b-sgr7g"},"log":{"offset":9614542,"file":{"path":"/log/kubelet.log"}},"message":"E0809 16:12:32.215087 1707368 summary_sys_containers.go:47] \"Failed to get system container stats\" err=\"failed to get cgroup stats for \\\"/reserved.slice/kubelet.service\\\": failed to get container info for \\\"/reserved.slice/kubelet.service\\\": partial failures: [\\\"/reserved.slice/kubelet.service\\\": RecentStats: unable to find data in memory cache]\" containerName=\"/reserved.slice/kubelet.service\"","input":{"type":"log"},"agent":{"type":"filebeat","version":"7.17.12","hostname":"filebeat-86d4cdf98b-sgr7g","ephemeral_id":"fb65bc4b-4e49-45a6-95c0-7ca965cd92e5","id":"f6b67625-4ed3-47c5-81a2-e1abcd5b0238","name":"filebeat-86d4cdf98b-sgr7g"},"ecs":{"version":"1.12.0"}}
{"@timestamp":"2023-08-09T08:12:32.806Z","@metadata":{"beat":"filebeat","type":"_doc","version":"7.17.12"},"host":{"name":"filebeat-86d4cdf98b-sgr7g"},"agent":{"id":"f6b67625-4ed3-47c5-81a2-e1abcd5b0238","name":"filebeat-86d4cdf98b-sgr7g","type":"filebeat","version":"7.17.12","hostname":"filebeat-86d4cdf98b-sgr7g","ephemeral_id":"fb65bc4b-4e49-45a6-95c0-7ca965cd92e5"},"ecs":{"version":"1.12.0"},"log":{"offset":9614939,"file":{"path":"/log/kubelet.log"}},"message":"E0809 16:12:32.215141 1707368 summary_sys_containers.go:47] \"Failed to get system container stats\" err=\"failed to get cgroup stats for \\\"/reserved.slice/docker.service\\\": failed to get container info for \\\"/reserved.slice/docker.service\\\": partial failures: [\\\"/reserved.slice/docker.service\\\": RecentStats: unable to find data in memory cache]\" containerName=\"/reserved.slice/docker.service\"","input":{"type":"log"}}

filebeat处理多行日志

主要是针对打印的堆栈信息
- multiline.pattern：希望匹配到的结果（正则表达式）
  multiline.negate：值为 true 或 false。使用 false 代表匹配到的行合并到上一行；使用 true 代表不匹配的行合并到上一行
  multiline.match：值为 after 或 before。after 代表合并到上一行的末尾；before 代表合并到下一行的开头
  multiline.max_lines：合并的最大行数，默认 500
  multiline.timeout：一次合并事件的超时时间，默认为 5s，防止合并消耗太多时间导致 filebeat 进程卡死

filebeat问题

https://xiwan.github.io/post/filebeat踩坑inode/

path配置

https://blog.51cto.com/ghl1024/5340920

logstash

https://www.cnblogs.com/crazymagic/articles/14512958.html

遇到的问题

https://blog.csdn.net/qq_43470725/article/details/120214322

安装jdk

https://www.cnblogs.com/Dr-wei/p/13339957.html

grok语法借鉴

https://www.cnblogs.com/even160941/p/16326986.html