『壹』 ELK应用之Filebeat
Filebeat是本地文件的日志数据采集器，可监控日志目录或特定日志文件（tail file），并将它们转发给Elasticsearch或Logstatsh进行索引、kafka等。带有内部模块（auditd，Apache，Nginx，System和MySQL），可通过一个指定命令来简化通用日志格式的收集，解析和可视化。 官方网址: https://www.elastic.co/guide/en/beats/filebeat/current/index.html Filebeat涉及两个组件：查找器prospector和采集器harvester，来读取文件(tail file)并将事件数据发送到指定的输出。 启动Filebeat时，它会启动一个或多个查找器，查看你为日志文件指定的本地路径。对于prospector所在的每个日志文件，prospector启动harvester。每个harvester都会为新内容读取单个日志文件，并将新日志数据发送到libbeat，后者将聚合事件并将聚合数据发送到你为Filebeat配置的输出。 当发送数据到Logstash或Elasticsearch时，Filebeat使用一个反压力敏感(backpressure-sensitive)的协议来解释高负荷的数据量。当Logstash数据处理繁忙时，Filebeat放慢它的读取速度。一旦压力解除，Filebeat将恢复到原来的速度，继续传输数据。 Harvester负责读取单个文件的内容。读取每个文件，并将内容发送到the output，每个文件启动一个harvester, harvester负责打开和关闭文件，这意味着在运行时文件描述符保持打开状态。 如果文件在读取时被删除或重命名，Filebeat将继续读取文件。这有副作用，即在harvester关闭之前，磁盘上的空间被保留。默认情况下，Filebeat将文件保持打开状态，直到达到close_inactive状态 关闭harvester会产生以下结果： 1）如果在harvester仍在读取文件时文件被删除，则关闭文件句柄，释放底层资源。 2）文件的采集只会在scan_frequency过后重新开始。 3）如果在harvester关闭的情况下移动或移除文件，则不会继续处理文件。 要控制收割机何时关闭，请使用close_ *配置选项 Prospector负责管理harvester并找到所有要读取的文件来源。如果输入类型为日志，则查找器将查找路径匹配的所有文件，并为每个文件启动一个harvester。每个prospector都在自己的Go协程中运行。 Filebeat目前支持两种prospector类型：log和stdin。每个prospector类型可以定义多次。日志prospector检查每个文件来查看harvester是否需要启动，是否已经运行，或者该文件是否可以被忽略（请参阅ignore_older）。 只有在harvester关闭后文件的大小发生了变化，才会读取到新行。 注：Filebeat prospector只能读取本地文件，没有功能可以连接到远程主机来读取存储的文件或日志。 配置文件：$FILEBEAT_HOME/filebeat.yml。Filebeat可以一次读取某个文件夹下的所有后缀名为log的文件，也可以读取指定的某一个后缀名为log的文件。 配置文件详解（ http://blog.51cto.com/michaelkang/1864225 ） （1）字段解释 paths： 指定要监控的日志，目前按照Go语言的glob函数处理。没有对配置目录做递归处理，比如配置的如果是： /var/log/* /*.log 则只会去/var/log目录的所有子目录中寻找以".log"结尾的文件，而不会寻找/var/log目录下以".log"结尾的文件。 encoding： 指定被监控的文件的编码类型，使用plain和utf-8都是可以处理中文日志的。 input_type： 指定文件的输入类型log(默认)或者stdin。 exclude_lines： 在输入中排除符合正则表达式列表的那些行。 include_lines： 包含输入中符合正则表达式列表的那些行（默认包含所有行），include_lines执行完毕之后会执行exclude_lines。 exclude_files： 忽略掉符合正则表达式列表的文件（默认为每一个符合paths定义的文件都创建一个harvester）。 fields： 向输出的每一条日志添加额外的信息，比如"level:debug"，方便后续对日志进行分组统计。默认情况下，会在输出信息的fields子目录下以指定的新增fields建立子目录， fields_under_root： 如果该选项设置为true，则新增fields成为顶级目录，而不是将其放在fields目录下。自定义的field会覆盖filebeat默认的field。 ignore_older： 可以指定Filebeat忽略指定时间段以外修改的日志内容，比如2h（两个小时）或者5m(5分钟)。 close_older： 如果一个文件在某个时间段内没有发生过更新，则关闭监控的文件handle。默认1h。 force_close_files： Filebeat会在没有到达close_older之前一直保持文件的handle，如果在这个时间窗内删除文件会有问题，所以可以把force_close_files设置为true，只要filebeat检测到文件名字发生变化，就会关掉这个handle。 scan_frequency： Filebeat以多快的频率去prospector指定的目录下面检测文件更新（比如是否有新增文件），如果设置为0s，则Filebeat会尽可能快地感知更新（占用的CPU会变高）。默认是10s。 document_type： 设定Elasticsearch输出时的document的type字段，也可以用来给日志进行分类。 harvester_buffer_size： 每个harvester监控文件时，使用的buffer的大小。 max_bytes： 日志文件中增加一行算一个日志事件，max_bytes限制在一次日志事件中最多上传的字节数，多出的字节会被丢弃。默认是10MB。 multiline： 适用于日志中每一条日志占据多行的情况，比如各种语言的报错信息调用栈。这个配置的下面包含如下配置： pattern： 多行日志开始的那一行匹配的pattern negate： 是否需要对pattern条件转置使用，不翻转设为true，反转设置为false。 match： 匹配pattern后，与前面（before）还是后面（after）的内容合并为一条日志 max_lines： 合并的最多行数（包含匹配pattern的那一行），默认为500行。 timeout： 到了timeout之后，即使没有匹配一个新的pattern（发生一个新的事件），也把已经匹配的日志事件发送出去 tail_files： 如果设置为true，Filebeat从文件尾开始监控文件新增内容，把新增的每一行文件作为一个事件依次发送，而不是从文件开始处重新发送所有内容。 backoff： Filebeat检测到某个文件到了EOF之后，每次等待多久再去检测文件是否有更新，默认为1s。 max_backoff： Filebeat检测到某个文件到了EOF之后，等待检测文件更新的最大时间，默认是10秒。 backoff_factor： 定义到达max_backoff的速度，默认因子是2，到达max_backoff后，变成每次等待max_backoff那么长的时间才backoff一次，直到文件有更新才会重置为backoff。比如： 如果设置成1，意味着去使能了退避算法，每隔backoff那么长的时间退避一次。 spool_size: spooler的大小，spooler中的事件数量超过这个阈值的时候会清空发送出去（不论是否到达超时时间），默认1MB。 idle_timeout: spooler的超时时间，如果到了超时时间，spooler也会清空发送出去（不论是否到达容量的阈值），默认1s。 registry_file: 记录filebeat处理日志文件的位置的文件 config_dir: 如果要在本配置文件中引入其他位置的配置文件，可以写在这里（需要写完整路径），但是只处理prospector的部分。 publish_async： 是否采用异步发送模式（实验功能）。 具体的一个yml采集配置样例如下：该配置文件是filebeat采集数据的依据，并根据需求添加必要配置，filebeat收集日志后发往logstash，配置如下： cd FILEBEAT_HOME nohup ./bin/filebeat -f config/test.conf >>/FILEBEAT_HOME/logs/filebeat.log & 后台启动filebeat，配置对应的参数 启动多个filebeat配置，新建一个目录（conf）存放多个filebeat的配置文件， #nohup ./bin/filebeat -f conf/* >>/FILEBEAT_HOME/logs/filebeat.log & 注意：一台服务器只能启动一个filebeat进程。 ps -ef |grep filebeat kill -9 $pid 注意： 非紧急情况下，杀掉进程只能用优雅方式。 A、filebeat运行不成功 问题：配置文件格式有问题，配置文件遵循yml文件格式， 多或少一个空格 都会导致启动问题，可以使用cmd命令窗口到filebeat安装路径下，使用filebeat.exe –c filebeat.yml 查看报错，也可以看filebeat路径下的log文件夹中的filebeat文件 B、 filebeat第一次运行成功无数据 问题：a、路径有问题 b、运行条件设置有问题（例如只采集某个条件下的数据，文件中没有符合条件的数据，这种情况下先注释掉采集条件测试一下） C、filebeat运行成功第一次运行后有数据，第二次无数据 问题：filebeat读取文件后会生成一个registry文件，注意windows机器中这个文件在手动启动的情况下会在filebeat安装目录下的data文件夹中，服务注册启动的情况下会在C盘下隐藏文件夹C:\ProgramData\filebeat中，删除掉这个就可以了 D、filebeat运行成功有数据，但是新添加数据不读取问题 问题：filebeat传输存在反压机制，在数据量特别大或者传输通道不通的情况下，filebeat会进行反压，暂停发送，等到数据量稳定或者数据传输通道正常的之后才会发送 Filebeat 保存每个文件的状态并经常将状态刷新到磁盘上的注册文件中。该状态用于记住harvester正在读取的最后偏移量，并确保发送所有日志行。如果输出（例如Elasticsearch或Logstash）无法访问，Filebeat会跟踪最后发送的行，并在输出再次可用时继续读取文件。 在Filebeat运行时，每个prospector内存中也会保存文件状态信息，当重新启动Filebeat时，将使用注册文件的数据来重建文件状态，Filebeat将每个harvester在从保存的最后偏移量继续读取。 每个prospector为它找到的每个文件保留一个状态。由于文件可以被重命名或移动，因此文件名和路径不足以识别文件。对于每个文件，Filebeat存储唯一标识符以检测文件是否先前已被采集过。 如果你使用的案例涉及每天创建大量新文件，你可能会发现注册文件增长过大。请参阅注册表文件太大？编辑有关你可以设置以解决此问题的配置选项的详细信息。 Filebeat保证事件至少会被传送到配置的输出一次，并且不会丢失数据。 Filebeat能够实现此行为，因为它将每个事件的传递状态存储在注册文件中。 在输出阻塞或未确认所有事件的情况下，Filebeat将继续尝试发送事件，直到接收端确认已收到。如果Filebeat在发送事件的过程中关闭，它不会等待输出确认所有收到事件。 发送到输出但在Filebeat关闭前未确认的任何事件在重新启动Filebeat时会再次发送。这可以确保每个事件至少发送一次，但最终会将重复事件发送到输出。 也可以通过设置shutdown_timeout选项来配置Filebeat以在关闭之前等待特定时间。 注意：Filebeat的至少一次交付保证包括日志轮换和删除旧文件的限制。如果将日志文件写入磁盘并且写入速度超过Filebeat可以处理的速度，或者在输出不可用时删除了文件，则可能会丢失数据。 在Linux上，Filebeat也可能因inode重用而跳过行。有关inode重用问题的更多详细信息，请参阅filebeat常见问题解答。 Logback日志切割用的是JDK里File#renameTo()方法。如果该方法失败，就再尝试使用复制数据的方式切割日志。查找该方法相关资料得知，只有当源文件和目标目录处于同一个文件系统、同volumn(即windows下的C, D盘)下该方法才会成功，切不会为重命名的后的文件分配新的inode值。也就是说，如果程序里一直保存着该文件的描述符，那么当程序再写日志时，就会向重命名后的文件中写。那么问题来了，filebeat是会一直打开并保存文件描述符的，那么它是怎么得知日志被切割这件事的呢？ 如果只用当前文件描述符一路监控到天黑的话，那么当logback把日志重命名后，filebeat仍然会监控重命名后的日志，新创建的日志文件就看不到了。实际上，filebeat是通过close_inactive和scan_frequency两个参数(机制)来应对这种情况的： (1)close_inactive 该参数指定当被监控的文件多长时间没有变化后就关闭文件句柄(file handle)。官方建议将这个参数设置为一个比文件最大更新间隔大的值。比如文件最长5s更新一次，那就设置成1min。默认值为5min。 (2)scan_frequency 该参数指定Filebeat搜索新文件的频率(时间间隔)。当发现新的文件被创建时， Filebeat会为它再启动一个 harvester 进行监控，默认为10s。 综合以上两个机制，当logback完成日志切割后(即重命名)，此时老的harvester仍然在监控重命名后的日志文件，但是由于该文件不会再更新，因此会在close_inactive时间后关闭这个文件的 harvester。当scan_frequency时间过后，Filebeat会发现目录中出现了新文件，于是为该文件启动 harvester 进行监控。这样就保证了切割日志时也能不丢不重的传输数据。(不重是通过为每个日志文件保存offset实现的)
『贰』 filebeat常见问题
Filebeat保持文件处理程序打开，直到文件到达文件末尾，以便它可以近乎实时地读取新的日志行。 如果Filebeat正在收集大量文件，则打开文件的数量可能会成为问题。 在大多数环境中，正在更新的文件数量很少。 close_inactive配置选项应相应地设置为关闭不再处于活动状态的文件。 您可以使用其他配置选项来关闭文件处理程序，但所有这些选项都应该小心使用，因为它们可能有副作用。 选项是： close_renamed和close_removed选项在Windows上很有用，可以解决与文件旋转相关的问题。 请参阅打开文件处理程序导致Windows文件旋转问题？ close_eof选项在具有大量只有很少条目的文件的环境中很有用。 close_timeout选项在关闭文件处理程序比发送所有日志行更重要的环境中很有用。 有关更多详细信息，请参阅设置探矿者。 确保在使用这些配置选项之前阅读这些配置选项的文档。 Filebeat可能被配置为频繁扫描文件。 检查filebeat.yml配置文件中scan_frequency的设置。 将scan_frequency设置为小于1s可能会导致Filebeat在频繁的循环中扫描磁盘。 Filebeat保持每个文件的状态并将该状态保存在registry_file中的磁盘上。 Filebeat重新启动时，文件状态用于在前一个位置继续读取文件。 如果每天都生成大量新文件，则注册表文件可能会变得太大。 要减小注册表文件的大小，有两个可用的配置选项：clean_removed和clean_inactive。 对于不再接触并忽略的旧文件（请参阅ignore_older），我们建议您使用clean_inactive。 如果旧文件从磁盘中删除，请使用clean_removed选项。 Inode重用会导致Filebeat跳过行吗？ 在Linux文件系统上，Filebeat使用inode和设备来识别文件。 从磁盘中删除文件时，可将inode分配给新文件。 在涉及文件旋转的使用情况下，如果旧文件被删除并且之后立即创建新文件， 新文件可能与删除的文件具有完全相同的inode。在这种情况下，Filebeat假定新文件与旧文件相同，并尝试在旧位置继续读取，这是不正确的。 默认状态不会从注册表文件中删除。要解决inode重用问题，我们建议您使用clean_ *选项（特别是clean_inactive）来删除非活动文件的状态。 例如，如果您的文件每24小时轮换一次，并且轮换的文件不再更新，则可以将ignore_older设置为48小时，将clean_inactive设置为72小时。 您可以将clean_removed用于从磁盘中删除的文件。请注意，clean_removed会在扫描期间无法找到文件时清除注册表中的文件状态。如果文件稍后再次显示，它将从头开始重新发送。 Filebeat使用换行符来检测事件的结束。 如果将行逐渐添加到正在采集的文件中，则在最后一行之后需要换行符，否则Filebeat将不会读取文件的最后一行。 在默认行为中，Filebeat会打开文件并保持打开状态，直到达到文件末尾。 在配置的输出很长时间（例如Elasticsearch或Logstash不可用）的情况下，这可能会导致Filebeat将文件处理程序保留到同时从文件系统中删除的文件。 只要Filebeat保持已删除的文件处于打开状态，操作系统就不会释放磁盘空间，这可能会导致磁盘利用率增加，甚至出现磁盘不足的情况。 为了缓解这个问题，您可以将close_timeoutedit设置设置为"5m"。 这将确保每5分钟关闭一次文件处理程序，而不管是否达到EOF。 请注意: 如果在Filebeat到达文件末尾之前删除文件，则此选项可能会导致数据丢失。 如果您需要限制带宽使用率，我们建议您在操作系统OS上配置网络堆栈以执行带宽限制。 例如，以下Linux命令通过在通过端口5044的TCP连接上设置50 kbps的限制来限制Filebeat和Logstash之间的连接： 使用操作系统工具执行带宽限制可让您更好地控制策略。 例如，您可以使用操作系统工具在白天限制带宽，但不是在晚上。 或者您可以保留带宽不受限制，但为流量分配低优先级。 您的配置文件的结构有问题，或者您使用了YAML分析程序无法解析的路径或表达式，因为配置文件包含未正确转义的字符。 如果YAML文件包含具有空格或不常用字符的路径，请将路径包装在单引号中（请参阅将单引号标记为包裹路径）。 另请参阅YAML提示和疑难解答中的一般建议： https://www.elastic.co/guide/en/beats/filebeat/current/yaml-tips.html 索引模板可能未正确加载。 请参阅步骤4：在Elasticsearch中加载索引模板。 如果您最近执行了加载或解析自定义结构化日志的操作，则可能需要刷新索引以使字段在Kibana中可用。 要刷新索引，请使用刷新API。 例如： 【参考： https://www.elastic.co/guide/en/beats/filebeat/current/faq.html 】
『叁』 FileBeat手动配置采集
为了手动配置Filebeat（代替用模块），你可以在filebeat.yml中的filebeat.inputs区域下指定一个inputs列表。
列表时一个YMAL数组，并且你可以指定多个inputs，相同input类型也可以指定多个。例如：
从日志文件读取行
为了配置这种input，需要指定一个paths列表，列表中的每一项必须能够定位并抓取到日志行。例如：
你还可以应用设置其它额外的配置项（比如，fields, include_lines, exclude_lines, multiline等等）来从这些文件中读取行。你设置的这些配置对所有这种类型的input在获取日志行的时候都生效。
为了对不同的文件应用不同的配置，你需要定义多个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编码是特殊的，因为它不校验或者转换任何输入。
exclude_lines
一组正则表达式，用于匹配你想要排除的行。Filebeat会删除（PS：我觉得用“丢弃”更合适）这组正则表达式匹配的行。默认情况下，没有行被删除。空行被忽略。
如果指定了multiline，那么在用exclude_lines过滤之前会将每个多行消息合并成一个单行。（PS：也就是说，多行合并成单行后再支持排除行的过滤）
下面的例子配置Filebeat删除以DBG开头的行：
一组正则表达式，用于匹配你想要包含的行。Filebeat只会导出那些匹配这组正则表达式的行。默认情况下，所有的行都会被导出。空行被忽略。
如果指定了multipline设置，每个多行消息先被合并成单行以后再执行include_lines过滤。
下面是一个例子，配置Filebeat导出以ERR或者WARN开头的行：
（画外音：如果 include_lines 和 exclude_lines 都被定义了，那么Filebeat先执行 include_lines 后执行 exclude_lines，而与这两个选项被定义的顺序没有关系。include_lines 总是在 exclude_lines选项前面执行，即使在配置文件中 exclude_lines 出现在 include_lines的前面。）
下面的例子导出那些除了以DGB开头的所有包含sometext的行：
当抓取一个文件时每个harvester使用的buffer的字节数。默认是16384。
max_bytes
单个日志消息允许的最大字节数。超过max_bytes的字节将被丢弃且不会被发送。对于多行日志消息来说这个设置是很有用的，因为它们往往很大。默认是10MB（10485760）。
json
这些选项使得Filebeat将日志作为JSON消息来解析。例如：
为了启用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如何扩多行处理日志消息
exclude_files
一组正则表达式，用于匹配你想要忽略的文件。默认没有文件被排除。
下面是一个例子，忽略.gz的文件
如果启用，那么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。
『肆』 Filebeat占用文件句柄
平台使用整套的ELK日志框架：服务写本地文件日志，由Filebeat监控本地日志，并写入ES。 本地Filebeat配置如下：
问题：文件句柄占用，导致磁盘无法释放。重启Filebeat后可清理掉占用的磁盘。
收到问题后，感觉是一个很常见的问题，就直接网络了一下，果然是一下就有很多的线索。结合一些帖子，对现有服务器做了排查，如下：
这里有两个问题：
可设置： close_older:1h force_close_files:false 由于目前服务日志滚动的频率不是很高，文件更名后，1h左右不会被删除。所以可以尝试使用close_older配置在文件删除之前释放句柄。
===================== 2019/7/17更新： 调研后发现，close_older的默认值就是1h，所以该方案不会让原本的问题变得更好。
虽然问题可能会被解决，但对Filebeat还不够理解，并且上述提出的两个问题，没有很好的解答。因此，我继续对Filebeat做进一步的学习和实验。
资料链接： https://www.jianshu.com/p/6282b04fe06a Filebeat主要组件：prospector和harvester，如图：
filebeat保持文件状态：
filebeat保证至少一次交付： 每次交付会有状态，对端需要ACK确认。
注意： Filebeat的至少一次交付保证包括日志轮换和删除旧文件的限制。如果将日志文件写入磁盘并且写入速度超过Filebeat可以处理的速度，或者在输出不可用时删除了文件，则可能会丢失数据。 在Linux上，Filebeat也可能因inode重用而跳过行。有关inode重用问题的更多详细信息，请参阅filebeat常见问题解答。（后续遇到的话，继续研究，本次略过）
首先看一下close_renamed的解释： close_renamed Only use this option if you understand that data loss is a potential side effect. When this option is enabled, Filebeat closes the file handler when a file is renamed. This happens, for example, when rotating files. By default, the harvester stays open and keeps reading the file because the file handler does not depend on the file name. If the close_renamedoption is enabled and the file is renamed or moved in such a way that it’s no longer matched by the file patterns specified for the , the file will not be picked up again. Filebeat will not finish reading the file. WINDOWS: If your Windows log rotation system shows errors because it can’t rotate the files, you should enable this option. 经过测试后发现，采用filebeat监听一个文本文件，通过mv将文件更改，close_renamed是管用的，但通过rm删除文件，close_renamed是不管用的。
结论：未重现生产环境的现象。
阶段性结论：升级生产环境filebeat版本后，检查问题是否解决。
后续研究：
close_inactive 启用此选项时，如果文件在指定的持续时间内没有更新，Filebeat会关闭文件句柄。如果关闭的文件再次发生变化，则会启动一台新的harvester，并在scan_frequency过去后采集最新的更改。建议将close_inactive设置为大于日志文件两次更新间隔时间的最大值。例如，如果日志文件每隔几秒更新一次，则可以安全地将close_inactive设置为1m。如果有更新频率非常不同的日志文件，则可以使用具有不同值的多个prospectors配置。将close_inactive设置为较低的值意味着文件句柄会更快关闭。但是，这具有副作用，即如果harvester关闭，则不会实时发送新的日志行。关闭文件的时间戳不取决于文件的修改时间，关闭文件的时间戳为修改文件的时间+close_inactive。例如，如果close_inactive设置为5分钟，那么在收割机读取文件的最后一行之后，5分钟的倒计时开始。您可以使用时间字符串，如2h（2小时）和5m（5分钟）。默认值是5m。
scan_frequency 指定扫描指定路径目录下是否有新的文件产生。例如，指定1以尽可能频繁地扫描目录，而不会导致Filebeat过于频繁地扫描。我们不建议将此值设置为<1秒。 如果您需要近实时发送日志行，请勿使用非常低的scan_frequency，但应调整close_inactive，以便文件处理程序保持打开状态并持续轮询您的文件。 默认设置是10秒。 注意区分backoff
『伍』 ELFK-基础篇
本文发布链接地址: https://www.jianshu.com/p/bf5189583543 [TOC] 后台运行与测试 关闭 配置文件的格式是 YAML 格式 elasticsearch-head 是一个简单的 elasticsearch web 图形化的管理工具 使用javascript写的一个弹性搜索集群的Web前端，在 elasticsearch5.x 后不再支持 插件形式的安装，需要作为一个独立的服务安装和启动。 上面的方式我测试没有成功，原因可能是网络问题导致，访问的都是国外的网站，慢。 推荐下面的方式 还有一种安装方式非常简单，只需要在 chrome 浏览器中安装 head 插件即可 在 谷歌商店 搜索 "ElasticSearch Head" 插件，安装这个插件，之后点击 相应插件图标即可。 插件安装地址 之后，在浏览地址栏里输入 elasticsearch 的地址和端口，点击连接 安装完毕 == 该配置文件的所有者必须是root或正在执行Beat进程的用户。 该文件的权限必须不允许除所有者以外的任何人写入，需要是0644的权限== ==/var/log/* 这样的匹配是错误的== 默认情况下，Filebeat 会自动加载推荐的模板文件 filebeat.template.json，如果启用了 Elasticsearch 输出。您可以通过调整 filebeat.yml 文件中的选项template.name和template.path选项来配置filebeat以加载其他模板： ==默认情况下，如果索引中已存在模板，则不会覆盖该模板。要覆盖现有的模板，请template.overwrite: true在配置文件中进行设置。== 要禁用自动模板加载，请注释Elasticsearch输出下的 template 的相关部分。 ==如果使用Logstash输出，则不支持自动加载模板的选项，需要手动加载模板。== 假如配置了输出到 Logstash 中，需要手动添加索引模板到 Elasticsearch 中，就需要在 filebeat 的安装目录中执行如下命令 假如你之前已经用了输出到 elasticsearch 的索引模板，可以在成功执行上面命令后，执行下面的命令，用于删除旧的索引模板，这样可以强迫 Kibana 重新使用新的索引模板 要在 Kibana 中查看数据，假如首次使用 kibana，需要先创建索引模式，具体请看 Kibana 部分的介绍 创建索引模式后，您可以 filebeat-* 在 Kibana 中选择索引模式来探索 Filebeat数据。 数据在线程之间以 事件 的形式流传。不要叫行，因为 logstash 可以处理多行事件 此时可以在命令行里输入一下信息，应该可以看到一些输出 可以利用文件输入插件，Logstash 可以很容易配置成读取日志文件作为输入源 例如 读取 Apache 日志文件作为输入,然后输出到标准输出。配置文件如下： 配置为将所有的输入输出到一个 Elasticsearch 实例中. 这是在 ELK 平台中是最常用的配置。 这里是把一个Django 的日志作为输入，之后输出到 elasticsearch 好像没啥卵用 插件类型包括: Logstash 可以从 file 读取数据 file 插件可用于将事件和日志文件输入给 Logstsh stdin 输入插件用于从标准输入中读取事件和日志。 当我们配置为 stdin 时，终端上的任何输入都会作为 Logstash 日志管道的输入。 这通常用于测试。 filebeat 插件出现在最新的 5.x 版本中，它是一个轻量级的事件和日志搜集工具。 会把处理过的数据输出到屏幕终端 把处理过的数据存储到 elasticsearch 集群中 true 和 false 编辑码器实际上并不是一种数据类型，它是在输入或输出的时候对数据进行解码或编码 的一种方式 例子： 在输出的时候设置，把输出数据编码成 JSON 格式 就是由一系列键值对组合成的集合。 以 "key" => "value" 的形式表示，多个用空格分开 用双引号引起来的字符序列 以字符 # 开头 字段可以使用 [field_name] 的方式引用 嵌套字段 [field1][field2] 支持下标索引 小贴士：logstash 的数组也支持倒序下标，即 [geoip][location][-1] 可以获取数组最后一个元素的值。 Logstash 还支持变量内插，在字符串里使用字段引用的方法是这样： "the longitude is %{[geoip][location][0]}" Logstsh 的判断语句，与js的一样 条件语句可以一起配合使用的运算符如下： 通常来说，你都会在表达式里用到字段引用。为了尽量展示全面各种表达式，下面虚拟一个示例： 要配置Logstash，您可以创建一个配置文件，指定要使用的插件和每个插件的设置。 您可以在配置中引用事件字段，并使用条件来满足某些条件时处理事件。 当您运行logstash时，使用-f指定您的配置文件。 可以把 Logstash 相关的配置信息放在一个自定义的文件里 配置文件的格式是被分为不同的区域块儿的，基本上是根据 输入插件、过滤插件和输出插件来区分的 每一个区域块儿都包含了一个或者多个插件的配置选项。 ==如果在同一个区域中使用了多个插件，则配置文件中的顺序就指定了应用到事件处理六的顺序。== 在运行 Logstash 运行时，可以用 -f 参数指定配置文件的完整路径，甚至可以指定一个包含了多个不同类型如输入、过滤和输出插件的配置文件目录 使用 -t (–configtest) 参数可以检查配置文件的语法，而不是真正运行 Logstash 测试配置文件 如果配置文件通过配置测试，请使用以下命令启动Logstash： 该–config.reload.automatic选项启用自动配置重新加载，以便您每次修改配置文件时不必停止并重新启动Logstash。 –config.reload.automatic 可以用 -r 替代 配置文件常见错误： 下面是完整正确的配置文件内容 用指定配置文件的方式启动 Ctrl + d 停止 logstash 在 shell 命令行里执行的启动程序first-pipeline.conf 其实上面的命令参数在 5.x 之后，都可以在配置文件 logstash.yml 中设置了 现在，您有一个工作流程，从Filebeat读取日志行。但是您会注意到日志消息的格式不理想。您要解析日志消息以从日志中创建特定的命名字段。为此，您将使用grok过滤器插件。 因为grok过滤器插件在传入的日志数据中查找模式，所以配置插件需要您决定如何识别用例感兴趣的模式。来自Web服务器日志示例的代表行如下所示： 使用方法，编辑 first-pipeline.conf 写入下面的内容： 假如你在这之前已经运行了 logstash 和 filebeat 。要想生效现在的过滤配置，您需要强制Filebeat从头开始读取日志文件。 不必重新启动Logstash来接收更改，但是需要删除 filebeat 下的注册表文件 registry，此文件一般在安装目录下的 data 目录下。 由于Filebeat存储在注册表中收集的每个文件的状态，因此删除注册表文件会强制Filebeat读取从头开始捕获的所有文件。 接下来，使用以下命令重新启动Filebeat即可 除了解析日志数据以获得更好的搜索之外，过滤插件也可以从现有数据中导出补充信息。例如，geoip插件会查找IP地址，从地址中导出地理位置信息，并将该位置信息添加到日志中。 将Logstash实例配置为使用geoip过滤器插件，将以下行添加到文件的filter部分first-pipeline.conf 完整的示例： 修改好保存，生效的话，同样先删除 Filebeat 注册文件，之后重启 filebeat 配置输出到 Elasticsearch 测试您的管道编辑 现在，Logstash管道配置为将数据索引到Elasticsearch集群中，您可以查询Elasticsearch。 根据grok过滤器插件创建的字段，尝试对Elasticsearch进行测试查询。使用YYYY.MM.DD格式将$ DATE替换为当前日期 输出 注意 索引名称中使用的日期是基于UTC，而不是Logstash运行的时区。如果查询返回index_not_found_exception，请确保logstash-$DATE反映了索引的实际名称。要查看可用索引的列表，请使用此查询：curl 'localhost:9200/_cat/indices?v' ps -ef |grep node kill -9 进程号 在浏览其中输入以下地址
『陆』 filebeat安装使用
1.配置文件含义
2.启动filebeat测试
输出信息
filebeat找不到配置文件时可以指定配置文件
./filebeat -c /usrlocal/filebeat/filebeat.yml
-e 将启动信息输出到屏幕上
filebeat进程日志
filebeat本身运行的日志默认位置 ${install_path}/logs/filebeat
要修改filebeat的日子路径，可以添加一下内容在filebeat.yml配置文件
查看可用的模块列表
模块配置文件保存位置
${install_path}/filebeat/moles.d/
启动nginx模块
sudo ./filebeat moles enable nginx
1.使用模板默认路径
nginx模块配置收集日志的默认路径是
CentOS
Ubuntu
测试
2.nginx日志不在默认存储路径下时
如果不设置此项，filebeat将根据你的操作系统选择使用默认路径
注意：此种方式十一追加的方式和模块默认路径合并在一起的，也就是说使用了此种方式，nginx模块还是回去默认路径下查找。
3.配置ouput
filebeat是用于搜集日志，之后把日志推送到某个接受的系统中，这些系统或者装置在filebeat中称为output。
output类型
完整的output列表在filebeat官方文档
filebeat在运行的时候，以上的output只可配置其中一种
输出到console
输出完整的json数据
前台运行filebeat
如果只想输出完整json数据中的某些字段
其他输出目标:
输出到elasticsearch
输出到 logstash
有时候处于实验目的，可能需要重新读取日志文件，这个时候需要删除安装目录下的 data 文件夹，重新运行 filebeat 即可。 [图片上传失败…(image-c04404-1650615591430)]
报错
假如出现如下报错，请删制除安装目录中的data文件夹
查看一下是否有一个进程已经处于运行状态，尝试杀死此进程，之后重新运行filebeat
可以在配置中定义处理器，以便在事件发送到配置的输出之前对其进行处理。libbeat库提供以下处理器∶
工作方式
每个处理器都接收一个事件，对该事件应用已定义的操作，然后返回该事件。如果定义
处理器列表，则将按照在Filebeat配置文件中定义的顺序执行它们。
去重日志中的某些行
配置位置在 filebeat.yml 文件中
删除所有以 DBG: 开头的行
像输出的信息中添加某些自定义字段
从事件中删除某些字段
以上配置，将删除字段: field1 和 field2
ignore_missing 的值为 false 表示，字段名不存在则会返回错误。为true不会返回错误。
注意: 事件中的 “@timestamp 和 type 字段是无法删除的。
下面的配置示例是删除顶级字段 input 和顶级字段 ecs 中的 version 字段。
『柒』 微服务治理-日志归集-环境搭建(开发及测试）
根据houyi平台规划，日志归集相关的技术组件都是基于k8s进行部署。 相关部署文件列表如图所示： 对应各个技术组件的部署以最简单的单点方式部署，暂时不考虑高可用性及性能弹性伸缩等非功能需求。 该部署比较简单，就是对外提供9200，9300两个端口提供服务，也没有考虑数据存储到容器外。 创建一个ClusterService, K8S内服务可以通过服务名称elasticsearch-service或一个固定IP访问es。 自定义logstash logstash.conf配置文件及logstash.yml文件，配置如下所示： logstash.conf主要配置为： logstash.yml的配置主要是实现与es之间的心跳。（通过监控日志及名称猜测是这个作用 ，并没有核实，如理解有误望指点。） logstash 容器启动logstash，并指定配置文件，打开5044端口。 通过filebeat config定义filebeat配置文件filebeat.yml： 根据filebeat 配置，读取指定路径下的增量日志信息，
『捌』 FileBeat配置输出
当你指定Elasticsearch作为output时，Filebeat通过Elasticsearch提供的HTTP API向其发送数据。例如：
为了启用SSL，只需要在hosts下的所有URL添加https即可
如果Elasticsearch节点是用IP:PORT的形式定义的，那么添加protocol:https。
enabled
启用或禁用该输出。默认true。
hosts
Elasticsearch节点列表。事件以循环顺序发送到这些节点。如果一个节点变得不可访问，那么自动发送到下一个节点。每个节点可以是URL形式，也可以是IP:PORT形式。如果端口没有指定，用9200。
username
用于认证的用户名
password
用户认证的密码
protocol
可选值是：http 或者 https。默认是http。
path
HTTP 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 选项。如果你用内置的Kibana dashboards，你也需要设置setup.dashboards.index选项。
indices
索引选择器规则数组，支持条件、基于格式字符串的字段访问和名称映射。如果索引缺失或没有匹配规则，将使用index字段。例如：
timeout
请求超时时间。默认90秒。
在filebeat.yml配置文件的setup.template区域指定索引模板，用来设置在Elasticsearch中的映射。如果模板加载是启用的（默认的），Filebeat在成功连接到Elasticsearch后自动加载索引模板。
你可以调整下列设置或者覆盖一个已经存在的模板。
上面是配置Filebeat输出到Logstash，那么Logstash本身也有配置，例如：
『玖』 记Filebeat的prospectors部分配置说明
Filebeat是一个日志文件收集工具，filebeat最初是基于logstash-forwarder源码的日志数据shipper，部署在所要采集日志的服务器上，采集指定的日志文件信息转发给logstash进行分析然后再发送到elasticsearch构建索引，或者直接发送到elasticsearch，也可以发送到redis上，用redis作为消息队列 Filebeat搜集日志的主要角色有 harvester 和 prospectors harvester负责读取单个文件的内容。harvester逐行读取每个文件，并将内容发送到输出。每个文件启动一台harvester。harvester负责打开关闭文件，harvester运行时会保持文件的文件描述符保持打开的状态，而且文件在被扫描时被删除或重命名了，Filebeat会继续读取文件， 这会导致在harvester关闭之前，被删除的文件的磁盘空间不会被释放。 默认情况下，Filebeat将文件保持打开状态，直到达到 close_inactive 。 prospectors目前支持5种类型： prospectors检查每个文件以查看是否需要启动harvester，是否已经运行harvester，或者文件是否可以被忽略。 只有在harvester关闭后文件的大小发生了变化，才会选择新行。 prospectors只能读取本地文件 Filebeat保持每个文件的状态并经常将状态刷新到磁盘的上注册表中。 该状态用于记住harvester正在读取的最后偏移量，便于确保发送所有日志行。但是如果你收集的日志，每天新建了大量的文件，会发现注册表会非常的巨大。要减小注册表文件的大小，有两个可用的配置选项： clean_removed 和 clean_inactive 。 对于不再接触并忽略的旧文件，使用 clean_inactive 。 如果旧文件从磁盘中删除，请使用 clean_removed 选项。 Filebeat保证事件至少会被传送到你所配置的output目标一次，并且不会丢失数据。 Filebeat能够实现此行为，因为它将每个事件的传递状态存储在注册表文件中。 在定义的output被阻止并且未确认所有事件接收到情况下，Filebeat将继续尝试发送事件，直到输出确认已收到事件。 如果Filebeat在发送事件的过程中关闭，它不会在关闭之前等待output目标确认所有事件的接受，Filebeat在重新启动后，他会重新发送之前没被输出目标确认接受的事件。 这可以确保每个事件至少发送一次，但也可能会将重复事件发送到输出目标。 您可以通过设置 shutdown_timeout 选项来配置Filebeat以在关闭之前的等待时间。 每个prospectors为每个文件保持一个状态。 由于文件可以被重命名或移动，因此文件名和路径不足以识别文件。 对于每个文件，Filebeat存储唯一标识符以检测文件是否先前已被harvester扫描过。 我们可以在filebeat.yaml中定义prospectors的配置选项，来实现对特定的日志进行特定的扫描收集，下文只列出部分配置选项，详细请看 官方文件 close_ * 配置选项用于在某个标准或时间后关闭harvester。 关闭harvester意味着关闭文件处理程序。 如果收割机关闭后文件被更新，则在 scan_frequency 过后，文件将再次被扫描。 但是，如果在harvester关闭的情况下移动或删除文件，Filebeat将无法再次扫描文件，harvester将丢失未读取的数据。 close_inactive 启用此选项时，如果文件在指定的持续时间内没有更新，Filebeat会关闭文件句柄。如果关闭的文件再次发生变化，则会启动一台新的harvester，并在 scan_frequency 过去后采集最新的更改。建议将 close_inactive 设置为大于日志文件两次更新间隔时间的最大值。例如，如果日志文件每隔几秒更新一次，则可以安全地将close_inactive设置为1m。如果有更新频率非常不同的日志文件，则可以使用具有不同值的多个prospectors配置。将close_inactive设置为较低的值意味着文件句柄会更快关闭。但是，这具有副作用，即如果harvester关闭，则不会实时发送新的日志行。关闭文件的时间戳不取决于文件的修改时间，关闭文件的时间戳为修改文件的时间+close_inactive。例如，如果close_inactive设置为5分钟，那么在收割机读取文件的最后一行之后，5分钟的倒计时开始。您可以使用时间字符串，如2h（2小时）和5m（5分钟）。默认值是5m。 close_renamed 启用此选项时，文件重命名时Filebeat会关闭文件处理程序。 默认情况下，采集器保持打开状态并持续读取文件，因为文件处理程序不依赖于文件名。 如果启用close_renamed选项，并且文件被重命名或移动，则文件将不会再次拾取。 Filebeat不会完成读取文件。 close_removed 如果启用此选项，Filebeat会在删除文件时马上关闭harvester。如果一个文件在harvester执行时被提前删除，而您没有启用close_removed，Filebeat会保持文件打开以确保harvester已经完成 通常情况下，文件只能在 close_inactive 指定的时间内未更新导致文件关闭后才能被删除。 如果此设置导致文件因为太早从磁盘中删除而未完全读取，请禁用此选项。 该选项默认启用。 如果禁用此选项，则还必须禁用clean_removed。 WINDOWS：如果您的Windows日志轮换系统由于无法轮换文件而显示错误，请确保启用此选项。 close_eof 启用此选项后，一旦文件结束，Filebeat会立即关闭文件。 当您的文件只写入一次而不是不时更新时，这很有用。 close_timeout 启用此选项时，Filebeat会为每个harvester提供预定义的使用期限。无论harvester读取到文件中哪个位置，在close_timeout时间过后读数都会停止。当您只想在文件上花费预定义的时间时，此选项可用于较旧的日志文件。虽然close_timeout将在预定义的超时后关闭文件，但如果文件仍在更新中，探矿者将根据定义的scan_frequency再次启动一个新的采集器。此收割机的close_timeout将在超时倒计时后重新开始。此选项在输出被阻止的情况下特别有用，这使得Filebeat即使对从磁盘中删除的文件也保持打开的文件处理程序。将close_timeout设置为5m可确保文件定期关闭，以便操作系统释放它们。如果您将close_timeout设置为与ignore_older相等，则在收割机关闭时如果修改该文件，则该文件将不会被拾取。这些设置的组合通常会导致数据丢失，并且不会发送完整的文件。当您对包含多行事件的日志使用close_timeout时，收割机可能会停在多行事件的中间，这意味着只会发送部分事件。如果收割机再次启动并且文件仍然存在，则只会发送事件的第二部分。该选项默认设置为0，这意味着它被禁用。 clean_ *选项用于清理注册表文件中的状态条目。 这些设置有助于减小注册表文件的大小，并可以防止潜在的inode重用问题。 clean_inactive 启用此选项后，Filebeat将在指定的非活动时间段过去后移除文件的状态。如果文件已被Filebeat忽略（该文件比ignore_older早），则只能删除该状态。 clean_inactive设置必须大于ignore_older + scan_frequency，以确保在收集文件时不会删除状态。否则，该设置可能会导致Filebeat不断重新发送全部内容，因为clean_inactive将删除文件的状态，harvester仍然执行，如果文件更新或再次出现，则从头开始读取文件。 clean_inactive配置选项对于减小注册表文件的大小非常有用，特别是在每天生成大量新文件的情况下。此配置选项对于防止Linux上的inode重用导致的Filebeat问题也很有用。 clean_removed 启用此选项后，如果文件在磁盘上找不到，Filebeat会清除注册表中的文件，该选项默认启用。 如果您还禁用了 close_removed ，则必须禁用此选项。 指定扫描指定路径目录下是否有新的文件产生。例如，指定1以尽可能频繁地扫描目录，而不会导致Filebeat过于频繁地扫描。我们不建议将此值设置为<1秒。 如果您需要近实时发送日志行，请勿使用非常低的scan_frequency，但应调整 close_inactive ，以便文件处理程序保持打开状态并持续轮询您的文件。 默认设置是10秒。 注意区分 backoff 每个harvester在获取文件时使用的缓冲区的大小（以字节为单位）。 默认值是16384。 单个日志消息可以拥有的最大字节数。 max_bytes之后的所有字节被丢弃并且不发送。 此设置对于可能变大的多行日志消息特别有用。 默认值是10MB（10485760）。 这些选项使Filebeat能够解码构造为JSON消息的日志。这些选项使Filebeat解码日志结构化为JSON消息。 解码发生在行过滤和多行之前。 如果您设置了 message_key 选项，您可以将JSON解码与过滤和多行结合使用。 在应用程序日志被包装在JSON对象中的情况下，这可能会很有用，例如Docker发生的情况。 配置示例： 您必须至少指定以下设置之一才能启用JSON解析模式： 默认情况下，解码后的JSON放在输出文档中的“json”键下。 如果启用此设置，则会将键复制到输出文档的顶层。 默认值是false。 如果启用了keys_under_root和此设置，则来自解码的JSON对象的值会覆盖Filebeat通常添加的字段（类型，源，偏移量等）以防冲突。 如果启用此设置，则在出现JSON解组错误或配置中定义了message_key但无法使用的情况下，Filebeat会添加“error.message”和“error.type：json”项。 一个可选的配置设置，用于指定应用行筛选和多行设置的JSON密钥。 如果指定，键必须位于JSON对象的顶层，并且与键关联的值必须是字符串，否则不会发生筛选或多行聚合。 控制Filebeat如何处理跨越多行的日志消息的选项。 有关配置多行选项的更多信息，请参阅管理多行消息 。 如果此选项设置为true，Filebeat开始在每个文件的末尾读取新文件，而不是开始。 将此选项与日志轮换结合使用时，可能会跳过新文件中的第一个日志条目。 默认设置为false。 此选项适用于Filebeat尚未处理的文件。 如果您之前运行Filebeat并且文件的状态已被tail_files ，则tail_files将不适用。 harvester将继续之前的状态执行扫描。 要将tail_files应用于所有文件，您必须停止Filebeat并删除注册表文件。 请注意，这样做会删除以前的所有状态。 注意 当您首次在一组日志文件上运行Filebeat时，忽略旧的日志。 第一次运行后，我们建议禁用此选项，否则您可能会在文件轮转过程中丢失行。 为此prespectors生成的事件设置的接收节点管道标识。 注意 管道标识也可以在Elasticsearch输出中进行配置，但此选项通常会让配置文件更简单。 如果管道在prespectors和输出中均配置，则选择prespectors中的配置。 向输出的每一条日志添加额外的信息，比如“level:debug”，方便后续对日志进行分组统计。默认情况下，会在输出信息的fields子目录下以指定的新增fields建立子目录。 例如 则在Kibana看到的内容如下： 如果该选项设置为true，则新增fields成为顶级目录，而不是将其放在fields目录下。自定义的field会覆盖filebeat默认的field。例如添加如下配置： 则在Kibana看到的内容如下： symlinks选项允许Filebeat除了常规文件以外还收集符号链接。 收集符号链接时，Filebeat会打开并读取原始文件。 当您配置收集符号链接时，请确保排除是否存在原始文件路径。 如果单个prespectors配置为收集的符号链接指向的路径已存在同一个prespectors下，则prespectors将检测到问题并仅处理找到的第一个文件。 但是，如果配置了两个不同的prespectors（一个读取符号链接而另一个读取原始路径），则将采集两个路径，导致Filebeat发送重复数据，并且prespectors覆盖彼此的状态。 如果符号链接到日志文件的文件名中包含额外的元数据，并且您想要在Logstash中处理元数据，则symlinks选项可能很有用。 例如Kubernetes日志文件的情况。 由于此选项可能会导致数据丢失，因此默认情况下会禁用它。 该选项指定达到EOF后再次检查文件是否有更新的间隔时间，默认值是1秒。 该选项指定达到EOF后再次检查文件是否有更新的最大间隔时间。 默认值是10秒。 要求：max_backoff应始终设置为max_backoff <= scan_frequency 。 如果max_backoff应该更大，建议关闭文件处理程序，而不要让探矿者重新拾取文件。 指定backoff的增长因数，backoff=backoff * backoff_factor <= max_backoff。 默认值是2。 harvester_limit选项限制一个探矿者并行启动的收割机数量。 这直接关系到打开的文件处理程序的最大数量。 harvester_limit的默认值是0，这意味着没有限制。 如果要采集的文件数量超过操作系统的打开文件处理程序限制，则此配置很有用。 设置收割机数量的限制意味着可能不是所有文件都并行打开。 因此，我们建议您将此选项与close_*选项组合使用，以确保收割机更经常停止，以便可以拾取新文件。 目前，如果新的收割机可以重新启动，收割机将随机挑选。 这意味着收割机可能刚刚关闭，然后再次更新，可能会启动而不是收割机收集长时间未收割的文件。 此配置选项适用于每个探矿者。 您可以使用此选项通过分配更高限的收割机来间接地为某些探矿者设置更高的优先级。 与type: udp ，指定通过UDP接收的消息的最大大小。 默认值是10240。 这些选项仅在使用docker探矿器类型时可用。 它们允许配置容器列表以从中读取日志。 Docker探矿者将在其路径下搜索容器日志，并将其解析为常见的消息行，并提取时间戳。 所有事情都发生在行筛选，多行和JSON解码之前，因此可以与它们结合使用。 配置示例： 使用docker探矿者类型时，您必须定义containers.ids ，这些都是可用的设置：
『拾』 docker安装filebeat
1、使用docker拉取filebeat镜像
2、下载filebeat配置文件
3、启动容器
说明：执行setup命令， 安装filebeat的index
说明：一定要映射日志文件路径，区分宿主机日志路径（/mnt/ygt_cloud/log）和容器日志路径（/logs/tomcat）
