日志文件转运工具Filebeat笔记|万字长文

一、概述与简介

Filebeat是一个日志文件转运工具,在服务器上以轻量级代理的形式安装客户端后,Filebeat会监控日志目录或者指定的日志文件,追踪读取这些文件(追踪文件的变化,不停的读),并将来自成百上千台机器的数据发送到elasticsearch、logstarsh、kibana或其他模块中存放(也支持Redis、Kafka等中间件输出)。

正如官方描述:“当您要面对成百上千、甚至成千上万的服务器、虚拟机和容器生成的日志时,请告别 SSH 吧。Filebeat 将为您提供一种轻量型方法,用于转发和汇总日志与文件,让简单的事情不再繁杂。”

即:Filebeat 是安装在服务器上的数据中转代理。它采集数据,并上报到Logstash或Elasticsearch等模块。【日志采集+输送展示】

日志文件转运工具Filebeat笔记|万字长文

注意:其实Filebeat是Beats家族中的一种类型。后续如果需要监控其他数据项的话,可以选择其他的Beat。(拓展数据源,Beats系列不仅仅只有日志选项)

Beats 有多种类型,可以根据实际应用需要选择合适的类型。

常用的类型有:

日志文件转运工具Filebeat笔记|万字长文

  • Packetbeat:网络数据包分析器,提供有关您的应用程序服务器之间交换的事务的信息。
  • Filebeat:从您的服务器发送日志文件。(本次日志监控选择此Beat)
  • Metricbeat:是一个服务器监视代理程序,它定期从服务器上运行的操作系统和服务收集指标。(重点关注,OS指标监控,很轻量级,可用来收集主机运行的健康数据,后期Tiops可考虑集成)
  • Winlogbeat:提供Windows事件日志。
  • Auditbeat:收集Linux审计框架数据并监视文件的完整性。
  • Heartbeat:通过主动探测监控服务的可用性。

二、FileBeat 的特性

之前说到Filebeat作为服务器上的数据中转代理。它采集数据,并上报到Logstash或Elasticsearch等,而且相比 Logstash,FileBeat 更加轻量化。

1. 汇总信息、采用“tail -f”原理 并支持搜索

启动 Filebeat 后,配置完成后,打开 Logs UI,直接在 Kibana 中观看对文件进行 tail 操作的过程。通过搜索栏按照服务、应用程序、主机、数据中心或者其他条件进行筛选,以跟踪您的全部汇总日志中的异常行为。

日志文件转运工具Filebeat笔记|万字长文

2. 性能稳健,不错过任何检测信号

在任何环境下,应用程序都有停机的可能性。 Filebeat 读取并转发日志行,如果中断,则会记住所有事件恢复联机状态时所在位置。

3. Filebeat 让事情简单化

Filebeat 内置有多种模块(auditd、Apache、NGINX、System、MySQL 等等),可针对常见格式的日志大大简化收集、解析和可视化过程,只需一条命令即可。之所以能实现这一点,是因为它将自动默认路径(因操作系统而异)与 Elasticsearch 采集节点管道的定义和 Kibana 仪表板组合在一起。不仅如此,数个 Filebeat 模块还包括预配置的 Machine Learning 任务。

4. FileBeat 不会让你的管道超负荷。

当将数据发送到 Logstash 或 Elasticsearch 时,Filebeat 使用背压敏感协议,以应对更多的数据量。如果 Logstash 正在忙于处理数据,则会告诉 Filebeat 减慢读取速度。一旦拥堵得到解决,Filebeat 就会恢复到原来的步伐并继续传输数据。

5.输送至 Elasticsearch 或 Logstash。在 Kibana 中实现可视化。

Filebeat 是 Elastic Stack 的一部分,因此能够与 Logstash、Elasticsearch 和 Kibana 无缝协作。无论您要使用 Logstash 转换或充实日志和文件,还是在 Elasticsearch 中随意处理一些数据分析,亦或在 Kibana 中构建和分享仪表板,Filebeat 都能轻松地将您的数据发送至最关键的地方。

日志文件转运工具Filebeat笔记|万字长文

三、FileBeat 的安装

(略)

四、FileBeat 的原理

1. FIlebeat 的4大组件

关于Filebeat的组成, 有4个非常重要的概念需要我们知道

  • Prospector–探测–(收取保护费的黑社会大哥)
  • Harvest–收取–(黑社会马仔小弟)
  • libeat–汇集对外输送–(黑社会社长)
  • registry–记录收取进度–(社团财务会计)

在一开始要提前在配置文件中写好日志所在的位置,Prospector就如黑社会大哥一样,如果要去收取保护费,它会负责探索哪里能收取到,在日志所在的位置探索。而Harvest就好比黑社会小弟一样,Prospector决定去哪里收取保护费后,就派小弟Harvest去收取。

每个Prospector 都有一个对应的Harvest,相当于每个大哥手下都有小弟,然后他们有一个共同的老大叫做Libeat,他是黑社会的社长,会汇总所有收集到的东西,然后把所有的东西(日志)传送给指定的地方去消费(酒吧、KTV等),这其中还有个非常重要的角色”registry“,它相当于一个会计,它会记录Harvest小弟 都收割了些啥,收割到哪里了,这样一但有问题了之后,harvest就会跑到会计哪里问:上次大哥指定的那几家的保护费,我收到哪里了? Registry 就会告诉Harvest 你收到哪里了,接下来继续收取就行了。这样就避免了保护费数据重复收集的问题!

2.FIlebeat 的工作流程

了解了Filebeat的四大组件后,我们再来看一下,他们是如何协调工作的。

2.1 首先就是inputs,在之前的Filebeat配置文件中,我们知道需要提前配置日志的收集位置。如下所示:

- type: log   # 读取数据源的类型为Log  enabled: true  paths:     -/var/log/*.log     -/var/log/tiops/**/*.log      # 即tiops平台的所有日志位置, 指定数据的输入路径为/tiops/**/*.log结尾的所有文件,注意/tiops/子目录下的日志不会被读取,孙子目录下的日志可以

2.2 接下来就是Prospector其对应的Harvest。他们一起工作来尾随文件并将事件数据发送到你指定的输出。

Prospector负责管理harvesters并找到所有的读取源。目前有几种类型:log(日志文件),stdin(标准输入),Redis,UDP和Docker,当配置日志类型时, prospector会查找驱动器上与所定义的全局路径匹配的所有文件,并为每个文件启动一个harvester。 每个prospector都在自己的Go例程中运行。本次– type: log

harvester负责读取单个文件的内容,每个文件启动一个harvester。 harvester会逐行读取每个文件,并将内容发送到输出。harvester负责打开和关闭文件,这意味着在harvesters运行时文件要保持打开状态如果在收获文件时删除或重命名文件,Filebeat将继续读取文件。这有副作用,在harvester关闭之前,磁盘上的空间被保留。默认情况下,Filebeat保持文件打开,直到达到close_inactive的设置(close_inactive默认为5分钟,即5分钟之内,没有最新的日志信息产生则关闭文件句柄)。

关闭harvester有以下情况:

  • 如果在harvester还在读取文件时文件被删除,那么文件处理程序关闭,释放基础资源。
  • 只有在scan_frequency过后,文件的采集才会重新开始。(scan_frequency参数默认为10秒,每隔10秒prospector检查目录中日志文件的变化情况)【扫描文件的频率】
  • 如果在harvester关闭的情况下移动或移除文件,则不会继续收集文件。

注1:上面说在harvesters运行时文件要保持打开状态,那Filebeat怎么保持文件状态呢?

Filebeat保存每个文件的状态,并经常刷新状态到磁盘上的注册文件(registry)。保存在安装目录的data目录下, 用于记住harvester读取的最后一个偏移量,并确保所有日志行被发送(到输出)。如果输出,比如Elasticsearch 或者 Logstash等,无法访问,那么Filebeat会跟踪已经发送的最后一行,并只要输出再次变得可用时继续读取文件。

当Filebeat运行时,会将每个文件的状态新保存在内存中。当Filebeat重新启动时,将使用注册文件中的数据重新构建状态,Filebeat将在最后一个已知位置继续每个harvester。对于每个输入,Filebeat保存它找到的每个文件的状态。因为文件可以重命名或移动,所以文件名和路径不足以标识文件。对于每个文件,Filebeat存储惟一标识符,以检测文件是否以前读取过。如果你的情况涉及每天创建大量的新文件,你可能会发现注册表文件变得太大了。

为了减小注册表文件的大小,有两个配置选项可用:clean_remove和clean_inactive。对于你不再访问且被忽略的旧文件,建议您使用clean_inactive。如果想从磁盘上删除旧文件,那么使用clean_remove选项。

注2:Filebeat如何确保至少投递一次(at-least-once)?

Filebeat保证事件将被投递到配置的输出中至少一次,并且不会丢失数据。Filebeat能够实现这种行为,因为它将每个事件的投递状态存储在注册表文件中。在定义的输出被阻塞且没有确认所有事件的情况下,Filebeat将继续尝试发送事件,直到输出确认收到事件为止。如果Filebeat在发送事件的过程中关闭了,则在关闭之前它不会等待输出确认所有事件。当Filebeat重新启动时,发送到输出(但在Filebeat关闭前未确认)的任何事件将再次发送。这确保每个事件至少被发送一次,但是你最终可能会将重复的事件发送到输出。你可以通过设置shutdown_timeout选项,将Filebeat配置为在关闭之前等待特定的时间。

( Filebeat会将每个event的传递状态存储在注册表中,在确认已经收到事件之前,会一直尝试发送事件。

与input结合起来就是,一个input负责管理harvesters,并找到所有要读取的源。

如果input类型是log,则input查找驱动器上与已定义的glob路径匹配的所有文件,并为每个文件启动一个harvester。此时每个input都在自己的Go例程中运行。

filebeat采取的是多个线程同时去读多个文件,每个文件读到数据会被封装为一个event,event经过一系列的processors处理,最终会放在一个队列,这个队列(pipeline)在发送到输出。

日志文件转运工具Filebeat笔记|万字长文

总结:当开启Filebeat程序的时候,它会启动一个或多个探测器(prospectors)去检测指定input的日志目录或文件,由于类型是log文件,则input查找驱动器上与已定义的golang glob的Paths路径匹配的所有文件,对于探测器找出的每一个日志文件,filebeat启动收割进程(harvester),此时每个input都在自己的Go例程中运行。每一个收割进程读取一个日志文件的新内容时,filebeat采取的是多个线程同时去读多个文件,每个文件读到数据会被封装为一个event,event经过一系列的processors处理,最终会放在一个队列,这个队列(pipeline)在发送到输出。

3.FIlebeat 的模块

 [root@192-168-108-22modules.d]# pwd     /etc/filebeat/modules.d  [root@192-168-108-22 modules.d]# ll        #支持的模块类型total 84-rw-r--r-- 1 root root 475 Apr 6 06:11 apache.yml.disabled-rw-r--r-- 1 root root 280 Apr 6 06:11 auditd.yml.disabled-rw-r--r-- 1 root root 1369 Apr 6 06:11 elasticsearch.yml.disabled-rw-r--r-- 1 root root 376 Apr 6 06:11 haproxy.yml.disabled-rw-r--r-- 1 root root 651 Apr 6 06:11 icinga.yml.disabled-rw-r--r-- 1 root root 470 Apr 6 06:11 iis.yml.disabled-rw-r--r-- 1 root root 366 Apr 6 06:11 iptables.yml.disabled-rw-r--r-- 1 root root 499 Apr 6 06:11 kafka.yml.disabled-rw-r--r-- 1 root root 293 Apr 6 06:11 kibana.yml.disabled-rw-r--r-- 1 root root 672 Apr 6 06:11 logstash.yml.disabled-rw-r--r-- 1 root root 296 Apr 6 06:11 mongodb.yml.disabled-rw-r--r-- 1 root root 519 Apr 19 17:35 mysql.yml.disabled-rw-r--r-- 1 root root 672 Apr 6 06:11 nginx.yml.disabled-rw-r--r-- 1 root root 495 Apr 6 06:11 osquery.yml.disabled-rw-r--r-- 1 root root 305 Apr 6 06:11 postgresql.yml.disabled-rw-r--r-- 1 root root 566 Apr 6 06:11 redis.yml.disabled-rw-r--r-- 1 root root 266 Apr 6 06:11 santa.yml.disabled-rw-r--r-- 1 root root 299 Apr 6 06:11 suricata.yml.disabled-rw-r--r-- 1 root root 679 May 20 16:09 system.yml.disabled-rw-r--r-- 1 root root 302 Apr 6 06:11 traefik.yml.disabled-rw-r--r-- 1 root root 426 Apr 6 06:11 zeek.yml.disabled

Filebeat模块简化了公共日志格式的收集、解析和可视化。一个典型的模块(例如,对于Nginx日志)是由一个或多个fileset组成的(以Nginx为例,access 和error)。

一个fileset包含以下内容:

  • Filebeat 输入配置,其中包含要默认的查找或者日志文件路径。这些默认路径取决于操作系统。Filebeat配置还负责在需要的时候拼接多行事件。
  • Elasticsearch Ingest Node 管道定义,用于解析日志行。
  • 字段定义,用于为每个字段在Elasticsearch中配置正确类型。它们还包含每个字段的简短描述。
  • 简单的Kibana dashboards,用于可视化日志文件。

Filebeat会根据你的环境自动调整这些配置,并将它们加载到相应的Elasticstack 组件中。

Filebeat提供了一组预先构建的模块,你可以使用这些模块快速实现并部署一个日志监控解决方案,包括样例指示板和数据可视化。

这些模块支持常见的日志格式,如Nginx、Apache2和MySQL,可以通过一个简单的命令来运行。

启动:

启用你想运行的模块。例如:

./filebeat modules enablesystem nginx mysql./filebeat modules disable systemmysqlfilebeat 已经yum安装完成。可以作为全局命令[root@192-168-108-22 ~]# filebeatmodules disable system mysqlDisabled systemDisabled mysql[root@192-168-108-22 ~]# filebeat modules listEnabled: Disabled:apacheauditdelasticsearchhaproxyicingaiisiptableskafkakibanalogstashmongodbmysqlnginxosquerypostgresqlredissantasuricatasystemtraefikzeek

启用模块完成后需要设置初始环境:./filebeat setup -e

然后运行Filebeat: ./filebeat -e

最后就可以在Kibana中查看你的数据。

关于模块包含很多种类型以及用法,这里就不一一描述,可以按需求去详细了解配置。

五、FileBeat 的配置项(摘自网络)

为了配置Filebeat,你可以编辑配置文件 filebeat.yml,位于/etc/filebeat目录下。

配置inputs为了手动配置Filebeat(代替用模块),你可以在filebeat.yml中的filebeat.inputs区域下指定一个inputs列表。

列表时一个YMAL数组,并且你可以指定多个inputs,相同input类型也可以指定多个。例如:

- type: log  paths:    # 从日志文件读取行,为了配置这种input,需要指定一个paths列表,列表中的每一项必须能够定位并抓取到日志行。    - /var/log/system.log    - /var/log/wifi.log- type: log  paths:    - "/var/log/apache2/*"  fields: apache: true

你还可以应用设置其它额外的配置项(比如,fields, include_lines, exclude_lines,multiline等等)来从这些文件中读取行。你设置的这些配置对所有这种类型的input在获取日志行的时候都生效。

配置项

paths(重要)例如:/var/log/*/*.log 将会抓取/var/log子目录目录下所有.log文件。它不会从/var/log本身目录下的日志文件。如果你应用recursive_glob设置的话,它将递归地抓取所有子目录下的所有.log文件。

recursive_glob.enabled

允许将**扩展为递归glob模式。启用这个特性后,每个路径中最右边的**被扩展为固定数量的glob模式。例如:/foo/**扩展到/foo,/foo/*,/foo/**,等等。如果启用,它将单个**扩展为8级深度*模式。这个特性默认是启用的,设置recursive_glob.enabled为false可以禁用它。

encoding(重要)读取的文件的编码,下面是一些W3C推荐的简单的编码:

  • plain, latin1, utf-8, utf-16be-bom, utf-16be, utf-16le, big5, gb18030, gbk, hz-gb-2312
  • euc-kr, euc-jp, iso-2022-jp, shift-jis, 等等

plain编码是特殊的,因为它不校验或者转换任何输入。

exclude_lines(重要)一组正则表达式,用于匹配你想要排除的行。Filebeat会删除(PS:我觉得用“丢弃”更合适)这组正则表达式匹配的行。默认情况下,没有行被删除。空行被忽略。

如果指定了multiline,那么在用exclude_lines过滤之前会将每个多行消息合并成一个单行。(PS:也就是说,多行合并成单行后再支持排除行的过滤)

下面的例子配置Filebeat删除以DBG开头的行:

filebeat.inputs: - type: log ... exclude_lines: ['^DBG']

include_lines一组正则表达式,用于匹配你想要包含的行。Filebeat只会导出那些匹配这组正则表达式的行。默认情况下,所有的行都会被导出。空行被忽略。

如果指定了multipline设置,每个多行消息先被合并成单行以后再执行include_lines过滤。下面是一个例子,配置Filebeat导出以ERR或者WARN开头的行:

 - type: log ... include_lines: ['^ERR', '^WARN'](如果 include_lines 和 exclude_lines 都被定义了,那么Filebeat先执行 include_lines 后执行 exclude_lines,而与这两个选项被定义的顺序没有关系。include_lines 总是在 exclude_lines选项前面执行,即使在配置文件中 exclude_lines 出现在 include_lines的前面。)

下面的例子导出那些除了以DGB开头的所有包含sometext的行:

- type: log   ...   include_lines: ['sometext']   exclude_lines: ['^DBG']

harvester_buffer_size(重要)当抓取一个文件时每个harvester使用的buffer的字节数。默认是16384。

max_bytes单个日志消息允许的最大字节数。超过max_bytes的字节将被丢弃且不会被发送。对于多行日志消息来说这个设置是很有用的,因为它们往往很大。默认是10MB(10485760)。

json这些选项使得Filebeat将日志作为JSON消息来解析。例如:

json.keys_under_root: true json.add_error_key: true json.message_key: log

为了启用JSON解析模式,你必须至少指定下列设置项中的一个:

  keys_under_root

默认情况下,解码后的JSON被放置在一个以”json”为key的输出文档中。如果你启用这个设置,那么这个key在文档中被复制为顶级。默认是false。

  overwrite_keys

如果keys_under_root被启用,那么在key冲突的情况下,解码后的JSON对象将覆盖Filebeat正常的字段

  add_error_key

如果启用,则当JSON反编排出现错误的时候Filebeat添加 “error.message” 和”error.type: json”两个key,或者当没有使用message_key的时候。

  message_key

一个可选的配置,用于在应用行过滤和多行设置的时候指定一个JSON key。指定的这个key必须在JSON对象中是顶级的,而且其关联的值必须是一个字符串,否则没有过滤或者多行聚集发送。

  ignore_decoding_error

一个可选的配置,用于指定是否JSON解码错误应该被记录到日志中。如果设为true,错误将被记录。默认是false。

multiline(重要)用于控制Filebeat如何扩多行处理日志消息,修改filebeat配置文件/etc/filebeat/filebeat.yml 在原来基础上面添加多行合并配置

1 2 3 4 multiline: pattern: ‘^[‘ negate: true match: after
  • pattern:正则表达式,匹配日志格式
  • negate:默认为false,暗示匹配pattern的行归并到上一行;true暗示不匹配pattern的行归并到上一行
  • match:after暗示归并到上一行的末端,before暗示归并到上一行的行首

exclude_files一组正则表达式,用于匹配你想要忽略的文件。默认没有文件被排除。

下面是一个例子,忽略.gz的文件

- type: log  ...  exclude_files: ['.gz

ignore_older如果启用,那么Filebeat会忽略在指定的时间跨度之前被修改的文件。如果你想要保留日志文件一个较长的时间,那么配置ignore_older是很有用的。例如,如果你想要开始Filebeat,但是你只想发送最近一周最新的文件,这个情况下你可以配置这个选项。

你可以用时间字符串,比如2h(2小时),5m(5分钟)。默认是0,意思是禁用这个设置。你必须设置ignore_older比close_inactive更大。

close_*close_*配置项用于在一个确定的条件或者时间点之后关闭harvester。关闭harvester意味着关闭文件处理器。如果在harvester关闭以后文件被更新,那么在scan_frequency结束后改文件将再次被拾起。然而,当harvester关闭的时候如果文件被删除或者被移动,那么Filebeat将不会被再次拾起,并且这个harvester还没有读取的数据将会丢失。

close_inactive(重要)当启用此选项时,如果文件在指定的持续时间内未被获取,则Filebeat将关闭文件句柄。当harvester读取最后一行日志时,指定周期的计数器就开始工作了。它不基于文件的修改时间。如果关闭的文件再次更改,则会启动一个新的harvester,并且在scan_frequency结束后,将获得最新的更改。

推荐给close_inactive设置一个比你的日志文件更新的频率更大一点儿的值。例如,如果你的日志文件每隔几秒就会更新,你可以设置close_inactive为1m。如果日志文件的更新速率不固定,那么可以用多个配置。

将close_inactive设置为更低的值意味着文件句柄可以更早关闭。然而,这样做的副作用是,如果harvester关闭了,新的日志行不会实时发送。

关闭文件的时间戳不依赖于文件的修改时间。代替的,Filebeat用一个内部时间戳来反映最后一次读取文件的时间。例如,如果close_inactive被设置为5分钟,那么在harvester读取文件的最后一行以后,这个5分钟的倒计时就开始了。

你可以用时间字符串,比如2h(2小时),5m(5分钟)。默认是5m。

close_renamed当启用此选项时,Filebeat会在重命名文件时关闭文件处理器。默认情况下,harvester保持打开状态并继续读取文件,因为文件处理器不依赖于文件名。如果启用了close_rename选项,并且重命名或者移动的文件不再匹配文件模式的话,那么文件将不会再次被选中。Filebeat将无法完成文件的读取。

close_removed当启用此选项时,Filebeat会在删除文件时关闭harvester。通常,一个文件只有在它在由close_inactive指定的期间内不活跃的情况下才会被删除。但是,如果一个文件被提前删除,并且你不启用close_removed,则Filebeat将保持文件打开,以确保harvester已经完成。如果由于文件过早地从磁盘中删除而导致文件不能完全读取,请禁用此选项。

close_timeout当启用此选项是,Filebeat会给每个harvester一个预定义的生命时间。无论读到文件的什么位置,只要close_timeout周期到了以后就会停止读取。当你想要在文件上只花费预定义的时间时,这个选项对旧的日志文件很有用。尽管在close_timeout时间以后文件就关闭了,但如果文件仍然在更新,则Filebeat将根据已定义的scan_frequency再次启动一个新的harvester。这个harvester的close_timeout将再次启动,为超时倒计时。

scan_frequency(重要)Filebeat多久检查一次指定路径下的新文件(PS:检查的频率)例如,如果你指定的路径是 /var/log/* ,那么会以指定的scan_frequency频率去扫描目录下的文件(PS:周期性扫描)指定1秒钟扫描一次目录,这还不是很频繁。不建议设置为小于1秒。

如果你需要近实时的发送日志行的话,不要设置scan_frequency为一个很低的值,而应该调整close_inactive以至于文件处理器保持打开状态,并不断地轮询你的文件。

默认是10秒。

scan.sort如果你指定了一个非空的值,那么你可以决定用scan.order的升序或者降序。可能的值是 modtime 和 filename。为了按文件修改时间排序,用modtime,否则用 filename。默认此选项是禁用的。

scan.order可能的值是 asc 或者 desc。默认是asc。更多配置请查看https://www.elastic.co/guide/en/beats/filebeat/current/configuration-filebeat-options.html这里再重点说一下 ignore_older ,close_inactive , scan_frequency 这三个配置项

  • ignore_older:它是设置一个时间范围(跨度),不在这个跨度范围之内的文件更新都不管
  • scan_frequency:它设置的是扫描文件的频率,看看文件是否更新
  • close_inactive:它设置的是文件如果多久没更新的话就关闭文件句柄,它是有一个倒计时,如果在倒计时期间,文件没有任何变化,则当倒计时结束的时候关闭文件句柄。不建议设置为小于1秒。

如果文件句柄关了以后,文件又被更新,那么在下一个扫描周期结束的时候变化发现这个改变,于是会再次打开这个文件读取日志行,前面我们也提到过,每个文件上一次读到什么位置(偏移量)都记录在registry文件中。)

配置output

配置Elasticsearch output当你指定Elasticsearch作为output时,Filebeat通过Elasticsearch提供的HTTP API向其发送数据。例如:

output.elasticsearch: hosts: ["https://localhost:9200"]index: "filebeat-%{[beat.version]}-%{+yyyy.MM.dd}"ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]ssl.certificate: "/etc/pki/client/cert.pem" ssl.key:"/etc/pki/client/cert.key"

为了启用SSL,只需要在hosts下的所有URL添加https即可

output.elasticsearch: hosts: ["https://localhost:9200"]username: "filebeat_internal" password: "YOUR_PASSWORD"

如果Elasticsearch节点是用IP:PORT的形式定义的,那么添加protocol:https。

output.elasticsearch: hosts: ["localhost"] protocol:"https" username: "{beatname_lc}_internal" password:"{pwd}"

配置项

enabled

启用或禁用该输出。默认true。

hosts

Elasticsearch节点列表。事件以循环顺序发送到这些节点。如果一个节点变得不可访问,那么自动发送到下一个节点。每个节点可以是URL形式,也可以是IP:PORT形式。如果端口没有指定,用9200。

output.elasticsearch: hosts: ["10.45.3.2:9220","10.45.3.1:9230"] protocol: https path: /elasticsearch

username用于认证的用户名

password用户认证的密码

protocol可选值是:http 或者 https。默认是http。

pathHTTP API调用前的HTTP路径前缀。这对于Elasticsearch监听HTTP反向代理的情况很有用。

headers将自定义HTTP头添加到Elasticsearch输出的每个请求。

index索引名字。(PS:意思是要发到哪个索引中去)。默认是”filebeat-%{[beat.version]}-%{+yyyy.MM.dd}”(例如,”filebeat-6.3.2-2017.04.26″)。如果你想改变这个设置,你需要配置 setup.template.name 和 setup.template.pattern 选项。如果你用内置的Kibanadashboards,你也需要设置setup.dashboards.index选项。

indices索引选择器规则数组,支持条件、基于格式字符串的字段访问和名称映射。如果索引缺失或没有匹配规则,将使用index字段。例如:

output.elasticsearch: hosts: ["https://localhost:9200"] index:"logs-%{[beat.version]}-%{+yyyy.MM.dd}" indices: - index:"critical-%{[beat.version]}-%{+yyyy.MM.dd}" when.contains: message:"CRITICAL" - index:"error-%{[beat.version]}-%{+yyyy.MM.dd}" when.contains: message:"ERR"timeout

请求超时时间。默认90秒。

配置Logstash output

output.logstash: hosts: ["127.0.0.1:5044"]

上面是配置Filebeat输出到Logstash,那么Logstash本身也有配置,例如:

input { beats { port => 5044 } }output { elasticsearch { hosts => ["https://localhost:9200"] index =>"%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}" } } 

配置Kafka output

output.kafka:# initial brokers for reading cluster metadatahosts: ["kafka1:9092", "kafka2:9092","kafka3:9092"]# message topic selection + partitioningtopic: '%{[fields.log_topic]}'partition.round_robin:reachable_only: falserequired_acks: 1compression: gzipmax_message_bytes: 1000000

负载均衡为了启用负载均衡,当你配置输出的时候你需要指定loadbalance:true

output.logstash: hosts:["localhost:5044", "localhost:5045"] loadbalance: true

六、FileBeat 的常见问题

1. Too many open file handler?(太多打开的文件句柄)Filebeat保持文件处理器打开,以防它到达文件的末尾,以便它可以实时读取新的日志行。如果Filebeat正在收集大量文件,那么打开文件的数量可能成为一个问题。在大多数环境中,主动更新的文件数量很少。应该相应地设置close_inactive配置选项,以关闭不再活动的文件。

2. Filebeat没有从一个文件收集行为了解决这个问题:

  • 确保路径配置正确
  • 检查这个文件是不是比指定的ignore_older值更旧
  • 确保Filebeat能够发送时间到配置的输出。以debug模式运行Filebeat来检查是否可以成功发送事件:
  • ./filebeat -c config.yml -e -d “*”

3. Filebeat占用了太多CPU资源Filebeat可能配置扫描文件太过频繁。检查filebeat.yml中的scan_frequency设置。

说明:本文为Filebeat学习笔记,部分资料来自于网上。