RSS DEV 社区
关注
CloudWatch 到 OTel：拆解可观测性桥接模式
CloudWatch 到 OpenTelemetry 的桥梁模式是金融平台将 AWS 指标整合到统一可观测性后端的一种常见解决方案。其主要目的是通过转发 AWS 服务的指标至支持 OpenTelemetry 的外部系统，来解决可观测性碎片化问题。该模式通常涉及 AWS 服务将指标发送至 CloudWatch，随后由 CloudWatch Metric Streams 捕获或通过 GetMetricData API 获取。这些指标通常由 Lambda 函数或 OpenTelemetry Collector 转换为 OpenTelemetry 格式，再发送至 Datadog 或 Grafana 等可观测性后端。
然而，这一“显而易见”的解决方案在指标新鲜度和 API 成本至关重要的金融高吞吐环境中隐藏着复杂性。该模式主要有两种摄入路径：CloudWatch Metric Streams 结合 Kinesis Firehose 提供低延迟和可预测的成本，而通过 GetMetricData 进行轮询则提供细粒度控制，但存在触及 API 速率限制并产生高昂成本的风险。一个健壮的转换 Lambda 函数必须具备幂等性，针对外部端点实现熔断器机制，并配置带有告警的死信队列（Dead Letter Queue）。
当需要支持 OTLP 的外部后端、指标流量足以证明流式传输的成本合理性，且需要 60 秒或更短指标新鲜度服务等级目标（SLO）时，该模式适用。它还有助于将可观测性与 AWS 解耦，并实现追踪与指标的关联。安全至关重要，需实施严格的 IAM 策略（包含资源条件）、对传输中的数据使用 KMS 加密，并控制网络出站流量。应避免的反模式包括：简单的轮询方式、缺乏适当错误处理或预留并发设置的 Lambda 函数，以及试图通过此专注于指标的桥梁转发日志或追踪。架构良好的实现应优先在流级别过滤指标，使用高效的缓冲机制，对桥梁本身进行可观测性监控，并采用严格的安全措施。
