Adobe Firefly：借助Amazon Managed Prometheus简化可观测性
内容提要
Adobe Firefly采用AWS Amazon Managed Prometheus替代自建Prometheus，解决GPU训练集群高基数指标查询性能问题。迁移后查询速度提升28倍以上，支持24小时观测窗口，降低运维负担，并计划扩展至多租户可观测性架构。
延伸解读
迁移策略：增量采用而非全量替换
Adobe并未一次性弃用自建Prometheus，而是采用Amazon Managed Service for Prometheus的托管采集器，与现有部署并行运行，仅接管发往托管工作区的指标采集。这种增量迁移方式降低了切换风险，保留了原有工作流，为其他有类似需求的企业提供了可借鉴的路径。
性能提升的量化对比
迁移后，查询性能提升显著：4小时窗口快3.5倍，12小时快22.6倍，24小时快28.8倍。此前60秒超时或2分钟部分返回的查询，现在约10秒完成。这凸显了托管服务在高基数、高容量时序数据查询上的优势，尤其适合GPU训练这类大规模监控场景。
运维负担与成本考量
Amazon Managed Service for Prometheus无需代理和额外配置，数据与控制组件均完全托管，显著降低了运维开销。但需注意，该服务与Amazon Managed Grafana均为付费服务，费用基于指标摄入、存储和查询量。企业在评估时应结合自身规模估算成本，避免仅关注性能提升而忽视费用。
Q&A
Adobe Firefly为什么从自建Prometheus迁移到Amazon Managed Prometheus？
因为随着Firefly采用率增加和训练任务扩展，自建Prometheus无法满足大规模GPU训练集群的高基数指标查询性能要求，查询速度慢，且运维负担重。迁移后查询性能提升28倍以上，支持24小时观测窗口，并降低运维负担。
Adobe Firefly的GPU训练集群规模有多大？
训练任务可运行在数千个计算节点和GPU上，例如2000个节点、16000个GPU，每30秒抓取一次，单个查询窗口可产生超过10亿个数据点。
Adobe Firefly迁移到Amazon Managed Prometheus后查询性能提升了多少？
查询性能提升超过28倍，具体为：4小时窗口快3.5倍，12小时窗口快22.6倍，24小时窗口快28.8倍。之前60秒超时或2分钟返回部分结果的查询，现在约10秒完成。
Adobe Firefly如何将指标迁移到Amazon Managed Prometheus？
Adobe使用Amazon Managed Service for Prometheus collector（托管抓取器）从Amazon EKS训练集群抓取指标并直接发送到Amazon Managed Service for Prometheus工作区。托管抓取器与自建Prometheus并行运行，仅接管发往托管服务的指标抓取，保留现有Prometheus设置，实现增量迁移。
Amazon Managed Prometheus相比自建Prometheus有哪些优势？
优势包括：大规模高基数时序数据查询性能快；内置高可用性；无需代理，迁移简单；每个工作区支持高达5000万个活跃时间序列，可扩展至10亿；与Amazon EKS和Amazon Managed Grafana原生集成；运维负担小，数据和控制组件完全托管。
Adobe Firefly迁移后观测窗口有什么变化？
迁移后，基础设施用户现在可以查看24小时窗口的指标，而之前实际限制为6小时。这对于跨越256个或更多节点的大型长期训练任务尤其重要，有助于查看任务完整生命周期，识别性能下降并关联基础设施事件。
Adobe Firefly未来在可观测性方面有什么计划？
Adobe和AWS正在合作，将托管Prometheus扩展到其余指标层，构建多租户、高可用的可观测性架构，以支持Adobe Firefly全规模的遥测数据。
