坐拥亿级用户，支付宝 APP 如何进行运维可观测体系建设？

一、蚂蚁客户端可观测体系介绍

蚂蚁可观测体系相对庞杂，涉及非常多系统，今天从一个角度切入讲讲重要问题的解决方法，以及针对核心技术，包括时序数据库、AI智能化相关做的一些开源工作。

在蚂蚁金服，无论是客户端还是服务端、基础设施，都统一在AntMonitor可观测平台中。我们会与业务团队合作，提供更多的平台化能力，由客户端的业务团队与我们配合建立运维体系。这包括小程序平台、客户端发布平台和客户端保障平台。针对第三方扩展，我们会提供一些行业开放的东西，大家自己编写小程序也能看到相应的数据。

二、客户端可观测技术难点

接下来，我们将讲解客户端可观测的核心技术难点，这些都是我们实际遇到的问题。既然要讲客户端，我们先回顾一下服务端的可观测数据，因为它们在很大程度上是与业界相似的。在这里，我们将介绍蚂蚁金服在服务端监控数据方面的体系，以及与其他公司的区别。

十年前，我们从日志开始构建了这个监控平台。字节可能在追踪（Trace）方面投入了更多的资源，这在每家厂商具体实际情况可能有一定区别。

我们具备可观测这三个方面（Logging、Metrics、Tracing）的能力，但是从应用程序日志转化为Metrics，最后变成指标监控的这个过程是我们使用最多的。

相对的，客户端比服务端更加复杂。针对这三个点，分别有如下难点和挑战：

Tracing：现代的SOA架构是一些小应用程序之间的串联，而客户端和服务端之间的串联是断开的。客户端本身有中间件、框架等，但是这些往往无法与后端联系起来，因此它们的价值会降低。

Metrics：聚合指标也面临着相同的问题，即如何处理早期版本和后期版本之间的指标差异。另外，”数据维度爆炸”是可观测领域普遍存在的问题。

在面对各种问题时，我们真正需要解决的是哪些问题呢？总结后有如下四点：

海量数据处理与水平伸缩架构

维度（Tag）爆炸与多维分析

海量多样化被观测实体告警

采集与埋点规范

本文将重点分享“维度（Tag）爆炸与多维分析”和“海量多样化被观测实体告警”两个难点的解决思路。

三、客户端可观测核心技术分享

下面将详细描述一下数据的流转过程：最初，客户端会将数据埋点上报到 SLS，然后整套采集系统会负责处理原始数据，包括补充一些版本相关问题和分布式数据缓存。在实时计算方面，我们使用了Spark，这取决于当时的情况和数据架构的可控性。

对于维表和统一服务，我们需要对大量的数据进行对齐和补齐，同时需要补充很多用户手机端没有打上的信息。这个过程中，数据会被移动到实时数据中，并最终写入到实时数据库中。

难题一：维度（Tag）爆炸与多维分析

解决方案Part1：维度服务与维表Join

解决方案Part2：分析型时序数据库CeresDB

关于维度爆炸对存储带来的问题，我们和其他厂商可能不太一样，前面提到了腾讯、京东等存储方案非常多，我们是自研一套时序数据库，我们在设计层面就考虑到维度爆炸问题。

传统时序数据库，包括 InfluxDB、Prometheus、VictoriaMetrics 这些，技术特点是 Tag 和 Field 是分开存储的，本质上是构建倒排索引，通过倒排索引能够在查询时精确地定位到某条时间线进行拉出来分析，这种点查或者针对某一条时间线的查询是非常高效的，但当维度爆炸时我们可能会有一些多维分析下钻相关诉求，这个支持起来就有问题。此外，维度爆炸之后构建倒排索引，写入时有大量的开销。

如何解决这个问题？我们选择了列式存储和分区剪枝。这个图有点问题，他写按年，实际我们是按天、按小时去分segment，每个segment里面有大量的源信息，对查询过程中的剪枝效果是非常好的。

解决方案Part3：分析型时序数据库CeresDB存算分离与弹性架构

介绍 CeresDB 分布式架构，我们自己从头开始研发了一款时序数据库，除了刚才解决单机维度爆炸的问题，还需要解决分布式问题，这包括原生 Prometheus 也是没有的，整个结构会变成计算存储分离结构。

解决方案Part4：分析型时序数据库CeresDB查询性能优化

CeresDB性能问题，我们通过如下三个方面解决这个问题。

针对超大数据表：百亿级别的数据表我们通过用分区表来增加水平扩展。

存算分离特有问题：

首查性能问题：发起第一次查询时本身并没有数据，需要从远端OSS把数据拉回来。因此我们考虑怎么样数据能够拉的更少，我们用各种相关元信息加到CeresMeta中来提升数据筛选度；其次是增加远程IO并行度，来使数据拉的更快。

次查性能问题：次查其实就是构建多级缓存，首查已经查过了，我们需要用到首查拿回来的数据。

3. 性能的一致性：用户肯定不希望数据库性能一会儿好、一会儿差，其实就是性能一致性。我们会把后台任务及烂SQL管理相关的东西做一些优化。

解决方案Part5：分析型时序数据库CeresDB性能优化

如下图所示，左边图中上图是写入性能，当维度开始爆炸时，因为需要构建倒排索引，可以看到 InfluxDB 写入性能是逐步下降的趋势。第二个是 CeresDB 的性能曲线，前面有部分掉下去是因为节点初始化时需要构建缓存等相关信息。

此外，查询性能也是非常重要的。目前在高筛选度条件下命中数据较少，针对某一台机器去查数据，由于存储结构设计我们跟InfluxDB不太一样，会有一定程度比InfluxDB要慢。这个问题可以通过针对小的数据块建立更多针对性的索引来优化。低筛选度条件，也就是说对大量数据做分析时，这种情况下CeresDB比InfluxDB快26倍。对于数据继续增长性能是没有什么特别大的影响的。

难题二：海量多样化被观测实体告警

我们有这么多数据，如何解决几百万被观测实体告警问题呢。运维出身的同学一定非常痛苦，不希望把所有报警手工配一遍，或者手工配出来，然后批量覆盖，这样针对每个有特点东西的覆盖效果并不是很好。

解决方案一：智能告警

目前业界比较流行，各个云厂商包括业界也有很多方案，针对曲线做异常检测。异常检测整体架构分为三层：第一层算法路由、第二层检测、第三层降噪。这三层在我们实际应用过程中效果非常好。

首先前置算法路由，拿到这个数据到底执行什么算法，不能把所有算法跑一遍，这样对系统开销是比较大的。算法路由模块会看这个数据当前有没有问题，有问题应该跑什么样的算法。中间会有具体的算法实现，但算法产生的结果并不总是我们想要的。

因此，我们需要引入降噪技术，将算法、规则和事件进行处理。这些事件可能是运维事件，也可能是主动或外部的突发事件。我们需要避免这些事件对真正需要收到告警的人造成干扰。

这是非常传统的异常检测。这块工作我们也在做相关的开源，后续会介绍。

解决方案一：动态阈值生成技术

这个技术业界提的相对比较少。实际想要做的事情是人工匹配被观测的实体，并根据曲线的形状生成规则。这些规则可以根据时间段内的阈值进行分类。我们希望将这些规则自动生成。

前面提到的单纯使用算法的异常检测可解释性非常差，真正用户并不知道里面发生了什么事情，也不知道什么情况下能告警出来，什么情况下不能告警出来，所以我们在推广时遇到非常大的阻力。

将生成的规则展示给用户，用户能直观地感受到这些规则的作用。生成规则时，可以结合数据特点，例如流量大小或检测业务总量等，这些特点可以帮助我们在生成规则时进行分类。下图解释了动态阈值生成技术的过程。

第一点和之前的内容相同，需要将一些事件的变更、突发情况或不太正常的情况剔除，以便我们通过常态的数据生成想要的规则。

对于只有每隔三五分钟才有一笔交易的小程序，如何设定阈值？这很难设定，因此我们可以改变思路，将其转换为中间时间长度，并通过特征转换生成阈值。

下面是具体的动态阈值生成方法，将每天分成几个时间段，并对每个时间段的历史数据进行回跑。与前面的内容一样，后置降噪同样很重要，我们都希望尽可能减少干扰。

上图是整体的模式实现架构。前置校验、推导任务统一调度，会由具体程序进行执行。再下面会有存储样本、算法结果，各种模板、阈值。最上面是实时运行，生成出来的规则缓存进行统一调度、告警检测。规则生成后，这些规则跟人工配置规则一起运行。

四、开源与技术演进

核心技术我认为在这个场景下主要解决两个问题，时序数据问题和智能化问题。我们将相关技术都进行了开源。CeresDB 于去年6月正式开源，而 Holonsight 的开源则是在今年2月底。这两个项目都是由我们团队负责的。

Holonsight 在内部使用较少，主要用于小程序和云上。CeresDB 的蚂蚁内部版本和开源版本完全相同，可以直接使用开源代码进行内部部署。

我今天的分享到此结束，谢谢大家！

高性能云原生时序数据库CeresDB：https://github.com/CeresDB/ceresdb

一站式智能可观测平台HoloInsight：https://github.com/traas-stack/holoinsight

陈伟荣（蚂蚁集团高级技术专家）

2015年加入阿里集团，此后一直在可观测领域工作。阿里电商可观测平台

Sunfire

创始团队成员。2017年转岗蚂蚁集团，为蚂蚁

Xflush核心研发。

2019

年起负责蚂蚁可观测技术与架构团队，带领团队经过多年工作，产出了蚂蚁统一可观测平台

AntMonitor、开源时序数据库 CeresDB、开源可观测平台

HoloInsight

等成果。

在小小的代码里挖呀挖呀挖，6月29-6月30，2023 DOIS DevOps 国际峰会 · 北京站，可观测性、SRE、云原生架构，运维转型需要的内容，都在这里！

“高效运维”公众号诚邀广大技术人员投稿