基础设施可观测性对于维持系统正常运行时间、优化云环境以及保护云边界安全至关重要。云环境会产生大规模的可观测性数据。VPC Flow Logs（流日志）、ELB Access Logs（访问日志）、CloudTrail 和 CloudWatch 日志可以轻松达到每秒数十万个事件。处理如此巨大的规模本身就是一个复杂的问题。
今天，我们要介绍EDOT Cloud Forwarder，它构建于 OTel Collector 之上，是将你的云环境连接到 Elastic Observability 的最简单、最快，可能也是最“无聊”（意味着省心）的方式，并且它现已在 AWS 上正式发布。使用 EDOT Cloud Forwarder，你可以在几秒钟内上手，获得整个云资产的可观测性，并轻松处理任何体量的遥测数据。
在 District Line 的列车上部署 Cloud Forwarder
于是，我开始着手在我的 AWS 账户中部署 EDOT Cloud Forwarder。我是在上下班通勤的路上做的，仅仅依靠还算不错的 4G 信号，并祈祷我那 27% 的电池电量能够撑住。
我点击了 Terraform 模板的部署按钮并开始等待。我开始看到事件流入 Elastic Observability。
当列车驶入 Putney Bridge 站时，日志流达到峰值，屏幕上滚动着每秒一百万个事件（1M EPS）。
部署完成后，我得到了我能期望的最好的“三个零”：
- 零人工干预（Zero Intervention）：我看着流量攀升至整整 100万 EPS。Lambda 函数自动从几个实例横向扩展到所需的 60-65 个并发执行。无需任何手动调整。扩缩容是即时且自动的。
- 零数据丢失（Zero Data Loss）：它实现了稳定的处理速率，每一个事件都被索引到了 Elasticsearch 中。
- 零闲置成本（Zero Idle Cost）：当没有事件时，Cloud Forwarder 会缩容至零——它没有固定的基础设施成本。你只需为数据处理的那一刻付费，而无需为长期闲置的超额配置服务器付费。
就在列车停稳之前，我看了一下在 Parsons Green 站和 Putney Bridge 站之间运行 Cloud Forwarder 这两分钟的总成本——我们转发了大约 120GB 的遥测数据，总成本不到 0.10 英镑。当然，除非你把 2.50 英镑的火车票也算进去！
让任何规模的可观测性变得简单
开始观测你的基础设施是很难的，而一旦它变得可观测，从中挖掘出可操作的价值需要从海量的遥测数据（有时每秒数百万个事件）中进行筛选和提炼。
适用于 AWS 的新版 EDOT Cloud Forwarder（GCP 和 Azure 版本也处于预览阶段）非常易于部署，只需一个 Terraform 模板即可。为了确保容易上手，我们将其设计为尽可能接近一键部署：
只需点击下面的链接，即可在你的 AWS 账户中启动 CloudFormation 堆栈：
最棒的部分是什么？这种开始使用 Elastic Observability 的最快方式可以扩展到任何规模的工作负载！有了 EDOT Cloud Forwarder，你只需这就一个解决方案，它既可以自动缩容至零，也可以扩展到每秒处理数百万个事件。
那么，什么是 EDOT Cloud Forwarder？
EDOT Cloud Forwarder 是一个无服务器（Serverless）的 OpenTelemetry 收集器，在 AWS 上作为 Lambda 函数运行。在 AWS 中，它由事件触发，处理来自 VPC Flow Logs、ELB Access Logs、CloudTrail、CloudWatch Logs 和 CloudWatch Metrics 等服务的日志和指标。
它具有以下核心功能：
- 从云服务提供商收集可观测性和安全数据
- 将数据解析为原生 OpenTelemetry 格式
- 通过 OTLP 转发数据
- 根据流量自动扩缩容
适用于 AWS 的 ECF 是纯无服务器解决方案，无需管理虚拟机、容器或 Kubernetes 控制平面。
下车后，一个更受控的场景
为了进行更受控的测试场景，我们使用了生成的合成 VPC Flow Log 数据，以展示 EDOT Cloud Forwarder 如何轻松可靠地维持每秒一百万个事件且无数据丢失。
在配置方面，我们保留了所有 EDOT Cloud Forwarder 的配置/设置为默认值。在 AWS 中，Lambda 的最大并发数默认为 5。如果保持默认值 5，预期可以达到约 50k EPS。对于我们的场景，我们将此值提高到 100，以确保我们的测试有足够的余量。
我们分 10 分钟一个阶段运行该场景，每个阶段的数据量都更大。我们在该阶段内保持摄入量平稳，以便为我们提供短期稳态窗口来抓取指标。
我们在所有场景阶段均未遇到错误，未出现预期行为之外的重试，在摄入的 54 亿个事件中没有数据丢失。
写给可观测性极客的数据统计
因为我们知道你们喜欢这些：
增量负载阶段
我们使用增量负载阶段测试了 EDOT Cloud Forwarder，逐渐将流量从大约每秒 300,000 个事件增加到每秒超过 100 万个事件。
下图显示了整个测试期间的 Elasticsearch 摄入率。你可以看到当我们通过六个不同阶段提升时的清晰进程，每个平台期代表 10 分钟的稳定期。
系统平滑地处理了每次流量增加，最终达到了持续的每秒 100 万个文档的摄入量，且没有瓶颈或数据丢失。
Lambda
如 CloudWatch 指标所示（无需手动调整）。在整个测试期间未发现错误和限流。
并发执行数
同时运行 60 到 65 个实例。
Lambda 平均执行时间
每次执行大约耗时 5 秒。
内存使用率
内存使用稳定在 450 MB 左右，低于 512 MB 的默认限制。
Elasticsearch 索引
Elasticsearch 每秒索引一百万个文档，几秒钟内即可在 Discover 中看到事件，没有索引延迟或瓶颈。
设计高效：基于 S3 的 Lambda 实现 1M EPS
在 AWS 上以 1M EPS 运行 ECF 的成本约为每小时 3.87 美元。其中大约 66%（每小时 2.57 美元）是数据传输费用（同区域），34%（每小时 1.32 美元）是 Lambda 计算费用，不到 1% 是 S3 请求费用。
这是完全无服务器的，没有闲置成本。你只需在转发事件时付费。对于 S3，数据以大对象预批处理的形式到达，这保持了较低的 Lambda 调用次数并严格控制了计算成本。在持续吞吐量下，Lambda 成本与 EKS 相当——但无需集群管理或闲置容量。
其他选项：在 EKS 上运行 OTel Collector 处理 1M EPS
在 EKS 上为 1M EPS 配置 OTel Collector 的基准成本约为每小时 3.69 美元。其中大约每小时 0.33 美元是计算相关费用（EC2 节点、EKS 控制平面和 EBS）。其余来自数据传输和 SQS，这部分随流量扩展，不随利用率变化。
闲置计算对 EKS 实际成本的影响
考虑到 EKS 通常是为峰值负载预置的，计算部分的实际成本会受到闲置容量的影响。在100% 利用率下，总成本为每小时 3.69 美元。在50% 利用率（吸收突发流量的常见基准）下，总成本上升至约每小时 4.02 美元。在30% 利用率下，它进一步增加到约每小时 4.46 美元。
为工作量付费 vs 为容量付费
适用于 AWS 的 ECF 提供了 1M EPS 的处理能力，成本与峰值利用率下的 EKS 相当，且无需闲置计算或容量规划。EKS 可以达到同样的峰值吞吐量，但随着平均利用率下降，总成本会进一步增加，因为必须提前预置计算容量。
结论
一个枯燥的事实：对于 EDOT Cloud Forwarder 来说，每秒一百万个事件与其他任何工作负载没有什么区别。
由于无需部署基础设施，没有闲置成本，也就无需手动扩缩容，我想最好的做法就是停止过度思考，开始转发数据！这就像踏上了线路上最快的列车：你只需上车，就能立即踏上前往目的地的旅程，毫不费力地应对任何距离，或者在这种情况下，应对任何数据量。
所以，我们发布了它。适用于 AWS 的 ECF 现已正式发布。
