本文根据陈伟荣老师在 GOPS 2023·深圳站演讲整理而成，如有图文不妥，请以视频为准。更多精彩，请关注高效运维公众号。
一、蚂蚁客户端可观测体系介绍
蚂蚁可观测体系相对庞杂，涉及非常多系统，今天从一个角度切入讲讲重要问题的解决方法，以及针对核心技术，包括时序数据库、AI智能化相关做的一些开源工作。
首先介绍客户端可观测技术情况。为什么需要关注客户端的可观测技术呢？主要有两个原因：
-
第一，由于客户端本身架构开始变得越来越复杂，大家认为客户端在很早之前是前端页面，现在有了手机APP，手机APP变得越来越复杂，支付宝里面有内部架构，有客户端中间件团队、客户端业务团队等。客户端正在逐渐变成平台化，微信、支付宝以及其他大型应用程序都拥有小程序。小程序支持大量扩展，对这些小程序和扩展进行观测和监控是必要的。
-
第二，客户端体验是传递用户价值的最后一环。虽然用户并不关心后面的复杂架构和技术细节，但用户所能感受到的只有打开支付宝卡了或闪退了等问题。因此，技术团队需要解决这些问题，而可观测性在这方面相对比较重要。
简单介绍一下客户端可观测性负责的范围，包括客户端可用性、应用程序存储性能、白屏和闪退等问题。之前有一段时间，有人诟病支付宝的耗电量过高，我们进行了相关信息收集，查看不同版本的相关情况。如果发现版本存在问题，我们肯定会采取相应措施。
如下图所示，中间这块涉及到从设备到支付宝APP、小程序、直播等非常上层的业务。右侧是我们针对场景的观测行为，例如每年的双11和五福活动，我们会针对场景做相应的观测。
在蚂蚁金服，无论是客户端还是服务端、基础设施，都统一在AntMonitor可观测平台中。我们会与业务团队合作，提供更多的平台化能力，由客户端的业务团队与我们配合建立运维体系。这包括小程序平台、客户端发布平台和客户端保障平台。针对第三方扩展，我们会提供一些行业开放的东西，大家自己编写小程序也能看到相应的数据。
二、客户端可观测技术难点
接下来，我们将讲解客户端可观测的核心技术难点，这些都是我们实际遇到的问题。既然要讲客户端，我们先回顾一下服务端的可观测数据，因为它们在很大程度上是与业界相似的。在这里，我们将介绍蚂蚁金服在服务端监控数据方面的体系，以及与其他公司的区别。
十年前，我们从日志开始构建了这个监控平台。字节可能在追踪（Trace）方面投入了更多的资源，这在每家厂商具体实际情况可能有一定区别。
我们具备可观测这三个方面（Logging、Metrics、Tracing）的能力，但是从应用程序日志转化为Metrics，最后变成指标监控的这个过程是我们使用最多的。
相对的，客户端比服务端更加复杂。针对这三个点，分别有如下难点和挑战：
-
Tracing：现代的SOA架构是一些小应用程序之间的串联，而客户端和服务端之间的串联是断开的。客户端本身有中间件、框架等，但是这些往往无法与后端联系起来，因此它们的价值会降低。
-
Logging：日志是客户端收集的主要数据来源，它带来了一个比较大的挑战，即体量问题。支付宝的装机量达到了数亿，回传日志如何处理、如何存储、如何与不同版本进行匹配都是需要解决的问题。用户侧的APP软件版本不统一，中间可能涉及到复杂的日志清洗等流程。
-
Metrics：聚合指标也面临着相同的问题，即如何处理早期版本和后期版本之间的指标差异。另外，”数据维度爆炸”是可观测领域普遍存在的问题。
在面对各种问题时，我们真正需要解决的是哪些问题呢？总结后有如下四点：
-
海量数据处理与水平伸缩架构
-
维度（Tag）爆炸与多维分析
-
海量多样化被观测实体告警
-
采集与埋点规范
本文将重点分享“维度（Tag）爆炸与多维分析”和“海量多样化被观测实体告警”两个难点的解决思路。
三、客户端可观测核心技术分享
客户端和服务端的主要区别在于日志来源。服务端日志通常在业务服务器上装好，然后正常收集即可。而客户端日志则通过客户端框架回传到 SLS。客户端还有一个日志网关，用于进行很多日志数据的预处理。等到预处理完成后，后续流程就与服务端的流程几乎一样了。
下面将详细描述一下数据的流转过程：最初，客户端会将数据埋点上报到 SLS，然后整套采集系统会负责处理原始数据，包括补充一些版本相关问题和分布式数据缓存。在实时计算方面，我们使用了Spark，这取决于当时的情况和数据架构的可控性。
对于维表和统一服务，我们需要对大量的数据进行对齐和补齐，同时需要补充很多用户手机端没有打上的信息。这个过程中，数据会被移动到实时数据中，并最终写入到实时数据库中。
难题一：维度（Tag）爆炸与多维分析
解决方案Part1：维度服务与维表Join
常规的时序数据通常会被认为是一条条的时间线，但因为各种各样的问题，往往需要Join很多外部数据。所以我们认为常规的业界的工具，比如 Prometheus 原生模型有一定缺陷，只关注了趋势分析，没有关注同一时间点，例如需要分析 APP 和APP 相关的一些内容的分析能力是欠缺的，我们加入了 Join 功能，在数据处理流程中以嵌入的形式集成，最终表达形式就是维度计算，会以 app.province.area 这种形式把所有维度数据进行多层 Join。
解决方案Part2：分析型时序数据库CeresDB
关于维度爆炸对存储带来的问题，我们和其他厂商可能不太一样，前面提到了腾讯、京东等存储方案非常多，我们是自研一套时序数据库，我们在设计层面就考虑到维度爆炸问题。
传统时序数据库，包括 InfluxDB、Prometheus、VictoriaMetrics 这些，技术特点是 Tag 和 Field 是分开存储的，本质上是构建倒排索引，通过倒排索引能够在查询时精确地定位到某条时间线进行拉出来分析，这种点查或者针对某一条时间线的查询是非常高效的，但当维度爆炸时我们可能会有一些多维分析下钻相关诉求，这个支持起来就有问题。此外，维度爆炸之后构建倒排索引，写入时有大量的开销。
如何解决这个问题？我们选择了列式存储和分区剪枝。这个图有点问题，他写按年，实际我们是按天、按小时去分segment，每个segment里面有大量的源信息，对查询过程中的剪枝效果是非常好的。
解决方案Part3：分析型时序数据库CeresDB存算分离与弹性架构
介绍 CeresDB 分布式架构，我们自己从头开始研发了一款时序数据库，除了刚才解决单机维度爆炸的问题，还需要解决分布式问题，这包括原生 Prometheus 也是没有的，整个结构会变成计算存储分离结构。
黄色这部分是真正的数据存储，可以外置到 Kafka、OSS。WAL用来保证数据可靠性，OSS主要是用来存储真正的数据。因为存算分离，绿色每一个CeresDB Server设计分布式方案非常简单，因为存储系统设计最难的就是状态，很多状态信息我们可以不用特意关注。
中间关于各节点调度，分表管理等会有 CeresMeta 节点。关于选组相关，我们是用嵌入式etcd的方案，之所以使用嵌入式 etcd 方案，是因为我们在架构上的设计考虑。因为我们认为大部分厂商、用户真正关注的数据体量并没有那么大，不需要部署一套非常复杂的系统，希望尽可能减少各种数据节点。
解决方案Part4：分析型时序数据库CeresDB查询性能优化
CeresDB性能问题，我们通过如下三个方面解决这个问题。
-
针对超大数据表：百亿级别的数据表我们通过用分区表来增加水平扩展。
-
存算分离特有问题：
-
首查性能问题：发起第一次查询时本身并没有数据，需要从远端OSS把数据拉回来。因此我们考虑怎么样数据能够拉的更少，我们用各种相关元信息加到CeresMeta中来提升数据筛选度；其次是增加远程IO并行度，来使数据拉的更快。
-
次查性能问题：次查其实就是构建多级缓存，首查已经查过了，我们需要用到首查拿回来的数据。
3. 性能的一致性：用户肯定不希望数据库性能一会儿好、一会儿差，其实就是性能一致性。我们会把后台任务及烂SQL管理相关的东西做一些优化。
解决方案Part5：分析型时序数据库CeresDB性能优化
如下图所示，左边图中上图是写入性能，当维度开始爆炸时，因为需要构建倒排索引，可以看到 InfluxDB 写入性能是逐步下降的趋势。第二个是 CeresDB 的性能曲线，前面有部分掉下去是因为节点初始化时需要构建缓存等相关信息。
此外，查询性能也是非常重要的。目前在高筛选度条件下命中数据较少，针对某一台机器去查数据，由于存储结构设计我们跟InfluxDB不太一样，会有一定程度比InfluxDB要慢。这个问题可以通过针对小的数据块建立更多针对性的索引来优化。低筛选度条件，也就是说对大量数据做分析时，这种情况下CeresDB比InfluxDB快26倍。对于数据继续增长性能是没有什么特别大的影响的。
难题二：海量多样化被观测实体告警
我们有这么多数据，如何解决几百万被观测实体告警问题呢。运维出身的同学一定非常痛苦，不希望把所有报警手工配一遍，或者手工配出来，然后批量覆盖，这样针对每个有特点东西的覆盖效果并不是很好。
解决方案一：智能告警
目前业界比较流行，各个云厂商包括业界也有很多方案，针对曲线做异常检测。异常检测整体架构分为三层：第一层算法路由、第二层检测、第三层降噪。这三层在我们实际应用过程中效果非常好。
首先前置算法路由，拿到这个数据到底执行什么算法，不能把所有算法跑一遍，这样对系统开销是比较大的。算法路由模块会看这个数据当前有没有问题，有问题应该跑什么样的算法。中间会有具体的算法实现，但算法产生的结果并不总是我们想要的。
因此，我们需要引入降噪技术，将算法、规则和事件进行处理。这些事件可能是运维事件，也可能是主动或外部的突发事件。我们需要避免这些事件对真正需要收到告警的人造成干扰。
这是非常传统的异常检测。这块工作我们也在做相关的开源，后续会介绍。
解决方案一：动态阈值生成技术
这个技术业界提的相对比较少。实际想要做的事情是人工匹配被观测的实体，并根据曲线的形状生成规则。这些规则可以根据时间段内的阈值进行分类。我们希望将这些规则自动生成。
前面提到的单纯使用算法的异常检测可解释性非常差，真正用户并不知道里面发生了什么事情，也不知道什么情况下能告警出来，什么情况下不能告警出来，所以我们在推广时遇到非常大的阻力。
将生成的规则展示给用户，用户能直观地感受到这些规则的作用。生成规则时，可以结合数据特点，例如流量大小或检测业务总量等，这些特点可以帮助我们在生成规则时进行分类。下图解释了动态阈值生成技术的过程。
第一点和之前的内容相同，需要将一些事件的变更、突发情况或不太正常的情况剔除，以便我们通过常态的数据生成想要的规则。
第二点是特征转换，拿到的数据可能不容易生成规则，但是经过一定的转换可以变成更容易生成的数据。例如，检测支付宝交易总量时，我们可以使用一阶差分。因为大多数用户在中国，每天晚上三四点交易量非常低，而每天中午和晚上因为需要点外卖，交易量比较高。生成一条非常平滑的曲线很难，因此我们可以使用一阶差分，生成03分数据减去02分数据，将一整天的数据计算出来，这个结果就会非常有规律。
对于只有每隔三五分钟才有一笔交易的小程序，如何设定阈值？这很难设定，因此我们可以改变思路，将其转换为中间时间长度，并通过特征转换生成阈值。
下面是具体的动态阈值生成方法，将每天分成几个时间段，并对每个时间段的历史数据进行回跑。与前面的内容一样，后置降噪同样很重要，我们都希望尽可能减少干扰。
上图是整体的模式实现架构。前置校验、推导任务统一调度，会由具体程序进行执行。再下面会有存储样本、算法结果，各种模板、阈值。最上面是实时运行，生成出来的规则缓存进行统一调度、告警检测。规则生成后，这些规则跟人工配置规则一起运行。
四、开源与技术演进
核心技术我认为在这个场景下主要解决两个问题，时序数据问题和智能化问题。我们将相关技术都进行了开源。CeresDB 于去年6月正式开源，而 Holonsight 的开源则是在今年2月底。这两个项目都是由我们团队负责的。
Holonsight 在内部使用较少，主要用于小程序和云上。CeresDB 的蚂蚁内部版本和开源版本完全相同，可以直接使用开源代码进行内部部署。
相关链接：
陈伟荣（蚂蚁集团高级技术专家）
2015年加入阿里集团，此后一直在可观测领域工作。阿里电商可观测平台 Sunfire 创始团队成员。2017年转岗蚂蚁集团，为蚂蚁 Xflush核心研发。
2019 年起负责蚂蚁可观测技术与架构团队，带领团队经过多年工作，产出了蚂蚁统一可观测平台 AntMonitor、开源时序数据库 CeresDB、开源可观测平台 HoloInsight 等成果。
在小小的代码里挖呀挖呀挖，6月29-6月30，2023 DOIS DevOps 国际峰会 · 北京站，可观测性、SRE、云原生架构，运维转型需要的内容，都在这里！
▲扫码图片二维码，进入大会官网，上下滑动，查看更多▲
近期好文：
“高效运维”公众号诚邀广大技术人员投稿
投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118。
发表评论