本文是对 Ceilometer: Uber’s Adaptive Benchmarking Framework 的整理与翻译。内容结构概览本文主要分为七部分Uber 为什么需要一个统一的自适应基准测试平台。Ceilometer 要解决哪些传统 benchmark 流程中的问题。Ceilometer 的整体架构编排、执行、结果存储、数据仓库和分析服务。Ceilometer 支持哪些测试框架合成 benchmark、有状态服务、无状态服务和机器学习场景。Ceilometer 的两个核心应用服务器规格选型和基础设施变更验证。Uber 后续希望在 Ceilometer 上继续增强哪些能力。从这篇文章可以总结出的基础设施工程经验。一、背景在 Uber 的规模下benchmark 不能再靠手工拼凑对 Uber 这样的超大规模基础设施系统来说每一种新的服务器型号、每一次内核升级、每一个配置调整都不能直接进入生产环境。因为这些变化表面上看可能只是硬件、系统或参数层面的微调但实际影响可能会扩散到数据库、缓存、微服务、机器学习任务、批处理系统以及整个平台的成本效率。过去这类验证工作通常依赖工程师手工组合测试环境、测试脚本、分析表格和经验判断。对于单个团队来说这也许还能勉强运转但当问题变成“要在大量服务、大量硬件形态和多种运行环境中持续验证性能与可靠性”时手工流程就会暴露出很多问题。原文提到在 Ceilometer 出现之前Uber 的性能验证流程往往是手动的、耗时的而且缺乏统一衡量效率和投资回报的能力。工程师需要把各种临时 benchmark 拼起来结果是验证周期变长、风险增加新技术的采用速度也被拖慢。(Uber)Ceilometer 就是在这个背景下被构建出来的。它是 Uber 内部的自适应基准测试框架用来提供快速、接近生产环境的系统性能信号。它可以用于验证新的云服务器 SKU评估基础设施变更衡量效率优化项目也能帮助 Uber 在大规模上线前测试下一代服务器形态和新的机器学习框架。除了看性能它也强调可靠性会通过长时间运行和压力测试来验证系统稳定性。换句话说Ceilometer 不是一个单纯的“跑分工具”而是一个围绕基础设施生命周期建立起来的 benchmark 平台。它关心的不只是“哪台机器分数更高”而是“这个变化放到 Uber 的真实工作负载里是否更快、更稳、更省钱、更值得上线”。二、Ceilometer 是什么一个自适应基准测试平台Ceilometer 是 Uber 用于性能和可靠性测试的平台。它既可以运行合成 benchmark也可以模拟和评估生产工作负载覆盖有状态服务和无状态服务。平台会自动执行测试、收集性能指标并给出关于资源利用率、成本效率和服务可靠性的分析信号。(Uber)在实际工作流中Ceilometer 会和 Uber 内部已有工具集成自动拉起 benchmark 集群并把 Uber 服务部署到目标机器上。工程师可以通过它发起测试、查看结果、识别性能差异和可靠性风险。这样一来基础设施团队和服务团队可以更快做出决策某个新硬件是否值得采购某个内核升级是否安全某个实例规格是否适合某类工作负载某个配置调整是否会带来性能退化。这类平台的价值在于它把 benchmark 从一次性的工程活动变成了持续化、标准化、可追溯的基础设施能力。如果用一句话概括Ceilometer 是 Uber 用来回答“这次底层变化到底会不会让系统变得更好”的统一测试和分析平台。三、为什么需要 Ceilometer传统 benchmark 流程的问题Benchmark 本身并不新。CPU、内存、磁盘、网络、数据库、缓存、微服务、机器学习框架都可以跑 benchmark。但真正困难的是如何在大规模组织里把 benchmark 做得稳定、可复现、可比较、可解释并且足够低成本。原文总结了 Uber 在引入 Ceilometer 前遇到的几个典型问题。(Uber)1. 测试不一致结果也就难以比较过去很多 benchmark 是由不同团队分别执行的。每个团队可能有自己的脚本、自己的机器选择方式、自己的参数、自己的结果整理格式。这样得到的结果很难横向比较。同一个硬件变更在 A 团队那里可能表现不错在 B 团队那里可能看起来一般。问题不一定出在硬件本身也可能只是测试方法不同。对于基础设施选型来说这种不一致会直接影响决策质量。Ceilometer 通过标准化配置来解决这个问题。测试配置统一后不同工程师执行出来的结果才有可比性才能做到真正的 apples-to-apples comparison也就是在相同条件下比较不同方案。2. 各自为政的测试系统浪费资源在 Ceilometer 之前不同技术栈可能都有自己的性能测试方式。数据库有数据库的 benchmark微服务有微服务的压测框架硬件团队有硬件团队的合成测试机器学习团队又有自己的评估流程。这种方式会造成碎片化工具重复建设、结果难以打通、维护成本很高而且新团队想接入 benchmark 时也很困难。Ceilometer 的思路是把这些 benchmark 实现整合到一个可扩展平台下。不同技术栈仍然可以保留自己的测试特点但执行、数据收集、结果归档、分析入口和对比逻辑尽量统一。3. 测试流程复杂难以规模化一次完整的 benchmark 往往不只是执行一个命令。它通常包括选择目标机器、配置测试环境、部署被测服务、启动负载、采集指标、解析结果、生成报告、和历史基线比较、判断是否退化。如果这些步骤都靠人工完成就需要投入大量工程时间。而且手工过程越多越容易出现操作不一致和结果不可复现的问题。Ceilometer 把主机识别、测试编排和结果解释统一起来尽量让工程师从重复劳动中解放出来。它的目标不是让 benchmark 更“炫”而是让 benchmark 更容易被大量团队反复使用。4. 结果缺少上下文难以产生洞察很多 benchmark 结果最终会被放在表格里。表格本身有数据但上下文不足机器规格是什么对比基线是谁预期 SLA 是什么这组数据是否需要归一化这个变化到底代表性能提升还是退化没有上下文benchmark 就容易变成一堆孤立数字。工程师还需要靠经验去解释这些数字效率低也容易误判。Ceilometer 的报告界面会原生提供关键上下文包括服务器规格、标准参考数据、预期 SLA 和归一化结果使 A/B 测试更容易进行。也就是说它不只是收集结果还会帮助工程师理解结果。5. 测试框架缺少可移植性如果 benchmark 只能在 Uber 内部生产环境跑那它的使用范围就很有限。比如某些新服务器还处在供应商开发阶段Uber 内部环境里还没有实际机器又或者工程师想在开发区、云控制台、外部供应商环境中提前测试。Ceilometer 使用容器化的测试 harness让外部供应商也可以在自己的环境中执行 Uber 标准化的合成 benchmark然后以 JSON 文件形式返回性能数据接入 Uber 的分析体系。这样既扩大了 benchmark 的覆盖范围又保持了数据格式和分析口径的一致性。(Uber)这一点很关键因为硬件和云实例选型往往需要在真正大规模采购或上线前就做判断。可移植的 benchmark 能让 Uber 更早获得信号提前发现风险也能指导供应商优化设计。6. 很多技术根本没有 benchmark 系统在大型组织中并不是每个服务或技术栈都有成熟 benchmark。很多系统只在出问题时才临时压测很难提前判断底层变更会产生什么影响。Ceilometer 试图提供广泛覆盖。它既覆盖 CPU、内存等主要服务器组件也覆盖有状态服务、无状态服务、批处理、机器学习等主要技术栈。这样更多团队可以在统一平台上获得基础性能评估能力而不是每次从零搭建。四、Ceilometer 的架构从测试执行到分析服务Ceilometer 的核心架构是一个分布式 benchmark 系统。它需要支持并行执行大量测试覆盖不同环境和不同工作负载同时保证结果能够被可靠保存、处理和分析。这张图展示了 Ceilometer 的整体数据流。左侧是 benchmark 编排和执行部分右侧是结果存储、数据处理、数据仓库和分析服务。1. Benchmark Orchestration测试编排Ceilometer 会在一组专用 benchmark 机器上编排测试。用户提交测试请求后Execution Service 负责调度执行Dedicated Host Pool 提供可被分配的目标机器被测系统通过 Benchmarking Container Agent 执行具体测试。这种分布式编排方式有两个价值。第一它可以并行执行测试提高效率。第二它可以更接近真实生产环境在多种机器和负载组合下观察系统表现。对于 Uber 这种规模的公司来说benchmark 不能是一个串行、单机、一次性的过程。它必须像其他基础设施任务一样可以被调度、编排和自动化。2. Blob Store结果持久化测试完成后benchmark 结果会被保存到高可用、可扩展的 blob store 中。原始结果被持久化之后后续才能做历史对比、审计和复盘。这一层看似普通但很重要。因为 benchmark 的价值不只在当下。今天跑出的结果未来可能会成为某次硬件采购、某次性能回归分析、某次事故复盘的依据。如果结果只散落在个人电脑、临时表格或一次性日志里就很难沉淀成组织能力。3. Result Ingestion结果摄取与处理原始结果不能直接拿来分析因为不同 benchmark 工具、不同服务、不同运行环境产生的数据格式可能不同。Ceilometer 会把原始结果送到专门的处理服务中完成校验、归一化和增强。这里的“归一化”非常关键。比如不同服务器规格、不同线程数、不同负载曲线下得到的结果不能简单按绝对数字比较。平台需要把数据转成结构化、可比较、可分析的格式才能支撑后续判断。4. Data Warehouse进入数据仓库处理后的性能数据会进入 Uber 的集中式数据仓库。这样一来benchmark 数据就可以和其他平台指标一起分析。例如工程师可以把某次 benchmark 的结果和生产环境资源利用率、故障指标、服务延迟、成本数据结合起来看。这样得到的不是孤立分数而是更接近业务和平台真实影响的判断。5. Analytics Service分析服务最终性能数据会通过专门的 analytics service 对外提供查询和可视化能力。工程师可以用它查看 benchmark 结果、做对比、识别异常、判断退化或提升。上图展示的是不同服务器 SKU 在不同线程百分位下的 NCU 平均得分对比。它不是只给一个总分而是展示在 25%、50%、75%、100% 线程维度下的表现差异。这样工程师可以看出一个规格是在低并发下更强还是在高并发下更稳定。这张图展示了 DeepETA 在不同并发下的每秒预测数量对比。DeepETA 属于 Uber 业务中非常核心的机器学习应用方向之一类似这类图可以帮助工程师判断某个 GPU SKU 或计算平台在模型推理负载下的扩展曲线。五、Ceilometer 支持的测试框架Ceilometer 的一个重要特点是它不只支持一种 benchmark 类型而是覆盖多种测试框架。不同工作负载的性能瓶颈完全不同CPU 密集型任务关心计算能力数据库关心读写吞吐和复制一致性微服务关心延迟和扩展性机器学习推理关心吞吐、并发和硬件利用率。因此一个真正有用的平台必须能适配不同测试场景。1. 合成 benchmark先看基础组件能力Ceilometer 支持大量 synthetic benchmarks也就是合成基准测试。这类测试通常用来压测系统组件或某类操作的最大性能并保证结果可复现。原文提到的工具包括 SpecCPU2017、SPECjbb2015、NetPerf、FIO 等。SpecCPU2017 偏向 CPU 计算性能SPECjbb2015 常用于 Java 服务端性能评估NetPerf 用于网络性能测试FIO 常用于存储 I/O 性能测试。Ceilometer 会根据 Uber 的工作负载需求对这些 benchmark 进行定制。(Uber)合成 benchmark 的价值在于它能提供早期信号。比如某个新服务器还没真正部署 Uber 服务就可以先通过 CPU、内存、网络、磁盘等基础测试判断是否存在明显瓶颈。这对采购决策和硬件优化非常重要。但合成 benchmark 也有局限它只能代表某类标准化压力不一定等同于真实业务表现。因此 Ceilometer 还需要支持更接近生产环境的应用 benchmark。2. 有状态服务 benchmark数据库和存储系统不能只看吞吐Uber 的基础设施里有大量有状态系统比如数据库、缓存和其他存储服务。这些系统的 benchmark 不能只看单机性能还要看复制、持久化、一致性、延迟尾部、不同负载下的读写能力。Ceilometer 为 Uber 的有状态数据库技术提供专门 benchmark并借助 Odin也就是 Uber 的 Stateful Platform来编排这些测试。原文提到这类测试会评估多个关键方面包括不同负载下的读写性能、事务吞吐能力以及复制系统中的数据一致性。(Uber)这类测试的意义在于它能更真实地模拟 Uber 数据基础设施的压力。数据库系统在低负载下表现正常并不代表它能扛住峰值流量单副本表现正常也不代表复制链路没有问题平均延迟好看也不代表尾延迟可接受。Ceilometer 需要把这些因素纳入统一评估。3. 无状态服务 benchmark微服务关注延迟、吞吐和可扩展性Uber 的微服务体系庞大无状态服务是其中非常重要的一部分。对于无状态服务Ceilometer 提供测试环境来评估性能、延迟和可扩展性。原文提到Ceilometer 会利用 Ballast 的自适应负载测试框架来模拟生产流量和访问模式从而评估服务性能。这样可以验证 Uber 的大量服务是否能在波动需求下保持高效和可靠。(Uber)这里的重点是“模拟生产流量”。很多压测工具只能制造固定 QPS 或固定并发但真实生产流量往往有复杂访问模式、突发峰值和不均匀分布。一个微服务在简单压测下表现稳定不代表在真实流量形态下不会出现队列堆积、尾延迟恶化或资源耗尽。Ceilometer 通过自适应负载测试把 benchmark 从静态压力推进到更接近生产行为的验证。4. 机器学习和下一代计算框架原文在开头提到Ceilometer 也被用于测试下一代 SKU 和新的机器学习框架。随着 Uber 的业务越来越依赖 ML基础设施验证就不能只关注传统 CPU 服务还要覆盖 GPU、推理吞吐、模型延迟、并发扩展性和成本效率。上面 DeepETA 的示例图就是这一方向的体现。对于机器学习推理来说不同硬件之间的差异不只是“每秒能跑多少次预测”还包括并发增长后吞吐是否线性提升、是否提前进入瓶颈、单位成本下的性能是否更优。这也说明 Ceilometer 的定位是自适应的它不是固定服务某一种工作负载而是随着 Uber 基础设施演进不断扩展覆盖范围。六、应用场景一服务器规格选型Ceilometer 在 Uber 最常见的应用之一是新服务器类型的 qualification也就是规格验证或形态验证。这个过程通常分阶段进行尤其是当服务器类型还处在供应商开发阶段时。第一阶段供应商可以在自己的环境中执行 Ceilometer 的合成测试套件。测试结果一方面会反馈给供应商用于指导他们优化设计另一方面也会报告给 Uber。Uber 的性能工程师会根据这些结果预测该服务器类型在 Uber 工作负载中的表现并提前判断它是否值得继续投入测试和优化。(Uber)第二阶段当该服务器类型可以进入 Uber 环境测试后Ceilometer 会执行更完整的测试套件包括合成 benchmark 和应用 benchmark。这些应用 benchmark 会根据 Uber 的有状态或无状态场景进行定制。最终结果会被用来和现有生产服务器比较从而判断下一代服务器中哪一种最具成本效益。这张图展示的是 Server SKU A 相对 Server SKU B 在多个 benchmark 项上的性能差异。绿色代表提升红色代表退化。可以看到某个服务器规格在一些指标上可能明显更好例如 mNCU、SPECCPU2017、Stream、Go Cloudflare 等但在另一些指标上可能退化例如 SpecJBB 某些项目或 DeepETA。这正是基础设施选型的难点不存在绝对完美的机器只有更适合某类工作负载的机器。一个 SKU 可能对 CPU 型服务有明显收益但对某些 Java 工作负载或 ML 推理并不占优。Ceilometer 的作用就是把这种差异以标准化、可解释的方式呈现出来。服务器选型最终不是看单项最高分而是看综合效果性能是否提升成本是否下降工作负载是否匹配风险是否可控是否值得替换现有生产机器。另外原文还提到这些测试结果也会反过来用于改进 Ceilometer 自身。比如某些 benchmark 配置需要更新或微调平台就可以根据真实验证结果不断校准使后续测试更准确。七、应用场景二基础设施变更验证除了服务器选型Ceilometer 另一个核心应用是变更验证。在基础设施系统中任何对现有硬件或软件配置的变更都可能引入性能变化。比如内核升级、BIOS 配置调整、云厂商底层升级、实例规格修改、系统库变化、存储参数调整等。这些变化有些会带来收益有些可能引入退化还有些问题只有在特定工作负载下才会暴露。Ceilometer 的做法是针对新配置硬件执行定向 benchmark 测试套件并与服务 owner 合作分析结果。因为每个服务都有自己的特点基础设施团队不能只看通用指标就决定上线。服务 owner 需要确认测试结果是否真实反映服务表现并认可该配置适合自己的服务。(Uber)当发现性能退化或异常行为时Ceilometer 也可以作为诊断工具使用。原文把这个过程分成三步第一步是 isolate也就是定位问题来源。工程师需要找出到底是哪个组件、哪个参数、哪个变更引入了退化。第二步是 reproduce也就是在受控环境中稳定复现问题。只有能复现才有可能真正理解问题特征而不是把它当作偶发现象。第三步是 mitigate也就是实施并测试解决方案。修复不是靠猜而是通过 benchmark 验证修复是否有效是否又引入新的问题。这套能力对于防止生产回归非常关键。很多基础设施事故不是因为完全未知的新问题而是因为某个“看起来安全”的底层变化在特定服务上触发了性能退化。如果能在生产大规模 rollout 前通过 Ceilometer 发现就可以显著降低事故概率。原文还提到Ceilometer 最近扩展到了验证云厂商在 Uber canary 环境中的外部 touchless upgrades。所谓 touchless upgrades可以理解为由外部云厂商执行、对 Uber 来说不需要手工介入的底层升级。即便这种升级由供应商侧完成Uber 仍然需要验证它不会破坏自己的可靠性要求。Ceilometer 在这里就承担了自动化验证和风险发现的角色。(Uber)八、Ceilometer 的未来方向原文在 Future Work 中提到随着 Uber 基础设施继续演进Ceilometer 也会继续扩展。未来重点包括几个方向。1. 更深入地集成 AI/MLUber 希望进一步使用 AI 和机器学习技术来自动化 benchmark 分析预测潜在性能回归并智能识别问题根因。这背后的逻辑很直接当 benchmark 覆盖范围越来越大、数据越来越多时单靠人工看图表会越来越吃力。如果平台能自动识别异常、预测风险、给出根因线索就能让性能工程从“事后分析”逐步走向“提前预警”。原文还提到这种能力未来也可以用于预测现有工作负载的合适资源规格从而优化未充分利用资源带来的成本浪费。(Uber)2. 支持更广泛的技术生态Uber 希望 Ceilometer 覆盖更多技术和测试环境包括新兴基础设施范式以及 Uber 内部所有关键有状态和无状态技术。这说明 Ceilometer 不会被限定为某几个 benchmark 工具的集合而是会继续演进成统一的性能验证平台。只要 Uber 的基础设施继续变化它就需要适配新的硬件、新的运行环境、新的服务形态和新的负载模式。3. 更高级的异常检测在高度动态的环境中性能异常可能非常微妙。平均值可能看不出问题但某个线程百分位、某个并发段、某个尾延迟指标可能已经出现变化。Ceilometer 未来希望实现更复杂的异常检测算法快速发现意外性能偏差。这样可以帮助工程师更早定位和解决细微问题而不是等它们在生产环境中放大。4. 集成利用率指标原文提到Ceilometer 计划扩展指标范围把基于组件的 utilization analytics 纳入进来。也就是说它不仅要告诉你“这个 workload 跑了多少分”还要告诉你底层系统是如何被使用的。比如 CPU 是否吃满内存带宽是否成为瓶颈磁盘 I/O 是否排队网络是否接近上限GPU 是否利用充分。没有利用率指标就很难解释性能差异到底来自哪里。5. Canary 持续验证测试Uber 的目标是用这个 benchmark 框架调度自动化测试在性能阈值被触发时提前告警。也就是说Ceilometer 不只是用于一次性的资格验证也可以进一步演进为持续验证系统。这类能力对于云环境特别重要。云基础设施底层可能不断变化如果每次变化都完全依赖人工感知就很容易漏掉风险。持续 benchmark 可以让平台在变化发生后更快发现异常。九、从 Ceilometer 看基础设施工程的几个关键原则Ceilometer 这篇文章虽然讲的是 benchmark 框架但它背后反映的是大规模基础设施治理的通用问题。1. Benchmark 的核心不是跑分而是决策很多团队做 benchmark最后只得到一组数字。数字本身当然重要但真正重要的是它能否支持决策。比如某个新服务器是否值得采购某个云实例是否适合数据库服务某个内核升级是否会导致延迟退化某个 GPU SKU 对特定模型推理是否更划算某个 touchless upgrade 是否可以继续 rolloutCeilometer 的价值在于它把 benchmark 和基础设施决策流程连在一起。结果不是停留在表格里而是进入数据仓库、分析服务、报告界面和变更验证流程最终影响生产环境中的真实选择。2. 统一平台比零散工具更重要不同技术栈当然需要不同测试方法但这不意味着每个团队都应该维护一套孤立 benchmark 系统。孤立工具的问题是配置不统一、结果不可比、数据难沉淀、接入成本高、长期维护困难。Ceilometer 的平台化思路是把差异留在测试适配层把共性能力抽到平台层。共性能力包括测试编排、机器分配、结果收集、数据归一化、历史存储、可视化、对比分析、异常检测和报告生成。这也是很多基础设施平台的通用演进方向先有工具再有规范最后变成平台。3. 合成 benchmark 和生产模拟要结合只跑合成 benchmark 不够因为合成分数不一定代表真实业务表现。只跑生产服务 benchmark 也不够因为它成本更高覆盖基础组件能力的能力较弱。Ceilometer 同时支持合成 benchmark 和生产工作负载模拟。前者提供早期、标准化、低成本信号后者提供更贴近真实业务的验证。两者结合才能更全面地评估基础设施变化。4. 性能和可靠性要一起看原文多次强调Ceilometer 不只关心 raw performance也关心 reliability。比如它会通过长时间使用和压力条件验证系统稳定性。这点很重要。一个配置在短时间 benchmark 中分数高不代表它适合生产。生产系统还需要考虑长时间运行、峰值压力、尾延迟、复制一致性、异常恢复、资源耗尽等问题。真正的基础设施 benchmark不能只问“快不快”还要问“稳不稳”“省不省”“能不能长期运行”“出问题能不能提前发现”。5. 性能数据必须沉淀成组织资产Ceilometer 把数据写入 blob store 和数据仓库并通过 analytics service 提供查询和可视化。这意味着 benchmark 结果不是一次性材料而是组织级资产。当数据持续积累后Uber 可以做更复杂的分析不同服务器代际的性能趋势、不同 workload 的资源偏好、不同云供应商升级带来的影响、某类回归的历史模式、不同配置组合的成本效率。这正是平台化的长期价值。短期看它减少人工 benchmark 成本长期看它让组织具备更强的基础设施判断力。十、总结Ceilometer 是 Uber 为了解决大规模基础设施性能验证问题而构建的自适应 benchmark 平台。它把过去手工、零散、不可复现的 benchmark 流程改造成了统一、自动化、可比较、可分析的平台能力。这套平台解决的问题包括测试配置不一致、测试系统碎片化、流程复杂难以规模化、结果缺少上下文、测试环境缺少可移植性以及很多技术栈没有成熟 benchmark 工具。通过标准化配置、容器化测试 harness、自动化编排、结果摄取、数据仓库和分析服务Ceilometer 让 Uber 能够更系统地评估服务器 SKU、基础设施变更、有状态服务、无状态服务和机器学习负载。(Uber)从应用场景看Ceilometer 最重要的两个用途是服务器规格选型和变更验证。前者帮助 Uber 在新服务器或云实例进入大规模使用前判断它们对不同工作负载的真实性价比后者帮助 Uber 在内核、配置、云厂商升级等变化进入生产前提前发现性能回归和异常行为。从未来方向看Uber 希望进一步增强 AI/ML 分析能力、扩大技术生态覆盖、引入更高级的异常检测、整合底层利用率指标并将 Ceilometer 推向 canary 持续验证。这样它就不只是一个 benchmark 平台而会更接近一个持续性能治理系统。这篇文章最值得借鉴的地方在于大规模基础设施中的 benchmark不应该只是某个工程师临时跑出来的一组数字而应该是一套贯穿硬件选型、系统变更、服务验证、成本优化和可靠性保障的工程体系。对于任何正在做基础设施平台化的团队来说Ceilometer 的经验都说明了一点性能测试只有被标准化、自动化、数据化并且嵌入真实决策流程才能真正发挥价值。