云端统一可观测性系统 DiTing（OSDI 2026）
原题：All Along the Watchtower: Achieving the Trinity of Observability in Cloud with DiTing
一句话总结：云端可观测性同时包含日志、指标和追踪，集中式 ClickHouse 在 CPU、内存和分区数上难以扩展，而节点资源又不够可靠；DiTing 用 Central–Node Collaboration 将近期数据和查询下推到产生数据的节点，并以 AZ 集中层保存副本和承担故障回退，在生产中达到亚秒级摄取、约 1,500 QPS/单 CPU 核和最高 65× 的 CapEx 降低。
问题与动机
SRE 诊断一次云故障时，通常先看指标，再沿追踪定位组件，最后查日志确认原因。传统系统把三类遥测数据放在不同存储和查询基础设施中，用户需要切换查询语言并手工关联结果。数据湖只统一计算接口，查询仍需跨系统搬运数据；纯内存系统成本又无法承受数百 PB 的日志与追踪数据。
作者在约 600 台节点的 ClickHouse 部署中观察到，扩展瓶颈主要是 CPU、内存和海量分区，而不是持久化容量。直接增加专用资源预计会增加超过 20% 的云基础设施 CapEx。另一方面，云服务器经常空闲，适合承载查询，但节点可能在流量突发或故障时不可用。DiTing 的问题是：如何把三类数据统一成一个可查询接口，同时利用空闲节点资源，又不把可观测性依赖在不可靠的末端节点上。
关键观察 / 隐含假设
- 观察 1：集中式处理的主瓶颈是 CPU 和内存。 ClickHouse 部署中宽指标表、超过百万分区和大范围扫描导致内存接近 85%，并出现 OOM；继续扩容 CPU/内存的成本估计超过 CapEx 的 20%（§3.2）。
- 依赖假设：遥测数据量持续增长，且指标维度和分区数量会继续扩大。
- 可能失效场景：如果工作负载主要是低维指标或查询量较低，集中式系统的资源成本差距会缩小。
- 观察 2：查询具有时间局部性和空间局部性。 SRE 多查询最近一小时或一周的数据，且诊断通常针对特定区域、集群、节点或设备（§4）。
- 依赖假设：近期数据仍留在产生数据的节点，物理位置和逻辑实体到节点的映射足够准确。
- 可能失效场景：全局历史分析、跨区域聚合或频繁迁移的数据会降低节点本地处理的收益。
- 观察 3：节点资源可利用，但在故障时最不可靠。 纯节点采集方案会在节点崩溃、网络分区和业务流量突发时失去查询能力，而这些时刻正是 SRE 最需要遥测数据的时候（§3.2）。
- 证据强度：强。架构直接提供三类故障回退，并在 200 节点实验中测试了 0%–100% 节点不可用。
- 假设 1：遥测数据允许短暂不一致，且主要是单写入、追加写。 DiTing 不提供强 ACID，节点作为固定 leader 写入，查询失败时读取 AZ 副本或对象存储副本（§4.5）。
- 证据强度：中。该假设适合诊断场景，但不同 SRE 任务对新鲜度和完整性的要求可能不同。
核心方法
DiTing 使用三层架构。Global 层只负责根据全局元数据把请求路由到 AZ，不存储或处理查询。AZ 层运行 20–100 台专用节点，负责持久化、查询树构造、聚合和回退执行。Node 层在采集遥测数据的服务器上运行 Data Collector，利用受限的空闲 CPU、内存和磁盘处理下推子查询并缓存近期数据。该 Central–Node Collaboration（CNC）对应观察 1–3：用节点资源降低稳态处理成本，用 AZ 层保留可靠副本和执行路径。
三类遥测数据统一存为 co-Log 表，并通过 SQL 查询。指标采用多值宽表，每 15 秒追加一行；追踪按 span 存储；日志保留时间、位置、严重级别和消息体。co-Log 使用 PAX 布局，把固定大小 row group、列和 page 组织在同一文件中，并在 footer 保存文件、row group、列和 page 多级索引。时间与空间字段默认建索引，适配观察 2；原始元数据格式避免 ProtoBuf/Thrift 的解析开销，以适应宽表中随机且偏斜的列访问。
查询树由 zone-root、zone-mixer 和 zone-leaf 组成。DiTing 不使用可能产生误报的 Bloom filter 做节点选择，而是结合 IP、集群信息、物理位置表和服务元数据精确定位目标节点。对于虚拟磁盘等逻辑对象，系统维护其到物理节点和磁盘的映射。节点不可用时，系统可在下推前直接回退、超时后重路由，或让过载节点仅返回最新数据，由 AZ 节点完成计算。
摄取路径利用时间局部性。节点内存缓冲保存最新数据；极端的 20K 指标/节点配置下，900 MiB 缓冲可覆盖超过 99.9% 的查询，资源更紧张时 100 MiB 仍达到约 90% 命中率。指标支持 1 分钟、5 分钟和 1 小时预聚合，降低长时间范围查询的扫描量。上传到 AZ 后，系统先合并同一服务器的 row group，再合并同一集群的 row group，同时保留 IP 排序和空间元数据，避免文件合并破坏查询下推。
一致性设计采用固定 leader 的简化 Raft-like 协议。节点是唯一写入者，数据上传至 AZ，并可备份到对象存储。CRC 覆盖生成、传输和持久化阶段，另有定期 scrub 与对象存储交叉校验。节点副本与 AZ 副本据故障率分析约提供九个九，增加对象存储备份后约为十二个九。
设计取舍
- 用非 ACID co-Log 换取吞吐和实现规模。 观测数据多为追加写，允许短暂陈旧和轻微不一致；代价是系统不适合需要事务语义的遥测更新。
- 用空间换查询速度。 节点保留内存缓存，指标还维护多粒度预聚合；这把成本从集中式 CPU 转移为全 fleet 的分布式内存。生产中 36K 节点的缓存合计约 34 TB。
- 放弃完全通用的数据格式。 co-Log 不支持复杂类型，也不做多粒度列级压缩，以简化实现并减少查询开销。该选择限制了对通用分析工作负载的适配能力。
- 精确定位换取元数据维护成本。 物理设备位置和虚拟磁盘映射需要从 EBS 等服务周期性刷新；映射延迟或错误会影响下推覆盖率和结果完整性。
实验与结果
- 在 80 台真实生产指标服务器的微基准中，单服务器查询约 1K QPS 时，DiTing 延迟约 0.2 秒；集中式变体慢 7–82×，长范围查询可达到 18.1 秒甚至因 OOM 失败（§5.1，图 9a）。
- 集群级指标查询中，DiTing 使用单个 CPU 核达到约 1,500 QPS；扩展到约 20K 节点的区域和约 60K 节点的多区域查询，延迟分别约 0.5 秒和 0.8 秒（图 9c–d）。
- 元数据辅助下推将约 1.4 PiB 数据的虚拟磁盘流量查询缩短到 2 秒；没有元数据时需要扫描全量数据，耗时几十分钟（§5.1）。
- 生产部署覆盖超过 100 万节点；在 300 多个集群、3.6 万节点的区域统计中，节点平均使用少于 2% CPU 核、约 0.5% DRAM 和 10–20 GB 本地磁盘，AZ 层平均服务约 1,200 QPS，节点层合计约 40K QPS（§5.2，图 10）。
- 与生产系统 Solution A 比较，DiTing 在 50 和 400 节点部署上提高 4–9× QPS，并把延迟降至其 1/10–1/4；CapEx 相比 Solution A 和 B 分别降低约 65× 和 3×（图 11–12，§5.3）。
- 元数据分片下推使查询延迟降低 33%，节点 CPU 从约 45% 降到 16%，每节点仅增加几 MB 内存（§4.3）。
论断—证据表
| 论断 | 证据 | 评测边界 | 置信度 |
|---|---|---|---|
| 节点下推能在大规模范围查询中保持低延迟 | 20K/60K 节点查询约 0.5/0.8 秒（图 9d） | 生产指标表、10 个字段、特定区域和多区域 | 强 |
| CNC 同时降低成本并保留故障回退 | 约 1% 查询回退；CapEx 降低 3–65×（§4.3、§5.3） | Alibaba 云内部部署与匿名基线 | 中 |
| 本地缓存是高 QPS 指标查询的主要来源 | 900 MiB 缓冲命中率超过 99.9%；去缓存后磁盘读取无法维持高并发（表 2） | 20K 指标/节点和 400 并发 | 强 |
| 统一 co-Log 能覆盖三类遥测数据 | 指标、追踪、日志联合查询，延迟随数据量增长（图 9g） | 三类生产数据的合成查询，规模有限 | 中 |
批判性分析
论证链条
从 ClickHouse 的资源瓶颈、节点空闲资源和遥测局部性出发，CNC 的设计逻辑是闭合的。实验也覆盖了单节点、集群、区域、全局、联合查询和节点失效。论文最有力的证据是大规模路由和元数据下推，而不是单纯的存储格式比较。
不过，65× CapEx 结论依赖内部成本模型。DiTing 不把被业务服务预先支付的节点资源计入 Type II 成本，因此该数字不能直接外推到需要独立购买节点的部署。联合查询的实验规模也明显小于生产规模，尚不足以证明跨百万节点的复杂 join 始终稳定。
假设压力测试
节点层资源限制由配置和 agent 自保护机制控制，但论文没有给出业务负载变化下的干扰分布、P99 影响或被终止 agent 的恢复时间。流量突发若同时造成节点不可用和 AZ 层回退，集中层是否有足够余量承接最坏情况，也没有完整容量模型。
空间下推依赖物理位置和逻辑映射的准确性。设备迁移、虚拟磁盘重平衡或元数据刷新延迟可能造成漏查或过度查询。论文说明了映射刷新机制，但没有报告错误映射、陈旧映射或跨服务映射失败的实验。
实验可信度
指标基准使用真实生产数据，并模拟了字段访问偏斜、多个时间窗口和 400 并发；追踪、日志和故障实验也使用生产数据或生产拓扑。基线包含集中式 DiTing、ClickHouse 和内部生产系统，覆盖较完整。缺口在于绝对成本、完整资源干扰、写入高峰期间的尾延迟和跨 AZ 故障场景均未公开。
系统性缺陷
每个节点都运行负责采集、持久化、缓存、执行和元数据处理的 agent，单个版本回归可能扩大到整个 fleet。论文承认这一 blast radius，并依赖 canary、分阶段发布、回滚、限流和熔断。对日志采用 schema-on-read 能保持写入简单，但会把解析成本推迟到查询路径，复杂正则在大范围扫描中的 CPU 和尾延迟未量化。
局限与后续工作
- 局限 1：成本对比使用匿名内部系统和内部计价，缺少绝对成本与可复现实验配置；外部用户难以验证 65× 的具体构成。
- 局限 2：论文未系统报告业务工作负载受节点 agent 影响的 P95/P99、CPU steal、磁盘带宽争用和 OOM 风险。
- 局限 3：简化一致性允许节点层与 AZ 层结果存在新鲜度差异；对于需要严格时间对齐的追踪—指标关联，用户可能必须重新查询集中副本。
- 后续工作 1：在真实流量突发和故障注入下，测量节点资源回收、查询回退比例、P99 延迟与业务 SLO 的联合分布。
- 后续工作 2：对陈旧或错误的物理映射注入故障，验证下推是否出现漏查、重复查和结果偏差，并设计可审计的映射版本语义。
相关
- 相关概念：Observability、Columnar-Storage、Query-Pushdown、Raft
- 同类系统：ClickHouse、Prometheus、Monarch
- 同会议：OSDI-2026