Fluentd｜统一的日志记录层

客座文章最初由Ran Ribenzaft在Epsagon上发表

https://epsagon.com/blog/cncf-tools-overview-fluentd-unified-logging-layer/

如今，从内部解决方案到开源工具，再到企业级的第三方服务，各种各样的数据处理可能会让人应接不暇。监管要求也不是玩笑。有些法律规定哪些必须记录，哪些不能记录；哪些必须保存多年；哪些必须在第二天或用户要求时丢弃。所有这些构成了操作员的日常工作，前提是他们首先找到日志。

如果你发现需要日志管理，那么统一的日志记录层是比内部解决方案更好的选择。在这篇文章中，我们将概述一个可以帮助你实现这一目标的工具：Fluentd。首先是一些背景知识。

过去的好日志

在裸机或宠物虚拟机（VM）的美好时代，管理员可以通过ssh和tail访问感兴趣的日志。这已经证明足够了，因为工作负载通常是计划的、手动运行的，并绑定到一台机器上。现在，这被称为日志流水线，它是由一个应用程序写入磁盘，有时通过syslog或定期进行备份组成的--按照现代标准，这并不复杂。随着时间的推移，业务需求不断增长。对日志进行了聚合、处理和分析，以提供有价值的见解。每一步都是典型的用脚本铺就的，这些脚本被小心翼翼地粘合成更大的系统。

然后是容器、一次性VM和PaaS环境的时代，它们的可用性承诺远远超过一台机器。目前，我们可能不知道特定服务在哪个VM（更不用说物理机器了）上运行。这绝对没问题--我们有软件来解决这个问题。然而，出现了一个问题--如果不知道日志的位置，如何访问它？

过去复杂的流水线迫切需要一个更优雅的解决方案。在胶水开始磨损之前，你所能施加的压力是有限的。

进入Fluentd

Fluentd承诺帮助你“构建统一的日志记录层”（如网页所述），而且它有充分的理由这样做。首先，这不是一个刚刚发布到beta版的全新工具。Fluentd从2011年就已经出现了，并被AWS和谷歌推荐在它们的平台上使用。后者甚至使用修改版的Fluentd作为默认的日志记录代理！

但成熟只是选择一个特解而不是另一个特解的原因之一。如果产品是有用的，它需要与系统的其他部分很好地集成。而Fluentd的集成能力是它的强项。由于其使用插件的模块化方法，你可能已经了解了官方发行版所提供的内容。

你可以找到数据源（如Ruby应用程序、Docker容器、SNMP或MQTT协议）、数据输出（如Elastic堆栈、SQL数据库、Sentry、Datadog或Slack）和其他几种过滤器和中间件的插件。如果你仍然不满意，因为你定制的网络路由器不受支持，你可以用Ruby编写你自己的插件！

所有日志解析、过滤和转发都位于代理配置文件中。其格式类似于Apache或Nginx日志，因此操作人员应该熟悉它。很有可能，它看起来比大多数定制的脚本干净得多，这些脚本粘在一起形成了一个流水线。

让我们构建一个流水线

无论你是rsyslogd的爱好者还是广泛使用应用程序容器，Fluentd都为你提供了帮助。假设你想要使你的遗留解决方案现代化，并使用Elasticsearch来存储rsyslog事件日志，你的示例流水线可能如下所示：

<source>
  @type syslog
  port 32323
  tag  rsyslog
</source>

<match rsyslog.**>
  @type copy
  <store>
    @type elasticsearch
    logstash_format true
    host elasticsearch.local
    port 9200
  </store>
</match>

这是所有吗？差不多了！你仍然需要配置rsyslogd来指向Fluentd代理。然后就完成了。

配置文件可以有多个源和多个输出。如果你刚刚引入了Docker，那么你也可以重用相同的Fluentd代理来处理Docker日志。与前面的示例一样，你需要做两个更改。首先是运行Docker与Fluentd驱动程序：

docker run --log-driver=fluentd --log-opt tag="docker.{.ID}}" hello-world

二是对Fluentd配置进行相关更改：

<source>
  @type syslog
  port 32323
  tag  rsyslog
</source>

<source>
  @type forward
  port 24224
  bind 0.0.0.0
</source>

<match *.*>
  @type copy
  <store>
    @type elasticsearch
    logstash_format true
    host elasticsearch.local
    port 9200
  </store>
</match>

就像使用多个源一样，可以配置多个输出。当然，它们中的每一个都可以通过标记进行过滤！考虑到我们希望将rsyslogd和Docker日志都转发到Elasticsearch，并将Docker日志输出到stdout进行调试，我们将使用以下配置：

<source>
  @type syslog
  port 32323
  tag  rsyslog
</source>

<source>
  @type forward
  port 24224
  bind 0.0.0.0
</source>

<match *.*>
  @type copy
  <store>
    @type elasticsearch
    logstash_format true
    host elasticsearch.local
    port 9200
  </store>
</match>

<match docker.**>
  @type stdout
</match>

你认为它提供了承诺的清洁配置吗？我们认为是的！

CNCF的一分子

由于本文是系列文章的一部分，所以我们必须提到Fluentd与CNCF（Cloud Native Computing Foundation，云原生计算基金会）的关系。Fluentd于2016年被CNCF采纳，是第六个成熟到可以毕业的项目。这意味着它已经加入了一个联盟，与Kubernetes、Prometheus、Envoy、CoreDNS和containerd一起。。

https://epsagon.com/blog/cncf-tools-overview-are-you-cloud-native/

那么，Fluentd和CNCF的朋友们玩得怎么样呢？我们已经讨论了数据源和输出的集成。很自然，Fluentd也支持Prometheus的监测。推荐使用这种方法来监视Fluentd的行为。其他可用的方法是Datadog或REST API。对于部署到Kubernetes集群，你可以使用一个官方的稳定Helm chart。是的，Helm chart也有Prometheus监控功能，所以你可以在一个简单的步骤中配置它。

其他选择

Fluentd解决了分布式系统中与日志记录相关的许多问题。它可以处理从网络硬件到操作系统和编排事件的所有事情，一直到应用程序逻辑。稳定、成熟，是CNCF的推荐。它还可以很好地集成各种数据源和存储，以及其他CNCF产品。不过，这并不是该领域唯一的产品。

你可能经常听说Elastic堆栈被称为ELK堆栈。中间的“L”代表Logstash，在很多方面与Fluentd相似。与Fluentd一样，它支持许多不同的源、输出和过滤器。配置文件看起来有点奇怪，尽管这可能只是个人偏好的问题。

在这个领域还有一个新的竞争者：Vector，它承诺有很好的性能和内存效率。与用JRuby编写的Logstash或用Ruby编写的Fluentd不同，Vector是用Rust构建的，因此它应该提供更少的开销和更好的稳定性。你可以使用Vector中的Lua来编写过滤和转换逻辑，如果你不想为此编写完整的插件，这也很有帮助。主要的缺点？它仍在积极开发中，在撰写本文时甚至还没有1.0版本。

其他值得考虑的备选方案包括Filebeat（也是Elastic堆栈的一部分）和SaaS解决方案（如Epsagon）。如果你想马上开始，一个托管服务可能需要较少的设置。

总结

如果你正在寻找一个适合你使用的其他CNCF项目的解决方案，那么Fluentd似乎是最好的选择。对于新项目和缺少日志记录层的项目，这是一个明智的选择。如果你已经投资了Logstash，那么这两者之间的差异并不大，所以最好保持当前的设置。如果你对Logstash安装感到厌倦，那么最好保持警惕，直到Vector变得稳定。在大多数情况下，上述统一解决方案比创建和维护自定义流水线更好。