Khronos: 面向万亿规模时间线的性能监控引擎建设实践

作者：余文清

阿里巴巴智能引擎事业部自研的 Khronos 系统是阿里内部接入规模最大的性能数据存储引擎。Khronos 支持动态生命周期的存储计算分离架构，采用 schemaless 的 data model 设计，在万亿数据规模下为业务提供易用、高效、经济的服务，团队近期的优化工作也被国际学术会议 CIKM2023 收录。本⽂总结了 Khronos 在性能监控领域遇到的技术挑战，以及在这个场景下的一些价值判断。

一、背景

时序数据管理系统（Time series DBMS）近年来受到较多的关注，这是受到多方面因素推动的结果，包括：云原生可观测性的要求逐渐标准化，DevOps/AIOps 的发展，IoT 技术、车联网、智能⾦融等技术趋势对时序数据的存储需求。从图 1 左侧 DB-Engines 网站[1]的趋势可以看出，从 2013 年开始，Time series DBMS 受到的关注就在逐渐上升。

另一方面，时序数据库产品形态也呈现出多元化趋势。图中右侧列出的是 DB-Engines 根据时序数据库产品热度的 top10 排名。在这个榜单中，有的是为业务场景设计的专业时序数据库产品（例如 InfluxDB、Prometheus、Graphite），有的是基于关系型数据库的架构，针对业务场景进行了专门的设计（例如 Kdb+，TimescaleDB), 也有的面向更通用的大数据分析场景，时序分析是它能满⾜的⼀个子场景（例如 Druid）。

在我们对业内产品的调研过程中发现，⽬前没有产品能够很好的满⾜大规模性能监控中台对时序数据库的要求。因此在 2019 年，阿里智能引擎团队就基于 AIOS 技术栈体系[2]和 Havenask 开源搜索引擎[3]，自研了⼀款面向大规模性能监控场景的时序存储引擎 Khronos。

经过几年的持续建设，它已经成为阿里内部两大性能监控平台 Kmonitor 和 Sunfire 的底层时序数据存储引擎。2023 年是 Khronos 上线生产系统的第 4 年，从数据接入量上看，它俨然已成长为阿里巴巴内部规模最大的性能数据存储引擎。

二、技术挑战

在性能监控场景，TSDB 的主要的使用场景有大盘展示、系统问题调查、根因分析、异常检测和报警等。随着内部业务逐渐向云上环境迁移，基于云上的性能监控，面临以下几大挑战：

2.1 写入规模巨大

随着 DevOps 概念、云原生概念、系统可观测性概念的普及，集团内部应用大量使用指标、日志等手段实时反馈系统的性能状态和业务状态。

以 Kmonitor 业务平台为例，指标接入量从 2019 年的每秒写入 46Million/second 增长到 2022 年的 255 Million/second，每年都有 1 倍左右的写入量增长。这些数据需要被 Khronos 实时消费、索引并且存储起来，这对数据的接入 pipeline 是⼀个巨大的压力。另⼀方面，业务层面对指标数据的保留时间限制(time-to-live) 存在需求，大部分的指标数据保留 1-3 个月，但是也有⼀定比例的指标要求永久保留。

2.2 维度诅咒

我们用时间线的基数（cardinality）来衡量性能监控场景的规模。这里先简单介绍⼀下时间线的概念。性能监控数据通常被建模为多维时间序列（multi-dimensional time series）,  每⼀个 time series 包含⼀个 metric、⼀组 tags（其中，每个 tag 由 tag key 和 tag value 构成）和⼀组带时间戳的样本值（timestamped samples）。⼀条时间线可以由 SeriesKey 进行唯⼀标识，SeriesKey =  metric + tags。

以下表为例，包含了 4 个 series（红、绿、蓝、黄）：

（表 1）

在 Kmonitor 业务场景中，我们在多个租户都观察到时间线的基数逐渐膨胀。图 2 给出了 4 个典型租户时间线基数的变化趋势。可以看出，他们的时间线规模都在持续增长，个别租户(HI) 的时间线规模甚至超过万亿级别（1e12）。另一个值得注意的统计特征是 60%以上的时间线生命周期并不长，在⼀个小时以内。

（图 2）

时间线基数膨胀的主要原因是时间线存在⼀定的流动率（churn rate）：active 的时间线停⽌接受指标样本，变为 inactive 状态。同时，又不断有新的 active 时间线进入系统。

在具体业务中，series churn 的来源是多方面的，例如：

• 在线系统会在电商大促活动期间进行弹性扩缩容操作，扩容操作发生时，新启动的业务进程就会产生大量新的时间线；而缩容操作发生时，大量的进程消亡，对应的时间线变成 inactive 状态。

• 随着大规模混布技术和容器技术的应用，云上部署的服务进程会在物理机之间进行迁移。如果某些指标以物理机 IP 作为 tag key，那么每当进程迁移到新的物理机时，就会产生⼀批新的 active 的时间线集合（IP 的 tag value 发生更新）。

表 2 对来自不同租户的 30 分钟区间的汇报指标进行了统计。可以看出时间线基数（#series）就达到百万级别（1e7）。例如 ASI 租户，时间线基数到了 4100 万+。主要原因是 tags 的平均维度（#tags）超过 31 个，tag values 的基数（tag values 列）超过 446 万。我们把 tags 维度太多导致的时间线基数膨胀问题，称作时序场景的“维度诅咒”。