【问题标题】:fluentd multiline parser in parser filter解析器过滤器中的流利多行解析器
【发布时间】:2021-04-12 22:15:33
【问题描述】:

我正在尝试在 fluentd on kubernetes 中解析我的应用程序中的多行日志。

我目前有以下过滤器插入我的流利容器:

<filter kubernetes.**>
  @type parser
  key_name log
  emit_invalid_record_to_error false # do not fail on non-matching log messages
  reserve_data true # keep the log key (needed for non-matching records)
  <parse>
    @type multiline
    format_firstline /\d{4}-\d{1,2}-\d{1,2}/
    format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3})\s+(?<level>\S+)(?:\s+\[[^\]]*\])?\s+(?<pid>\d+)\s+---\s+\[\s*(?<thread>[^\]]+)\]\s+(?<class>\S+)\s+:\s+(?<message>.*)/
    time_format %Y-%m-%d %H:%M:%S.%L
    types pid:integer
  </parse>
</filter>

这个过滤器应该解析 Spring Boot 风格的日志(这并不重要,因为它也不适用于我的其他过滤器)。

单行日志解析得很好!检测到所有捕获组,时间格式和 pid 类型也保存为整数。但是在多行日志语句的情况下,下一行保持原样并保存为自己的条目。

我从 fluentd 文档中得到了这个解析器的想法:https://docs.fluentd.org/parser/multiline

文档说目前 in_tail 插件适用于多行,但其他输入插件不适用。

我使用的容器使用in_tail 插件来获取日志。但我在过滤器中使用解析器。不确定这是否是问题所在?在文档中,解析器过滤器插件 (https://docs.fluentd.org/filter/parser) 只是链接到解析器插件概述 (https://docs.fluentd.org/parser),而没有提及任何关于单个解析器不起作用的信息。

如果有人能指出我正确的方向,那就太好了!

提前致谢!

【问题讨论】:

    标签: regex elasticsearch kubernetes logging fluentd


    【解决方案1】:

    我最近遇到了完全相同的问题,但仍然找不到明显的解决方案,所以我不得不自己弄清楚。它与文档中的完全一样 - 您提到的这个解析器仅在输入插件中用作解析器部分(仅限“in_tail”)。不幸的是,它在过滤器插件中不起作用。

    但对我来说,这个插件有帮助: https://github.com/fluent-plugins-nursery/fluent-plugin-concat

    您只需在执行此连接的主要过滤器部分上方添加一个过滤器部分,例如我的例子看起来完全像这样(真正的新日志的指标是时间戳,如果没有时间戳,它总是出现问题的错误堆栈跟踪):

    <filter XYZ.**>
      @type concat
      key log
      multiline_start_regexp /\d{4}-\d{1,2}-\d{1,2}/
    </filter>
    <filter>
       # here the original filter
    </filter>
    

    【讨论】:

    • 是的,我前段时间也发现了类似的东西。不幸的是,这仍然存在问题,如果堆栈跟踪是最后一条日志消息,它会阻止消息。有一些超时和错误处理的解决方案。有用。但似乎不是最好的解决方案:/
    • 嗯实际上为什么超时不是很好的解决方案(这个插件中的'flush_interval')。干净的解决方案有“multiline_end_regexp”但是如果您无法指定结束条件并且多行来自单个事件(可能是您的情况)并且一段时间没有新事件那么恕我直言,这是唯一且干净的解决方案甚至健壮。如果您设置 timeout=1s 是否会伤害您,日志出现在弹性事件后不是 1ms 而是事件后 1s?我猜流利的刷新间隔->弹性你有更高的,但是。
    • 我觉得它“不太好”,因为超时会使消息处于某种错误状态,然后您需要考虑这一点(默认情况下,它们不会像所有其他消息一样处理)。这些额外的过滤器和映射器来处理这些消息并将它们恢复到“正常处理”。这看起来和感觉像是一种解决方法。
    猜你喜欢
    • 1970-01-01
    • 2022-11-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-05-15
    • 2020-09-16
    • 1970-01-01
    相关资源
    最近更新 更多