使用 Fluent Bit 实现多云可观测性

多云和混合 IT 运维并不奇怪，虽然超大规模化者希望我们将工作负载留在他们的云上，但这并不现实。毕竟，不同的云有不同的优点和缺点。有时，不同的特性并不能驱动云的选择。Fluent Bit 是 Fluent CNCF 项目的一部分，它提供了收集可观测性数据（代表是经典的 日志、跟踪和度量三大支柱）的能力，然后将这些事件进行转换、过滤并路由到适当的工具中。因此，在我们考虑 Fluent Bit 在多云场景中的作用之前，让我们先回顾一下多云环境中所涉及的驱动因素和挑战。

发散与自治

对于大型组织来说，多云方式并不总是来自于战略规划，并试图将一切与单个供应商绑定保持一致来最大限度地提高购买力。合并和收购历来被认为是多云的驱动因素之一（例如，文章中提到的 Thoughtworks）。然而，更常见的情况可能来自于本地或灰色 IT 部门做出的本地化选择，以及部门或业务单元具有一定程度的自主权。虽然自治本身很适合敏捷，但它也可能带来挑战，尤其是当本地解决方案获得吸引力并在组织内得到更广泛的采用，或者是被确定为与更广泛的组织合规义务不完全一致时。

图 1：本地化解决方案如何发展到需要企业级支持

将本地化的运维流程引入到组织更广泛的韵味中可能是局势紧张的根源。在操作上，本地团队将乐于使用他们自己的工具，但像安全这样的专业团队会使用他们的方法来管理更广泛的可见性，并了解因果关系。不仅如此，这些其他的团队也可能在不同的云上工作。这就是允许将可观测性数据路由到各种工具的技术的众多好处之一（我们将很快讨论到 Fluent Bit 的这个方面）。

通过允许不同的团队使用他们自己喜欢的工具，分发可观测性数据可以帮助解决这一挑战。相应的工具可以部署在不同的云中，企业范围 / 集中式的功能通常托管在战略云平台上。

成本效益

无论一个组织是如何应对多云环境的，它都需要对其 IT 有一个端到端的了解，以便识别何时出现问题以及相应的因果关系。

中心化的 IT 团队通常会被视为一种开销，因此存在着用更少的资源做更多事情的持续性压力。从运维流程到安全性上都是这样。因此，任何使工作更快捷、更容易的改进都是积极的——从整合通用的可观测性工具和仪表板到更快地识别问题或确定何时采取预防措施。正如我们将要看到的，Fluent Bit 可以帮助简化这些挑战。但是，简单地整合来自多个云的所有可观测性数据可能是昂贵的；日志和跟踪的量可能会非常大，并且度量通常是以高频形式生成的。所有这些都会产生网络成本，尤其是数据出口成本，即使我们看到的是每小时每服务几美分，它也会迅速增涨。因此，我们需要找到一种有效的策略——这是 Fluent Bit 可以帮助我们的另一个方面。

Fluent Bit

有必要介绍一下 FLent Bit 的背景，以了解它是如何帮助我们的，因为这可以帮助我们深入了解它的一些重要特征。Fluent Bit 与 Fluentd 来自同一个 CNCF 项目，在 Fluentd 成立的早期，它作为 CNCF 的一部分，在很大程度上是“小弟弟”。Fluent Bit 是物联网用例的理想选择，它占用空间非常小。它可以收集日志并将其传递以进行处理，通常是通过它的兄弟 Fluentd。但在过去的几年里，Fluent Bit 已经走出了其兄弟的阴影。这是由云原生对拥有更小、更高效的可执行文件的关注所驱动的。Fluent Bit 是用 C 语言构建的，可使用 C、Go 和 WASM 进行扩展，既可以创建原生二进制文件，也可以使用 LuaJIT 进行定制。

Fluent Bit 除了可扩展性之外，其支持常用标准的方式也很有影响力。因此，除了熟悉的开放遥测协议（Open Telemetry Protocol ） 和能够作为开放遥测收集器（Open Telemetry Collector）发挥作用外，它还可以与现有的 Fluentd 部署无缝互操作，并在“插件”中进行编译，允许数据被获取并发送到许多不同类型的端点，从 Log4J、Apache 和 Nginx 日志文件到 Kafka、TensorFlow 和社交通知渠道的输出。

这些技术是 Fluent Bit 早期应用于物联网（IoT）用例的部分原因，因为代码可以为专业硬件以高效且占用空间小的形式编译。随着云原生和 Kubernetes 大规模地推进更小、更高效的二进制文件（Windows 上为 22MB，而 Fluent 为 100MB），这些性能优势也带来了成本节约（尤其是在超大规模下）。然而，云也是人工智能 / 机器学习的一大推动者，因为我们可以“分时共享”大量密集的 GPU，这些 GPU 可以使用 Fluent Bit 进行监控。

它可以充当 Prometheus 的代理和所有信号类型的 OpenTelemetry 收集器。它很容易适应 Kubernetes 生态系统，支持传统环境，并无缝插入到我们可能使用 Fluentd 的地方。

Fluent Bit 提供了一个适应性很强的单代理替代品，可以支持我们所需的工具来询问和可视化正在发生的事情。这意味着我们可以极大地简化我们的代理部署需求：部署 Fluent Bit 后无需再部署 Prometheus 代理、用于收集操作系统级日志的代理、OpenTelemetry 收集器等。

Fluent Bit 的功能使我们能够转换正在发生的事件，从日志中提取度量（例如，日志流中每分钟有多少错误），并将日志表示转换为行业标准化的度量或跟踪。执行这种转换的能力使团队能够在不造成重大破坏的情况下引入新的可观测性工具和技术。例如，如果开发团队在构建时采用代码的自动插装，或者使用诸如 Istio 之类的服务网格来生成跟踪数据，但核心运维工具尚未跟上处理跟踪数据的步伐，我们就可以将跟踪和度量转换为日志。反之，对于可能从其日志中获得跟踪和度量的遗留应用程序，也没有人想要更改它来从支持此类数据的可观测性堆栈中获得更多的见解。

最重要的是，由于 Fluent Bit 是通过配置文件驱动的，因此在我们发展实践和技术的过程中，可以很很容易的以简单、迭代的方式推出更改，从而避免进行破坏性更改。

多云环境中的 Fluent Bit

正如我们已经看到的，Fluent Bit 提供了许多功能来调和并支持多种工具以及重叠的技术或运维工具。我们可以支持最新、更成熟的监测和可观测性方法，并有可能取代多个数据收集代理。我们的运维占用空间小，效率高。

这些都是支持 Fluent Bit 的论据，但它在多云用例中的独特之处是什么呢？Fluent Bit 中使用的技术（以及它是一个开源解决方案的事实）意味着它几乎可以在任何地方运行，包括跨多个云。

数据处理和过滤是多云的重要组成部分；可观测性是冗长的（特别是跟踪和日志），并且会消耗大量带宽，因此也会消耗成本。出口的确切成本可能会很复杂，因为它们可能会根据以下几个因素而变化：

• 在四大云供应商中，只有甲骨文在云区域上费用保持不变（当这种情况发生时，美国和欧洲区域往往更便宜，而亚太和拉丁美洲则更贵）。

• 分层——供应商将根据数量、承诺的消费量等对其定价进行分层。

• 大多数供应商将对在其云区域之间流动的数据收费。

• 用例——在某些用例中，例如服务迁移或离线数据传输，数据出口成本可能会降低或免费。

我们观察到每 GB 的价格高达 0.16 美元。按照这个价格，一台服务器每小时生成 1 GB 的日志、跟踪和指标，全天侯运行，每月的成本为 115 美元。但是谁会运行单服务器解决方案呢？因此，如果我们能够制定一项战略，在不影响支持团队运维效率的情况下，将这一成本降低 10%，我们将节省大量的资金。

Fluent Bit 能够过滤并与许多不同的工具交互，这意味着可以很容易地配置它来过滤掉嘈杂的日志，并将日志临时存储在性能（和成本）较低的服务器本地存储中。最终的结果是，如果认为有必要，日志是可以检索的，但希望在 99.99% 的情况下，它们对需求来说是多余的。例如，应用程序可能会定期报告它们还活着，状态良好。与其在网络上发送所有这些事件中的每一个，不如简单地配置 Fluent Bit 来排除此类日志事件，或者更好的是，只共享从一个云到中心位置的日志（事实上，每 5 分钟就能观察到 x 个这样的日志，因此信息的缺失不会成为一个问题）。因此，我们得到了一个更像下图的架构：

图 2：帮助降低数据成本的简单顶层架构

这个想法并不新颖；我们经常将其视为“云边缘”运维的一个案例。如果中心化运维团队使用多种工具，它会变得更加聪明。所有应用程序都需要重叠的可观测性数据，因此我们解决了本地路由到运维基础设施的问题，限制了任何重复的流量。

观察有地理分布的应用实例

我们也遇到过这种中立性的变体。如前所述，法规和合规性要求可能意味着需要将相同的解决方案部署到多个云中。然而，我们仍然希望有一个核心来管理和观测整体性能，这样它们就不需要本地敏感数据了。相反，它们需要整合显示哪些部署是好的或需要干预的视图。因此，过滤和提取指标度量和警报的智能可以与应用程序一起在本地部署。但它提供了全局监控，因此支持团队可以很容易地看到哪些部署是需要关注的。

这种方式并不新颖；托管服务解决方案通常采用这种方式——它们的中心云在单个云中具有所有的运维可观测性仪表板和知识指南——但需要登录到远程云中去执行修复。

Fluent Bit 可以让我们通过过滤或派生地理分布部署中的相关事件，并将其转发到中央服务上，同时屏蔽或删除任何无法分发的敏感值来实现这一点。不仅如此，当我们转发数据时，中央服务将需要知道事件源，例如哪个 Kubernetes 集群是事件源；这可以通过插件（例如 Kubernetes 插件）注入到可观测性事件中。

标准化数据采集——本地可视化

Fluent Bit 能够脱颖而出的最后一个用例是，构建的解决方案与供应商无关，通常采用基于 CNCF 的技术栈。然后，收集的可观测性数据通过一个集中式节点被定向到云域。这意味着一个 Fluent Bit 节点需要支持本地可观测性产品的特定集成。对于主要的供应商来说，这可能会使用行业标准的数据定义来公开，例如 Fluent Bit 熟悉的 OpenTelemetry 的 OTLP。

然后，团队对监控可视化进行定制，以使用云本地工具。他们甚至可以将 Fluent Bit 数据反馈与本地云特定的监控点（如 CloudWatch）融合在一起（这通常是免费提供的，因此 Fluent Bit 不会产生计算成本）。从使用同一供应商或同一时间使用的多个云的意义上说，这不是多云。但这对软件供应商来说却意义重大，因为他们正在以一种客户不需要侵入或理解配置的方式提取应用程序的监控。当在 Kubernetes 风格的环境中运行时，他们只需使用 Fluent Bit Feed，并使用来自 Fluent Bit 的数据，这在所有部署中都是一样的，通过控制工具甚至仅使用 Kubernete Operators 就能来控制事情。

结     论

在处理多云时，无论是针对单个企业视图的跨多个云的集中化，还是跨多个云分布的同一解决方案，我们都需要控制数据流，以帮助控制成本，同时不影响团队效率（甚至解决组织责任、职责和文化差异问题）。

数据在云或云区域之间流动通常意味着会跨越法律边界。如果我们的数据包含 PII 等敏感数据，我们不仅会面临成本问题，还会面临法律的约束和义务 (例如，数据主权)。

Fluent Bit 占用空间小、效率高，几乎可以部署在任何地方，从而实现了这一目标。我们可以整合足够多的数据——如果必要的话，构建聚合摘要——但也可以将可观测性数据保留在某些在需要时可以轻松提取的位置。

我们可以将正确的数据提供给不同的工具，用于不同的相关可观测性任务，从安全到专业的应用程序运维视图，以一种尽可能有效的方式来支持团队。

由于 Fluent Bit 可以近乎实时地收集事件，我们可以从在问题开始发生时检测到问题，转变为在收集事件时实际识别警告信号，并创造积极主动的机会。

 作者介绍

Phil Wilkins 在软件行业拥有 30 年的工作经验，工作环境从跨国公司到初创企业再到最终的用户组织。Phil 专注于监控、API、集成和开发技术以及科技，并在 Industries Group 担任 Oracle 的云架构师和布道师。Phil 撰写了关于 Fluent Bit 和 Fluentd 的书籍，并与人合著了关于 API 和集成开发的书籍。他还是一名博客作者和科技期刊的撰稿人。Phil 在世界各地的会议上都做过演讲。LinkedIn

原文链接：

https://www.infoq.com/articles/multi-cloud-observability-fluent-bit/

声明：本文为 InfoQ 翻译，未经许可禁止转载。